|
Базовая информация по аутентификации администраторов на Enterprise Сервере приведена в разделе Аутентификация администраторов. |
Аутентификация при использовании Active Directory
Конфигурируется только разрешение использования и порядок в списке аутентификаторов: тэги <enabled/> и <order/> в auth-ads.xml.
Принцип работы:
1.Администратор задает имя пользователя и пароль в одном из следующих форматов:
◆username,
◆domain\username,
◆username@domain,
◆LDAP DN пользователя.
2.Сервер регистрируется с этим именем и паролем на доменном контроллере по умолчанию (или доменном контроллере для домена, указанного в имени пользователя).
3.Если не удалось зарегистрироваться, осуществляется переход к следующему механизму аутентификации.
4.Определяется LDAP DN зарегистрированного пользователя.
5.У объекта с вычисленным DN читается атрибут DrWeb_Admin. Если он установлен в FALSE - неуспех и переход к следующему механизму аутентификации.
6.Читается атрибут DrWeb_AdminReadOnly. Если он установлен в TRUE, администратор имеет права только на чтение.
7.Читается атрибут DrWeb_AdminGroupOnly. Если он установлен в TRUE, администратор имеет права только на управление определенными группами.
8.Читается атрибут DrWeb_AdminGroup, который должен содержать список групп для управления данным администратором.
9.Если на этом этапе какие-либо атрибуты не определены, их поиск осуществляется в группах, в которые входит данный пользователь. Для каждой группы просматриваются ее родительские группы (стратегия поиска - вглубь).
|
В случае любой ошибки осуществляется переход к следующему механизму аутентификации. |
Утилита drwschema-modify.exe (входит в дистрибутив Сервера, располагается в каталоге bin каталога установки Сервера) создает новый класс объектов DrWebEnterpriseUser для Active Directory и описывает новые атрибуты для данного класса.
Атрибуты имеют следующие OID в Enterprise пространстве:
#define DrWeb_enterprise_OID "1.3.6.1.4.1" // iso.org.dod.internet.private.enterprise |
Редактирование свойств пользователей Active Directory осуществляется вручную на сервере Active Directory (см. п. Аутентификация администраторов).
Алгоритм разбора атрибутов при авторизации:
1.Читаются атрибуты пользователя.
2.Если атрибут DrWebAdmin установлен в TRUE, то:
2.1.Если не хватает части атрибутов и атрибут DrWebInheritPermissions установлен в TRUE, то недостающие атрибуты считываются из групп. Как только все атрибуты заданы - процедура обхода групп завершается. Таким образом, чем раньше были считаны атрибуты, тем больше у них приоритет. Доступ администратору разрешается.
2.2.Если не хватает части атрибутов и атрибут DrWebInheritPermissions установлен в FALSE (или не определен), доступ администратору разрешается.
2.3.Если все атрибуты заданы, доступ администратору разрешается.
3.Если атрибут DrWebAdmin установлен в FALSE, доступ администратору запрещается.
4.Если атрибут DrWebAdmin не задан, то:
4.1.Если атрибут DrWebInheritPermissions принимает значение TRUE, то считываются атрибуты из групп. Далее аналогично шагу 2.
4.2.Если атрибут DrWebInheritPermissions принимает значение FALSE (или не задан) аналогично шагу 3.
Аутентификация при использовании LDAP
Настройки приводятся в файле конфигурации auth-ldap.xml.
Основные теги конфигурационного файла:
◆<enabled/> и <order/> - аналогично варианту для Active Directory.
◆<server/> задает адрес LDAP-сервера.
◆<user-dn/> определяет правила трансляции имен в DN с использованием DOS-подобных масок.
В теге <user-dn/> допускается использование символов подстановки:
•* заменяет последовательность любых символов кроме . , = @ \ и пробелов;
•# заменяет последовательность любых символов.
◆<user-dn-expr/> определяет правила трансляции имен в DN с использованием регулярных выражений.
Например, одно и то же правило в разных вариантах:
<user-dn user="*@example.com" dn="CN=\1,DC=example,DC=com"/>
<user-dn-expr user="(.*)@example.com" dn="CN=\1,DC=example,DC=com"/>
\1 .. \9 определяют место подстановки в шаблоне значений *, # или выражений в скобках.
Исходя из данного принципа: если указано имя пользователя в виде login@example.com, то после трансляции получится DN: "CN=login,DC=example,DC=com".
◆<user-dn-extension-enabled/> разрешает выполнение Lua-скрипта ldap-user-dn-translate.ds (из каталога extensions) для выполнения трансляции имени пользователя в DN. Данный скрипт выполняется после попыток применения всех правил user-dn, user-dn-expr в случае, если не найдено ни одно подходящее правило. У скрипта один параметр - введенное имя пользователя. Скрипт возвращает строку, содержащую либо DN, либо ничего. В случае, если не подошло ни одно правило и скрипт не разрешен или не вернул ничего, то введенное имя пользователя используется как есть.
◆Атрибуты LDAP-объекта для DN, полученного в результате трансляции, и их возможные значения могут быть переопределены тэгами (указаны значения по умолчанию):
<!-- DrWebAdmin attribute equivalent (OID 1.3.6.1.4.1.29690.1.3.1) --> |
В качестве значений параметров true-value/false-value задаются регулярные выражения.
◆Если остались неопределенные значения атрибутов администратора, то в случае задания в конфигурационном файле тэга <group-reference-attribute-name value="memberOf"/>, значение атрибута memberOf рассматривается как список DN групп, в которые входит данный администратор, и поиск нужных атрибутов по этим группам ведется также, как в случае с использованием Active Directory.