Функции безопасности Domino/Notes 6
Аутентификация клиентов с использованием удаленного LDAP-каталога
Для аутентификации клиентов с использованием удаленного LDAP-каталога доступны следующие возможности:
- настраиваемые фильтры поиска для управления фильтром поиска, используемым для просмотра имен в удаленном LDAP-каталоге;
- сопоставление имен LDAP – Domino, что позволяет пользователям осуществлять аутентификацию с применением отличительных имен Notes, а не отличительных имен LDAP
Вызов Directory Assistance для аутентификации с использованием LDAP-каталога
Процесс аутентификации начинается, когда клиент пытается получить доступ к приложению или базе данных Domino, требующей аутентификации. Пользователю выдается окно запроса пароля, куда пользователь вводит идентификатор и пароль. Затем процесс аутентификации пытается найти запись, соответствующую введенному идентификатору, в каталоге Domino Directory. Если запись найти не удалось, тогда используется список каталогов – Directory Catalog (если он существует), после чего выполняется проверка через Directory Assistance.
Если процесс аутентификации обнаруживает соответствие идентификатору пользователя (при этом поиск соответствия выполняется в нескольких полях), процесс аутентификации возвращает отличительное имя (Distinguished Name, DN), связанное с записью соответствующего пользователя. После этого отличительное имя и пароль, предоставленные пользователем, применяются для создания аутентифицированной связи с каталогом, в котором была найдена запись. Если создание связи прошло успешно, это означает, что пара "отличительное имя/учетные данные" является корректной, после чего пользователь является аутентифицированным. В случае сбоя при создании связи процесс аутентификации продолжает поиск записей, соответствующих предоставленному идентификатору пользователя. Он продолжает этот процесс, пока не найдет первую запись с совпадающей парой "идентификатор пользователя/пароль" или пока не будут просмотрены все сконфигурированные каталоги.
При этом если запись Person для одного и того же человека содержится в каталоге Domino Directory и в каталоге стороннего производителя, то, если учетные данные сохранены только в каталоге стороннего производителя, аутентификация выполняется в этом каталоге. Это также означает, что в качестве идентификационных данных пользователя при аутентификации используется отличительное имя, возвращенное каталогом, содержащим совпадающую запись, так что, если пользователь выполняет аутентификацию в каталоге стороннего производителя, возвращается отличительное имя, хранящееся в этом каталоге стороннего производителя, которое должно быть указано в ACL базы данных, к которой пользователь пытается получить доступ.
11.6.4 Расширенные таблицы управления доступом
Новое в Domino 6
Расширенная таблица управления доступом (ACL) является дополнительной функцией управления доступом к каталогу, доступной для каталога, созданного на основе шаблона PUBNAMES.NTF, – Domino Directory или Extended Directory Catalog. Расширенные ACL дополняют ACL базы данных и ограничивают доступ пользователей к определенным разделам Domino Directory или Extended Directory Catalog. Также они применяют защиту базы данных при просмотрах имен Notes-клиентов, а также при анонимном доступе для LDAP-поиска.
Расширенная ACL привязана к ACL базы данных, и доступ к ней осуществляется через диалоговое окно Access Control List (Таблица управления доступом) клиента Notes 6 или Domino Administrator 6. Расширенные ACL используются для применения ограничений общего доступа, разрешенного пользователю таблицей управления доступом базы данных; их нельзя употреблять для расширения доступа, разрешенного таблицей управления доступом базы данных. Следует употреблять расширенные ACL для назначения доступа:
- ко всем документам с иерархическими именами в определенном расположении в иерархии имен каталогов, например ко всем документам, имена которых заканчиваются на OU=West/O=Acme;
- ко всем документам определенного типа, например ко всем документам Person;
- к определенному полю в документе определенного типа;
- к определенному документу.
Расширенные ACL позволяют:
- делегировать функции администрирования Domino, например позволяющие группе администраторов управлять только теми документами, которые относятся к определенному подразделению;
- установить доступ к определенным фрагментам содержимого каталога;
- с легкостью устанавливать глобальный доступ к документам и полям через единый источник, вместо того чтобы осуществлять управление доступом через поля Readers и Authors ;
- управлять доступом пользователей к каталогу с применением поддерживаемых протоколов: Notes (NRPC), Web (HTTP), LDAP, POP3 и IMAP. Примечание. Серверные процессы, в частности задача Router, не применяют ограничения, заданные расширенными ACL. Однако что касается задачи Router, то можно ограничить для некоторых пользователей отправку почты группе путем редактирования поля Readers для группы, включив в него имена только тех пользователей, которым вы хотите разрешить отправку почты группе. Если пользователи, не включенные в поле Readers, попытаются отправить почту группе, Router не выполнит доставку почты. Доступ, установленный для пользователя в расширенной ACL, не может расширять доступ, установленный в ACL базы данных, включая привилегии и роли, установленные в ACL базы данных. Например, если ACL базы данных разрешает пользователю осуществлять доступ только на уровне Reader, нельзя применять расширенную ACL для включения доступа на уровне Write. Также если для пользователя не задана роль User Creator в ACL базы данных, нельзя с применением расширенных ACL разрешить пользователю доступ к документам Person на уровне Create.
Доступ, установленный через средство безопасности в дизайне базы данных, также ограничивает доступ, который можно определить через расширенные ACL. Например, если поле Readers в определенной форме не разрешает пользователю осуществлять чтение полей в документах, созданных с применением этой формы, назначение пользователю доступа уровня Browse к форме в расширенной ACL не замещает параметры доступа, заданные в поле Readers.
Планирование управления доступом к каталогу
Для управления общим доступом пользователей и серверов к Domino Directory следует применять ACL базы данных. Кроме того, можно использовать расширенные ACL для уточнения ACL базы данных и дополнительного ограничения доступа к определенным фрагментам каталога. Расширенная ACL доступна только для Domino Directory и Extended Directory Catalog.
При планировании управления доступом к каталогу следует рассмотреть следующие вопросы:
- Требуется ли назначить администраторов на определенные роли администрирования в Domino Directory? Если администраторы в вашей компании имеют особые административные обязанности, следует назначить администраторов только на те роли администрирования в ACL, которые соответствуют их обязанностям. Если администраторы в вашей компании выполняют все административные задачи, назначьте их на все роли.
- Требуется ли использовать расширенную ACL? Одним из оснований для использования расширенной ACL является ограничение доступа между организациями к каталогу, содержащему информацию нескольких организаций или подразделений.
- Требуется ли разрешить анонимный доступ к каталогу? По умолчанию используется документ Configuration Settings домена в каталоге Domino Directory для управления анонимным доступом для LDAP-поиска. По умолчанию анонимные пользователи LDAP имеют доступ уровня Read к определенному набору атрибутов.
Запись Anonymous (Анонимный) в ACL базы данных каталога по умолчанию имеет уровень доступа No Access (Нет доступа) и управляет анонимным доступом для всех пользователей, кроме пользователей LDAP. При употреблении расширенной ACL запись Anonymous (Анонимный) в ACL базы данных и расширенной ACL также управляют анонимным доступом к LDAP. Обычно записи Anonymous (Анонимный) не назначается уровень доступа выше Reader.
11.6.5 LDAP-каталоги
Протокол LDAP (Lightweight Directory Access Protocol) является стандартным интернет-протоколом для поиска и управления записями в каталоге. Domino и Notes обеспечивают поддержку LDAP с использованием следующих инструментов:
- службы LDAP, позволяющей серверу Domino работать в качестве сервера LDAP-каталога и обрабатывать LDAP-запросы;
- учетных записей LDAP на клиентах Notes, что позволяет пользователям Notes выполнять LDAP-поиск адресов в LDAP-каталогах;
- средства Directory Assistance, позволяющего серверу Domino использовать удаленный LDAP-каталог для аутентификации клиента или для просмотра участников групп при авторизации в базе данных.
Конфигурирование фильтров поиска в документе Directory Assistance для удаленного LDAP-каталога
Новое в Domino 6
Можно использовать собственные LDAP-фильтры для замещения встроенных фильтров поиска, используемых средством Directory Assistance при поиске в LDAP-каталоге. Их можно применять для просмотров почтовых адресов, просмотров учетных данных аутентификации клиента и просмотров авторизации группы.
Управление использованием фильтров для поиска в каталоге осуществляется через поле Type of search filter to use (Тип используемого фильтра поиска) в документе Directory Assistance. Возможные опции перечислены в табл. 11.3.
Определение собственных фильтров поиска
Вам может потребоваться определить собственные фильтры поиска, если поиск не дает результатов или если возвращаемые результаты относятся к неправильным записям. Такая ситуация может возникнуть, если сервер удаленного LDAP-каталога применяет нестандартную схему.
При выборе опции "Custom" в поле Type of search filter to use (Тип используемого фильтра поиска) выводятся три поля, употребляемые для определения собственных фильтров поиска, как показано в табл. 11.4.
Чтобы определить собственные фильтры поиска, нужно иметь представление о допустимых фильтрах поиска, описанных в RFC 2251 и 2254.
Синтаксис собственных фильтров поиска LDAP
Чтобы определить собственный фильтр поиска, следует добавлять в стандартные фильтры поиска LDAP параметры, представляющие фрагмент имен, которые требуется найти.
| Фрагмент имени | Определение | Пример фрагмента имени (выделен жирным) | Параметр, представляющий фрагмент имени |
|---|---|---|---|
| Имя | Набор символов от первого символа до первого пробела или знака препинания | Alex M Davidson | %a |
| Фамилия | Набор символов от последнего пробела или знака препинания до последнего символа | Alex M Davidson | %z |
| Полное имя | Имя целиком | Alex M Davidson | %* |
| Локальный элемент | Локальный элемент почтового адреса (RFC 822) | amd@acme.com | %l |
| Элемент домена | Элемент домена почтового адреса (RFC 822) | amd@acme.com | %d |
| Искомое имя | Формула фильтра поиска в документе Directory Assistance | Фильтр поиска, используемый для поиска имени |
|---|---|---|
| Alex M Davidson | (|(gn=%a)(sn=%z)(cn=%*)(mail=%l)) | (|(gn=Alex)(sn=Davidson)(cn=Alex M Davidson)(mail="")) |
| amd | (EmpID=%*) | (EmpID=amd) |
| amd | (EmpID=%z) | (EmpID="") |
| amd | (mail=%*@acme.com) | l |
| amd | (mail=%*@*) | (mail=amd@*) |
| amd@acme.com | (mail=*@%d) | (mail=*@acme.com) |
| amd@acme.com | (mail=%*) | (mail=amd@acme.com) |
| amd@acme.com | (uid=%l) | (uid=amd) |
| blue | (color=%*) | (color=blue) |
11.7 Синхронизация интернет-паролей и паролей Notes
Новое в Domino 6
Можно осуществлять синхронизацию интернет-пароля пользователя, хранящегося в записи Person в каталоге Domino Directory с Notes-паролем пользователя. Это означает, что пользователи могут применять один пароль для входа на сервер Domino через клиент Notes и через Web-браузер. Вы можете выполнить синхронизацию паролей Notes и интернет-паролей для отдельных пользователей во время регистрации пользователя или включить синхронизацию интернет-паролей и паролей Notes для нескольких пользователей на сервере посредством применения документа политики параметров безопасности.
Дополнительные сведения о политиках см. в разделе 11.1.5, "Политики и документы политик".
Изменение пользователем пароля Notes приводит к изменению интернет-пароля.
Важно! Администраторы должны помнить о том, что пользователи, серьезно относящиеся к безопасности, могут обойти синхронизацию паролей Notes и интернет-паролей через диалоговое окно User Security (Безопасность пользователя) и выбрать применение различных паролей в качестве паролей Notes и интернет-паролей. Как ни парадоксально, но это обеспечивает более высокий уровень безопасности и обычно не представляет проблемы. Дополнительные сведения о диалоговом окне User Security (Безопасность пользователя) см. в разделе 11.14, "Безопасность клиента Notes".
11.8 Восстановление идентификаторов Notes
Первым этапом в настройке восстановления ID-файла Notes является настройка централизованной почтовой или базы данных mail-in для хранения зашифрованных резервных копий ID-файлов Notes. Затем необходимо ввести информацию о том, какие администраторы (называемые администраторами центра восстановления -Recovery Authorities) имеют право восстанавливать идентификаторы Notes.
Таблица управления доступом централизованной почтовой или базы данных mail-in должна иметь как минимум следующие настройки:
- -Default- и Anonymous должны иметь уровень доступа No Access;
- все администраторы центра восстановления должны иметь по меньшей мере доступ на уровне Reader.
Корректное определение этой ACL необходимо для защиты резервных копий идентификаторов Notes, которые будут здесь храниться. Поэтому следует уделить большое внимание определению ACL.
Для настройки восстановления идентификаторов ID необходимо выполнить следующие действия:
- В Domino Administrator выберите Configuration (Конфигурирование), после чего выберите Certification (Сертификация).
- Выберите Edit Recovery Information (Редактирование информации восстановления).
- В диалоговом окне Choose a Certifier (Выбор сертификатора) выберите Server, после чего выберите имя сервера регистрации в Domino Directory (только если не выводится корректное имя сервера).
- Выберите сертификатор, для которого выполняется создание информации восстановления.
- При использовании центра сертификации на основе сервера выберите Use the CA process (Использовать процесс CA), после чего выберите сертификатор из выпадающего списка. Для того чтобы иметь возможность изменить информацию о восстановлении идентификаторов, вы должны быть администратором центра сертификации.
- Если не используется центр сертификации на основе сервера, выберите Supply certifier ID and password (Предоставлять идентификатор и пароль сертификатора). Если не выводится путь и имя файла идентификатора сертификатора, выберите Certifier ID (Идентификатор сертификатора), после чего выберите ID-файл сертификатора и введите пароль.
- Нажмите OK. Появится диалоговое окно Edit Master Recovery Authority List (Редактирование главной копии списка администраторов центра восстановления).
- Введите количество администраторов центра восстановления, требуемых для восстановления ID-файла. Рекомендуется выбрать по меньшей мере три администратора.
- Нажмите Add (Добавить) и выберите имена администраторов, назначенных на роль администраторов центра восстановления.
- Укажите, требуется ли использовать существующий почтовый ящик для информации восстановления, или же нужно создать новый:
- Если у вас уже есть почтовая или база данных mail-in, настроенная на хранение информации восстановления, выберите I want to use an existing mailbox (Требуется использовать существующий почтовый ящик). Нажмите Address (Адрес) и выберите базу данных из Domino Directory.
- Если требуется создать новую базу данных для хранения информации восстановления, нажмите I want to create a new mailbox (Требуется создать новый почтовый ящик). В диалоговое окно Create New Mailbox (Создание нового почтового ящика) введите имя сервера, на котором требуется создать базу данных, и заголовок базы данных. Можно использовать имя файла, создаваемое на основе заголовка базы данных, или задать новое имя.
Примечание. При внесении изменений в этом диалоговом окне кнопка Export (Экспорт) становится недоступной. Нельзя экспортировать информацию восстановления, пока не будет сохранена новая или обновленная информация.
- Нажмите OK.
- При использовании центра сертификации на основе сервера, следует ввести в консоли сервера
load ca
Это запустит процесс CA с новой информацией восстановления или обновит этот процесс, если он уже запущен. После этого для обработки запроса на добавление информации восстановления в сертификатор следует ввести
tell adminp process all
Примечание. При создании дополнительных сертификаторов Notes на уровне организации (O), следует обязательно выполнить для них кросс-сертификацию с первоначальным сертификатором Notes, прежде чем настраивать параметры информации восстановления.
После этого пользователи получат почту Notes, содержащую информацию восстановления. Каждый пользователь должен принять ее, выбрав Action (Действие) -> Accept Recovery Information (Принять информацию восстановления), и сохранить информацию в своем ID-файле Notes. В то же время резервная копия информации восстановления записывается в резервную базу данных идентификаторов.
При регистрации администратором нового пользователя Notes после выполнения этой операции резервная копия ID-файла Notes автоматически записывается в резервную базу данных идентификаторов.