Используемая терминология
Для проверки прав доступа пользователей к ресурсам на серверах Eserv (почтовым ящикам POP3, IMAP, файлам HTTP, FTP) и прав приема/передачи интернет-трафика программами пользователя (внешних ресурсов через HTTP, FTP, Socks прокси, передачи почты по SMTP) в Eserv используются два основных вида управляющих списков:
списки пользователей (учетных записей)
списки прав доступа (ACL)
Списки пользователей – установка соответствия между полученными от пользователя данными (имя, пароль, IP-адрес и другие вводимые вручную или детектируемые сервером автоматически атрибуты) и именем учетной записи.
Списки прав доступа – определение прав доступа авторизованного пользователя к конкретному сетевому ресурсу, требующему не-анонимного доступа. На основе этого анализа доступ предоставляется, ограничивается отдельными правами, отвергается или запрашивается переавторизация – для смены полномочий.
Для удобства управления большими списками с однотипными правами пользователей можно объединять в именованные группы, и в списках прав доступа задавать права не отдельным пользователям, а группам. Соответственно, в Eserv применяются дополнительные списки – списки групп, где описывается членство пользователей в группах.
В случаях, когда Eserv обслуживает более одной организации или подразделения/проекта или более одного интернет-домена возникают ситуации, когда невозможно (и ненужно) обеспечивать уникальность имен учетных записей (например, в каждой организации есть свой postmaster). Поэтому реализована возможность иметь несколько независимых непересекающихся списков пользователей – в виде доменов. Домены – это имена для уникальной идентификации таких общностей учетных записей. Внутри домена имя учетной записи должно быть уникально. Полное имя учетной записи состоит из имени внутри домена и имени самого домена. Такое полное имя записывается как email-адрес: имя_учетной_записи@имя_домена и является уникальным как минимум в пределах Eserv. Имя домена может соответствовать реально существующему доменному имени, принадлежащему организации, а может быть никак не связанным с интернетом. В последнем случае оно может содержать любые символы, допустимые в файловой системе. Для различения своих и чужих доменов используются списки локальных доменов. Если используются реально существующие интернет-домены, то Eserv может отличать свои домены от чужих автоматически – по DNS.
При авторизации пользователь может явно указывать имя@домен – в этом случае Eserv сразу знает, по какому домену проводить авторизацию этого пользователя. Если домен не указывается, применяется домен по умолчанию. Это может быть один жестко заданный в настройках домен, а также может выбираться в зависимости от сетевого интерфейса (IP-адреса сервера), к которому подключился клиент. В multihomed-системах это позволяет создать на каждом IP свой отдельный «виртуальный» сервер с привязкой домена к IP-адресу – в результате пользователям не нужно вводить домен при авторизации на своем сервере. Домен по IP может определяться автоматически по DNS, если используются реальные интернет-домены. Но в общем случае надежнее и намного быстрее пользоваться списком соответствия домены – IP.
Часто бывает удобно автоматически назначать не только домен, но и имя пользователя (учетной записи). Если IP-адреса пользовательских компьютеров фиксированы, и если пользователи работают только со своих компьютеров, то можно назначать имя пользователя по IP-адресу подключившегося к серверу клиента. В Eserv это называется IP-авторизацией. Соответствие имен учетных записей клиентским IP задается в списке IP-авторизации.
При использовании SSL/TLS-соединений с сервером Eserv также позволяет использовать автоматическую авторизацию по пользовательским X.509-сертификатам. Эта возможность реализована в ядре Eserv осенью 2003, но пока не поддерживается в интерфейсе управления (на февраль 2004).
Как было сказано выше, домены – это фактически списки учетных записей. Когда становятся известны пользовательские данные – имя, пароль, домен – сервер может проводить авторизацию пользователя по заданному для данного домена списку. Физически списки пользователей домена могут храниться различными способами – быть записаны в текстовых файлах разных форматов, в базах данных доступных по разным протоколам, совпадать с учетными записями локального Windows NT, другого компьютера, контроллера домена, веб-сервера и т. п. В Eserv поддерживаются перечисленные способы доступа к спискам и эти способы могут дополняться, т. к. все способы реализованы в виде подключаемых модулей – plugin'ов. Логически работа с любым списком единообразна – нужно иметь возможность выяснить, есть ли такой пользователь в списке, совпадает ли пароль, входит ли пользователь в заданную группу, и т. п. Однако в зависимости от способа авторизации требуются дополнительные параметры – имя файла со списком, либо параметры доступа к базе данных, имя NT-сервера и т. д. По аналогии с источниками данных (DSN – data sources) в Windows, в Eserv используются список источников авторизации (AuthSources). В списке задаются имена источников (произвольные), имена методов авторизации (auth_nt, auth_e2, auth_md5, auth_odbc, … – имена соответствующих plugin'ов) и параметры доступа к конкретным спискам в зависимости от метода авторизации. А в списке локальных доменов указывается только имя источника авторизации – оно используется как ссылка на список источников. Если в этих списках обнаружено несоответствие (нет заданного пользователем домена или в списке источников авторизации нет указанного в списке локальных доменов источника), то используется метод авторизации по умолчанию, заданный в настройках сервера.
Конкретная реализация в базовой конфигурации Eserv и Eproxy
В Eserv3.ini по умолчанию принята авторизация AuthDomains? – выбор способа авторизации в зависимости от домена. При авторизации выполняется следующая последовательность действий:
предварительный «отсев» по черным и белым спискам по IP для конкретного сервиса
для протоколов, допускающих анонимную работу (SMTP, HTTP, proxy) предварительная IP-авторизация
явная авторизация, если переданы пользовательские имя/пароль/домен
если домен не задан, то установка домена по умолчанию по списку Lists[DomainIP?] либо Server[DefaultDomain?], если в DomainIP? не указано соответствие для текущего IP
по домену в списке локальных доменов Lists[LocalDomains] находится имя источника авторизации, а если домен не найден, то используется метод авторизации по умолчанию – AUTH[AuthMethod]
по имени источника в списке источников авторизации AUTH[AuthSources] ищется метод авторизации и его параметры, а если источник не наден, то используется метод авторизации по умолчанию – AUTH[AuthMethod]
выполняется правило DoLogin? для найденного источника авторизации. При успешной авторизации переменная UID содержит ненулевое число. Далее это значение может использоваться при анализе прав доступа к конкретному серверу/ресурсу. Правило «LoggedAs?: user» возвращает истину, если имя учетной записи user, и UID не равен нулю.
…
IP-авторизация
Автоматическая авторизация удобна для тех протоколов, в которых не предусмотрена обязательная явная авторизация, и таким образом так или иначе существует «пользователь по умолчанию» или «права по умолчанию». К таким протоколам относятся HTTP, HTTP-proxy, SMTP, Socks4. Все перечисленные протоколы, кроме Socks4, допускают и явную авторизацию. IP-авторизация в этом случае позволяет автоматически устанавливать пользователя, чьи права должны применяться по умолчанию, и таким образом регулировать права без явного запроса имени:пароля у пользователя. При нехватке «автоматических» прав можно запросить явную авторизацию для повышения прав.
В POP3, IMAP, FTP, Socks5 авторизация всегда явная (даже в случае «анонимных» FTP клиентская программа всегда использует команды протокола USER,PASS).
IP-авторизация берет IP-адрес подключившегося клиента и сверяет со списком, в котором заданы соответствия IP-подсеть – имя. При попадании IP клиента в заданную подсеть клиент автоматически считается авторизованным с именем «имя».
В текущей версии Eproxy для HTTP-proxy используется Eserv/2-совместимый? формат списка IP-авторизации
IP-Auth: IP_адрес маска имя_пользователя
и задается в файле CommonPlugins\plugins\auth_lib\IpAuth.rules.txt
В текущей версии Eserv SMTP-сервера IP-авторизация объединена с белым списком IP – SMTP[IpWhiteList?], в веб-интерфейсе управляется через http://localhost:3140/main/CONF/lists/smtp/IpWhiteList.txt Указываемый в последнем столбце логин назначается по умолчанию при подключении клиента с подходящим под маску IP-адресом.
FAQ
Нужно ли пользователю подтверждать свои имя и пароль, можно ли использовать этот метод при установке Eproxy3 на контроллере домена, на сколько медленнее идет авторизация при этом по сравнению с IPAuth, auth_md5
Подтверждать имя:пароль не нужно. При авторизации по доменам NT имя и пароль, введенные пользователем, передаются для проверки на компьютер или домен ActiveDirectory?, имя которого указано в источнике авторизации. Если указать “." (точка) вместо имени компьютера, то используются локальные учетные записи NT того компьютера, на котором установлен Eserv. Скорость проверки паролей в auth_nt сильно зависит от конфигурации NT и сети, и от к-ва пользователей, но обычно медленнее, чем IP-Auth и auth_md5.
Как правильно настроить определенный метод (например упомянутый выше доменный)
Сначала в списке источников авторизации (AuthSources.txt) добавить новый источник с требуемыми вам параметрами (если там такого нет), потом в списке локальных доменов добавить домен, ссылающийся на этот источник. Либо, если ничего не настраивать в «свежеустановленном» Eserv, будет по умолчанию использоваться авторизация auth_md5 по списку UserList?.txt – этот список можно заполнить через веб-интерфейс.
Если я правильно понимаю, при настройке источника авторизации списоб – вещь определенная и выбор у меня только из того, что указано в исходных (постинсталляционных) файлах, а наименование – могу указывать, что на ум придет, а потом ссылаться на него там где нужно.
Верно, наименование источника авторизации роли не играет, это имя используется только для ссылок.
Для определения имени пользователя используется база пользователей из Active Directory? И вводить имя и пароль от пользователя не требуется (как при IP-авторизации)? Как происходит проверка пароля – опишите механизм, пожалуйста.
Вводить пароль не потребуется только в случае IP-авторизации. Если используется авторизация auth_nt, и в качестве параметра указывается домен Active Directory или имя сервера с контроллером домена, то Eserv/Eproxy сможет там авторизоваться, если у машины, на которой установлен Eserv, есть права на эту операцию (как правило, машина должна быть членом домена, плюс Eserv должен работать сервисом под учетной записью LocalSystem?). В старые версии Eproxy, а также в текущие версии Eserv (начиная с 09.02.2004) входит скрипт http://eserv:3140/nt/users.html, который позволяет управлять пользователями и группами на NT-сервере – если это удается через веб-интерфейс, значит и для авторизации прав хватит.
Хотелось бы вообще отвязаться от «списков пользователей» в Eproxy.
Тогда можно просто не требовать авторизации в ACL в Eproxy – будут допускаться все локальные пользователи. Если разным пользователям нужно дать разные права на доступ через прокси, то придется списки использовать – если не имён, то хотя бы IP. При подключении клиента сервер изначально ничего не знает о нем, кроме его IP…
Как мне давать инет не всей сети, а только некоторым её членам, скажем с ip=192.168.0.1, 192.168.0.4 и др?
В http://localhost:3140/main/CONF/lists/proxy/HostBlackList.txt есть пример с ограничением доступа к сайту www.fastmoneyforfree.com пользователю с IP 10.1.1.20:
www.fastmoneyforfree.com * 0 PeerIP= 10.1.1.20
Если добавить запись
* 0 0 PeerIP= 10.1.1.20
То доступ этому IP будет ограничен ко всем сайтам. Аналогично в белом списке можно разрешать доступ. Белый список имеет приоритет. Т.е. если если в черном списке всем запретить (* 0 0 0), то в белом можно будет разрешать избранным – авторизованным по имени пользователя (* имя 0 0) или по IP (* 0 0 PeerIP= 10.1.1.3). Здесь 0 – обозначение пустого поля – в веб-интерфейсе так и вводите, а если напрямую редактируете файл, то просто ставьте;""; или;;.
срабатывает только первое правило, подходящее под маску хоста (в вашем случае «*»). Если нужно разрешить несколько IP, можно использовать сетевые маски, например
PeerIP:Mask= 192.168.1.0:255.255.255.0
или перечислить конкретные IP через OR:
PeerIP= 192.168.1.2 PeerIP= 192.168.1.3 OR PeerIP= 192.168.1.4 OR
Либо использовать IP-авторизацию.
|
Библиотека 
BlueCurve Classic
Clearlooks