Функции безопасности Domino/Notes 6

11.9.3 Web-пользователи из дополнительных каталогов Domino Directory и LDAP-каталогов

При аутентификации Web-клиента на сервере по умолчанию сервер проверяет основной каталог Domino Directory на наличие сертификата клиента в документе Person. Если ваша организация использует дополнительный каталог Domino Directory или LDAP-каталог для проверки сертификатов клиентов, вы можете настроить Domino на проверку в этих дополнительных каталогах. Для этого необходимо настроить дополнительный каталог Domino и LDAP-каталог в качестве доверенных доменов в базе данных Directory Assistance.

Если вы отмечаете домен как доверенный, Domino выполняет поиск пользователя в основном каталоге Domino Directory, после чего осуществляет поиск в доверенном дополнительном каталоге Domino и LDAP-каталогах. При настройке средства Directory Assistance указывается, в каком порядке Domino должен выполнять поиск в дополнительных каталогах.

Кроме того, Domino просматривает основной каталог Domino Directory и дополнительные каталоги, с которыми установлены доверительные отношения, при добавлении SSL-сертификатов клиента в Domino Directory с использованием приложения Domino Certificate Authority. Однако нельзя добавлять сертификаты клиентов в LDAP-каталог, даже если LDAP-каталог установлен на сервере Domino.

Рекомендуется использовать SSL для защиты информации, пересылаемой между сервером и сервером LDAP-каталога.

Иерархическое имя, возвращаемое Domino Directory или LDAP-каталогом, сверяется с правилом доверия в базе данных Directory Assistance, чтобы убедиться в том, что организация и подразделения соответствуют заданному правилу. Например, если возвращаемое имя пользователя имеет вид Dave Lawson/Acme, документ Directory Assistance должен включать правило */Acme.

Также возможен поиск в нескольких каталогах для аутентификации пользователей, применяющих аутентификацию посредством имени и пароля.

В целях управления доступом к серверу Domino клиентами, которые он поддерживает, существуют механизмы аутентификации, дополняющие механизмы аутентификации, установленные по умолчанию. Используется механизм Public Key Checking (Проверка открытого ключа), а также права группы пользователей Allow Access (Разрешить доступ) к серверу. Помимо этого применяется средство Password Checking (Проверка паролей). В остальной части раздела описывается этот аспект аутентификации пользователей, а также объясняется его работа и употребление не только для клиентов Notes, но и для альтернативных клиентов, таких, как iNotes.

11.9.4 Сопоставление имен в Domino

При интеграции существующей среды Domino с другими Web-технологиями через механизм единой регистрации или при использовании средой Domino внешнего LDAP-каталога для аутентификации возможности сопоставления имен в Domino могут быть необходимы для непрерывного использования полных имен Notes/Domino в ACL базы данных Domino.

Ниже представлены некоторые примеры ситуаций, когда может потребоваться сопоставление имен:

• Domino и Portal.

  Когда сервер Domino используется в составе реализации WebSphere Portal, Portal выполняет аутентификацию пользователя по LDAP-каталогу, вследствие чего создается LTPA-токен с иерархическим именем LDAP, например "uid=twor ek,ou=users,o=redbooks,c=us". Когда пользователь осуществляет доступ к почтовому портлету, который должен осуществлять доступ к данным Domino от имени пользователя, в Domino передается такой же LTPA-токен (при условии, что Portal и Domino включены в общий домен LTPA SSO). Однако ACL в почтовой базе данных пользователя будет содержать полное имя Notes, "William Tworek/Cambridge/IBM". Так как LTPA-токен содержит LDAP-имя, Domino не поймет, что это тот же пользователь, и не разрешит доступ к почтовому файлу.
• Domino и внешний LDAP-каталог.

  Если в Domino Directory Assistance включено доверие стороннему LDAP-каталогу для выполнения аутентификации, аутентификация пользователей будет выполняться по LDAP-каталогу и в Domino будет возвращено иерархическое имя LDAP. Если базы данных Domino при этом содержат оригинальные иерархические имена Notes, пользователи не получат доступа к своим базам данных, так как Domino не поймет, что LDAP-имя указывает на этого пользователя.

К счастью, Domino поддерживает некоторые варианты решения этой проблемы, один из которых был впервые реализован в Domino 6:

1. Использование LDAP-имени в ACL базы данных.
2. Включение LDAP DN в качестве "альтернативного" имени в документах Person в Domino. Поддерживается в Domino 5.x и Domino 6.02+.
3. Включение полного отличительного имени Domino в LDAP-каталог. Поддерживается в Domino 6.x посредством новых функций Directory Assistance.

Использование LDAP-имени в ACL базы данных

Этот подход в действительности не является решением для сопоставления имен, а скорее представляет собой изменение ACL в Domino таким образом, чтобы установить доверие к LDAP-именам. При таком подходе потребуется изменить все ACL базы данных таким образом, чтобы они содержали иерархические имена LDAP вместо оригинальных полных имен Notes.

Например, если изначально ACL содержала запись "William Tworek/Cambridge/IBM" с правами менеджера, LDAP-имя будет иметь вид "uid=tworek/ou=users/o=redbooks/c=us". Обратите внимание на то, что при вводе LDAP-имени в ACL Domino следует заменить запятые, используемые в традиционном синтаксисе LDAP, на символы "/".

Такое решение работает, однако оно вызывает большой объем дополнительной работы, связанной с изменением и обслуживанием ACL базы данных.

Включение LDAP DN в качестве "альтернативного" имени в Domino

При данном подходе к постановке имен в соответствие необходимо выполнить обновление всех пользователей в каталоге Domino Directory таким образом, чтобы отличительное имя LDAP каждого пользователя было включено в документ Person в качестве "альтернативного" имени.

Пример использования данного метода представлен на рис. 11.7.

Рис. 11.7. Отличительное имя LDAP, включенное в документ Person

Реализация этого подхода чаще всего осуществляется с использованием одного из инструментов синхронизации каталогов, рассматриваемых в "Стратегии каталогов" . Использование такого инструмента позволяет обеспечить синхронизацию двух каталогов; при этом все изменения имен в LDAP-каталоге будут своевременно отражаться в документах Person каталога Domino, обеспечивая непрерывную постановку имен в соответствие.

Повторимся, что эта опция поддерживается в Domino 5.x и Domino 6.02+. Однако она не работает в Domino 6.0 и 6.01.

Включение полного отличительного имени Domino в LDAP-каталог

Эта последняя опция сопоставления имен в соответствие в Domino требует дополнительного времени для настройки, а также требует изменения LDAP-каталога. Ее действие, в сущности, является обратным действию предыдущей опции, т. е. теперь имя Domino распространяется по LDAP-каталогу.

Для реализации этой опции необходимо выполнить следующие действия:

1. Определите атрибут из LDAP-каталога, который можно использовать, или рассмотрите вариант расширения схемы LDAP для добавления нового атрибута.
2. Наполните LDAP-каталог таким образом, чтобы для каждого LDAP-пользователя в этот атрибут было записано его полное имя Notes.
3. И наконец, обновите документ Domino Directory Assistance и определите имя атрибута в LDAP для Directory Assistance. Это указывает DA, какой атрибут в LDAP следует использовать для выполнения постановки имен в соответствие.

Это изменение в Directory Assistance представлено на рис. 11.8.

Подобно другой опции постановки имен в соответствие, поддержку этой опции можно обеспечивать с использованием инструмента синхронизации каталогов для управления распространением нового LDAP-атрибута в LDAP-каталоге.

Эта опция была впервые реализована в Domino 6, поэтому она поддерживается в Domino 6.x, но не поддерживается в Domino 5.x и более ранних версиях.

Рис. 11.8. Обновление атрибута LDAP для постановки имен в соответствие в Domino Directory Assistance

11.10 Проверка паролей в Domino

Инструмент Password Checking (Проверка паролей) представляет собой средство аутентификации клиентов, обеспечивающее принудительное регулярное изменение пользователями своих паролей и включение защиты базы пользователей. Рассмотрим следующий пример. Если кто-либо каким-то образом получит ID-файл пользователя Notes и будет знать пароль для этого идентификатора Notes, он обычно сможет получить доступ к серверу с применением этой копии идентификатора Notes. Однако при включении функции Password Checking в тот момент, когда пострадавший пользователь изменяет свой пароль в настоящем ID-файле Notes, это средство сообщает об изменении серверу. Если какой-либо злоумышленник после этого попытается получить доступ к украденной копии ID-файла Notes, ему будет отказано в доступе к серверу.

При включении администратором функции Password Checking он может установить опцию Required Change Interval (Интервал обязательного изменения) (изменяется в днях), которая принуждает пользователей изменять пароли для своих ID-файлов Notes в течение заданного интервала времени. С приближением даты истечения срока действия пароля клиент Notes просит пользователя изменить свой пароль. Помимо интервала изменения администратор может задать опцию Grace Period (Период отсрочки). Он содержит значение (опять же измеряемое в днях), которое указывает временной интервал (по окончании срока действия пароля), в течение которого пользователь должен изменить свой пароль. Как в R5, так и в Version 6 по истечении интервала изменения и периода отсрочки пользователю будет отказано в доступе к серверу до тех пор, пока администратор не переустановит его учетную запись в документе Person пользователя. Это отличается от способа работы клиентов Notes до версии R4.67. Дальнейшее описание относится к клиентам R5 и Version 6.

11.10.1 Система проверки паролей Notes и Domino

Систему проверки паролей Notes и Domino можно разделить на два основных компонента: клиент Notes и сервер Domino (интеграцией iNotes мы займемся немного позже). На данном этапе важно отметить, что основная часть работы, связанная с принудительной блокировкой сервера Domino (вследствие выполнения средства проверки паролей), в действительности выполняется на клиенте Notes. Прежде чем описывать полностью весь рабочий процесс, важно составить начальное описание составляющих его компонентов.

При включенном идентификаторе пользователя Notes пользователям могут выдаваться уведомления о приближающемся окончании срока действия пароля, прежде чем они щелкнут по значку базы данных или подключатся к серверу. Это выполняется на клиенте Notes, так как ID-файл пользователя Notes содержит всю необходимую информацию для определения даты окончания срока действия пароля.

Информация для проверки паролей в ID-файле пользователя Notes

Относительно проверки паролей ID-файл пользователя Notes содержит следующие элементы:

• дату последнего изменения пароля;
• количество дней до истечения срока действия текущего пароля;
• максимальное количество дней, в течение которых пользователь может использовать текущий пароль без его изменения;
• текущий пароль;
• последние 49 использовавшихся паролей и даты окончания их срока действия.

Информация для проверки паролей в Domino Directory

Относительно проверки паролей Domino Directory содержит элементы, представленные в табл. 11.9 и 11.10.

Запись информации на стороне сервера в идентификатор пользователя Notes

В связи с необходимостью согласования действий сервера и клиента необходимо установить на сервере некоторые параметры. Они описываются ниже.

1. Включение проверки паролей. Выполняется путем редактирования документа Server для сервера, который требуется включить. Откройте соответствующий документ Server и перейдите на вкладку Security (Безопасность), как показано на рис. 11.9.
   

   
   Рис. 11.9. Включение проверки паролей

   В поле Check passwords on Notes IDs (Проверять пароли в идентификаторах Notes) включите Enabled (Включено).

   Это действие включает функцию проверки паролей. Она вступает в действие только после перезапуска сервера, так как при этом выполняется чтение документа Server.

   После перезапуска сервера, когда клиент Notes открывает рабочий сеанс с сервером Domino, соответствующий документ которого был изменен таким образом, клиент Notes осуществляет чтение этого поля. Если этот параметр включен, то функции проверки паролей на стороне клиента включаются при подключении к определенному серверу.
2. Назначение пользователей, для которых требуется выполнять проверку паролей через AdminP.

   Следует определить пользователей, для которых нужно включить проверку паролей. После определения этих пользователей нужно выполнить приведенные ниже действия для включения каждого пользователя через документ Person. Эти действия должен выполнять администратор с соответствующим идентификатором и соответствующими правами:

   1. В Domino Directory через представление People View следует определить одного или нескольких пользователей, для которых нужно включить функцию проверки паролей.
   2. В меню следует выбрать Actions (Действия) > Set Password Fields (Назначение полей паролей).
   3. Notes выведет сообщение Set Password Fields (Назначение полей паролей) с текстом You are about to set the password fields for the selected person records. Do you want to continue? (Это действие приведет к назначению полей паролей для выбранных записей пользователей. Продолжить?). Для продолжения нажмите Yes (Да).
   4. Выводится еще одно диалоговое окно. В списке Check Password (Проверка пароля) выберите Check password (Проверять пароль), после чего введите значения параметров Required Change Interval (Интервал обязательного изменения) и Grace Period (Период отсрочки); значения этих полей задаются в днях. Если, например, вам требуется, чтобы пользователи выполняли изменение паролей каждые 90 дней, а также требуется дать пользователям дополнительные 30 дней отсрочки, введите 90 и 30 дней соответственно (в период отсрочки пользователь не сможет получить доступ к серверу, однако сможет изменить свой пароль без помощи администратора для разблокировки своей учетной записи).
   5. Нажмите OK. Запрос Administration Process (adminp) записывается в базу данных запросов администрирования сервера Domino (Domino Server Administration Request Database, admin4.nsf), и клиент Notes выведет диалоговое окно Completed Successfully (Выполнено успешно), сообщающее о том, что запрос был успешно передан в базу данных запросов администрирования сервера.
3. Наблюдение за запланированной задачей Adminp для проверки паролей.

   Откройте базу данных запросов администрирования, после чего вы сможете увидеть запрос Set password information (Настройка информации о паролях).

   При открытии документа, содержащего запрос Adminp, выводится имя запроса, а также определенные параметры. Пример из п. 2 представлен на рис. 11.10.

   

   
   Рис. 11.10. Запланированная задача Adminp для проверки паролей
4. Наблюдение за выполнением задачи Adminp для проверки паролей.

   После выполнения задачей Adminp запроса на изменение в базу данных запросов администрирования записывается документ подтверждения, как показано на рис. 11.11.

   

   
   Рис. 11.11. Задача Adminp для проверки паролей

   Открыв документ Person для этого пользователя, вы можете убедиться в том, что поля Check Password (Проверять пароль), Change Interval (Интервал изменения) и Grace Period (Период отсрочки) были заполнены должным образом.

Обратите внимание на то, что поле Password digest (Дайджест пароля) в документе Person осталось пустым. Это не ошибка, так как пользователь не выполнял аутентификацию на сервере с момента включения проверки паролей.

Когда пользователь пытается получить доступ к серверу, используя свой идентификатор пользователя Notes (и после аутентификации сертификата), клиент Notes проверяет, включена ли проверка паролей на сервере, и, если она включена, проверяет, включена ли проверка паролей в документе Person. В нашем примере эти проверки возвратили значение true.

Помимо этих проверок, также выполняется проверка в базе данных admin4.nsf на наличие незавершенных запросов. В нашем примере клиент определяет незавершенный запрос Adminp и копирует параметры Grace Period (Период отсрочки) и Change Interval (Интервал изменения) в ID-файл Notes. После их принятия клиент создает новый запрос на изменение в базе данных admin4, подтверждающий, что идентификатор пользователя Notes получил параметры Grace Period (Период отсрочки) и Change Interval (Интервал изменения). Этот запрос теперь также включает дайджест текущего пароля из ID-файла и текущую дату.

Используя встроенный инструмент для изучения идентификатора пользователя Notes, можно увидеть, что установлена новая структура, как показано в примере 11.1.

PWD_KEY_HDR
Type: 0000
Version: 0000
LastChanged: TIMEDATE
Innards: 0025 69DC 0039 822B
Text format: 22/01/2001 10:28:08
ExpirationDays: 0000 005A
NextExpirationDays: 0000 005A
NumDomains: 0001
NumOldPwds: 0001
OldPwdTotLen: 0214

Когда Adminp впоследствии обрабатывает новый запрос на изменение, параметр Password digest (Дайджест пароля) сохраняется в документе Person пользователя вместе с параметром Last Changed Date (Дата последнего изменения), отражая инициализацию пароля. Чтобы в этом убедиться, можно просмотреть требуемый документ Person, как показано на рис. 11.12.

Рис. 11.12. Документ Person пользователя, для которого отрегулирована настройка пароля

После того как мы убедились в том, что документ Person содержит дайджест текущего пароля пользователя, проверка паролей для этого идентификатора пользователя Notes и для этого сервера настроена и выполняется.

После синхронизации информации на сервере и ID-файла пользователя Notes можно рассмотреть, каким образом определяется время блокировки доступа пользователя к серверу и, что более важно, когда и как пользователю сообщается о приближающейся блокировке.