Регистрация...

Почтовый сервер Eserv // EservAuth

oldwiki // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Новости
15.05.2012
Eserv504
15.05.2012
ActiveSync
01.04.2012
Eproxy508
25.03.2012
Eserv503
26.02.2012
Eserv502
08.02.2012
UMI.CMS
22.12.2011
Eserv431
20.12.2011
Eproxy507
15.11.2011
Eproxy506
19.09.2011
Eproxy505
08.09.2011
Eserv430
06.09.2011
Lightning
19.07.2011
PoweredBy
16.07.2011
IPv6
08.07.2011
Eproxy5beta1
17.06.2011
IPv6DNS
13.06.2011
IPv6Mail
21.03.2011
Eserv428
22.10.2010
Eserv426
22.10.2010
SSL
22.04.2010
Eserv423
20.04.2010
Eserv4WhatsNew
19.04.2010
EservLDAP
19.04.2010
EservDHCP
19.04.2010
EservRubricator
08.04.2010
EservDNS
08.04.2010
NSСI
08.04.2010
WPAD
27.03.2010
Eserv422
27.03.2010
Eserv4Docs
26.03.2010
Eserv4FAQ
21.03.2010
EservIrc
05.03.2010
Eserv421
05.03.2010
HttpProxy
02.03.2010
EservVideo
02.12.2009
Eserv4Wiki
02.12.2009
Eserv4acWEB
02.12.2009
PopPull
22.11.2009
PigMailPigProxy2/WhatsNew
22.11.2009
PigMail/WhatsNew
22.09.2009
FossilEservHowTo
22.09.2009
SourceCodeManagement
22.09.2009
FossilScm
16.09.2009
SendEmail
08.09.2009
RoundCube
07.05.2009
GitScm
07.05.2009
GitEservHowTo
06.05.2009
SunBird
06.05.2009
WebDav
20.04.2009
Etelnet

Авторизация пользователей в Eserv/3 и Eproxy/3

Оглавление документа

Используемая терминология

Для проверки прав доступа пользователей к ресурсам на серверах 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 — выбор способа авторизации в зависимости от домена. При авторизации выполняется следующая последовательность действий:
  1. предварительный "отсев" по черным и белым спискам по IP для конкретного сервиса
  2. для протоколов, допускающих анонимную работу (SMTP, HTTP, proxy) предварительная IP-авторизация
  3. явная авторизация, если переданы пользовательские имя/пароль/домен
    1. если домен не задан, то установка домена по умолчанию по списку Lists[DomainIP] либо Server[DefaultDomain], если в DomainIP не указано соответствие для текущего IP
    2. по домену в списке локальных доменов Lists[LocalDomains] находится имя источника авторизации, а если домен не найден, то используется метод авторизации по умолчанию — AUTH[AuthMethod]
    3. по имени источника в списке источников авторизации AUTH[AuthSources] ищется метод авторизации и его параметры, а если источник не наден, то используется метод авторизации по умолчанию — AUTH[AuthMethod]
    4. выполняется правило DoLogin для найденного источника авторизации. При успешной авторизации переменная UID содержит ненулевое число. Далее это значение может использоваться при анализе прав доступа к конкретному серверу/ресурсу. Правило "LoggedAs: user" возвращает истину, если имя учетной записи user, и UID не равен нулю.
    5. ...

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-авторизацию.

См. также FAQ
 
Комментарии к этой версии (18.02.2004 22:44) [~AndreyCherezov]
Работает на Eserv/5.05567 (10.02.2020)