Усовершенствования, связанные с восстановлением ID

3.1.3 Notes ID

В основе Notes PKI лежит идентификатор Notes (Notes ID). Notes ID представляет собой небольшой файл (его размер - несколько килобайтов), содержащий многое из того, что является необходимым для использования возможностей PKI, встроенных в клиент Notes. В этом подразделе мы рассмотрим эти возможности и расскажем о разных типах Notes ID, заложив основу для понимания объяснений восстановления Notes ID, приводимых ниже в этой лекции.

ID-файлы сертификатора, сервера и пользователя

Notes ID, по сути, является "контейнером" для сертификатов и ключей шифрования. Существует 3 разных типа Notes ID:

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

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

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

Из-за того, что ID сертификатора может применяться для генерации ID серверов и пользователей, ему нужно обеспечивать более надежную защиту, чем другим типам. Храните эти идентификаторы на флоппи-дисках и помещайте их в безопасное место, а не на жесткий диск сервера. В Domino 6 стало возможным использовать сервер сертификатов Domino 6 certificate authority (CA), который позволяет администратору избежать циркуляции сертификационных ID при их употреблении.

В Domino ID используются для идентификации пользователей и контроля доступа к серверам. ID сертификатора, сервера и пользователя содержит следующую информацию:

Имя владельца. Файл пользовательского ID может содержать одно альтернативное. имя (на другом языке). Файл ID сертификатора может содержать несколько альтернативных имен.

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

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

Унаследованные сертификаты. Сертификат от каждого сертификатора-предшественника (как минимум один от сертификатора организации и по одному для. каждого сертификатора подразделения).

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

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

(Дополнительно, только для клиентов Notes.) Интернет-сертификаты. Интернет-сертификат применяется для создания безопасных SSL-соединений и шифрования и подписи почтовых сообщений S/MIME. Интернет-сертификат выпускается. сертификационным органом certificate authority (CA) и удостоверяет идентичность пользователя. В этом сертификате хранится личный ключ пользователя, связанный с данным интернет-сертификатом.

Наконец, личный ключ и ключи шифрования в ID-файле шифруются ключом, сформированным на основе пароля пользователя, чтобы только владелец имел доступ к идентификатору. Общедоступная информация, такая, как имя пользователя и общий ключ, не шифруется.

На рис. 3.2 показана структура Notes ID, в которой есть как стандартная часть, создаваемая для каждого Notes ID, так и необязательная (дополнительная) часть (которую можно добавить в Notes ID позже).

Здесь нужно обратить внимание на 2 момента:

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

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

Сертификаты Notes

При аутентификации Lotus Notes в основном используются сертификаты Notes, которые хранятся в Notes ID.

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

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

Чтобы обеспечить установление доверительных взаимоотношений, в сертификатах должны содержаться несколько видов информации. Сертификат Notes, как и Notes ID, содержит несколько элементов, в частности:

Имя сертификатора, выпустившего сертификат.

Имя пользователя или сервера, для которого выпущен сертификат.

Общий ключ, хранящийся как в Domino Directory, так и в ID-файле. В Notes общий ключ (public key) используется для зашифровывания сообщений, посылаемых владельцу общего ключа, и для проверки подписи владельца ID.

Цифровую подпись.

Дату окончания действия сертификата.

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

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

(рис 3.3) Структура сертификата Notes

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

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

Пароли Notes

Главное назначение и область применения Notes ID - это аутентификация. Мы не собираемся здесь описывать весь процесс аутентификации с использованием Notes ID. Лучше вам обратиться за этим к предыдущей публикации этой серии, Lotus Security Handbook, SG24-70 17.

Давайте рассмотрим основы использования паролей и узнаем, почему потерянный пароль делает Notes ID совершенно бесполезным.

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

В отношении пароля Notes ID существует определенная путаница. Он применяется исключительно для того, чтобы разблокировать файл Notes ID пользователя, и ни для чего больше. Для самой аутентификации пользователя применяется пара ключей, содержащаяся в этом файле.

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

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

3.2 Восстановление Notes ID

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

Далее в этой книге вместо "Notes ID" мы будем употреблять термин "ID", поскольку мы обсудили его выше и ассоциация ID с Notes ID у вас должна теперь присутствовать.

3.2.1 Основные наблюдения

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

Приведенные инструкции относятся к стандартным сертификаторам Notes и к пользовательским ID-файлам, но не к интернет-сертификатам и не к файлам кольца для ключей (key ring).

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

Многие возможности Domino, описанные в этой лекции (и в некоторых других лекциях), требуют некоторого времени (разного в разных ситуациях). Например, после создания нового пользователя этот пользователь иногда не может войти в систему немедленно, а должен подождать, пока новый ID будет зарегистрирован процессом СА. Если изменяется список разрешающих восстановление лиц в сертификаторе, новый список загружается в пользовательские ID-файлы по прошествии некоторого времени. Эти задержки могут составлять несколько часов. Если вам кажется, что определенный этап процесса завершился неудачей, подождите полдня, а затем попробуйте еще раз.

В связи с предыдущим пунктом следует отметить, что команды tell adminp process all и tell ca show queue* не всегда отображают или очищают отложен ные элементы заданий, относящиеся к этим возможностям. Процесс СА в Domino. выполняет эту работу по своему расписанию и без уведомлений.

3.2.2 Общий обзор восстановления ID

Процесс восстановления ID основывается на том, что Domino хранит зашифрованную резервную копию ID-файла в назначенной базе данных- получателе почты (mail-in database) специально для восстановления ID- файла, который был потерян или поврежден.

Резервные копии ID-файлов шифруются при помощи случайного ключа. Их нельзя использовать в Notes, пока не будет произведено восстановление. Они сохраняются в виде вложений к документам, находящимся в специальной базе данных Notes, предназначенной для восстановления ID. Эта база данных представляет собой базу-получатель почты (mail-in database) или почтовую базу данных (mail database). Наконец, обратите внимание, что этой базе для хранения резервных копий ID можно давать каждый раз другое имя. Вы можете создать базу восстановления ID для каждого сертификатора. На рис. 3.4 показан вид документов, в которых хранятся зашифрованные резервные копии идентификаторов.

Восстановить ID-файл, для которого был забыт пароль, несколько проще. Если исходный ID-файл содержит информацию для восстановления, то администратор может восстановить ID, даже если отсутствует зашифрованная резервная копия. Такая "восстановительная" информация для восстановления ID-файла хранится в ID сертификатора Domino и в пользовательском ID-файле.

(рис 3.4) Общий вид документов, в которых хранятся зашифрованные резервные копии идентификаторов

В файле ID сертификатора хранится следующая информация:

число администраторов Notes, необходимых для разблокирования ID-файла;

имена администраторов Notes, которым разрешено восстанавливать ID-файлы;.

адрес почтовой базы данных (mail database) или базы данных-получателя почты (mail-in database), в которую пользователи посылают зашифрованную резервную копию своего ID.

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

Совет. Лучше всего назначить нескольких администраторов ответственными за восстановление ID и паролей. Хотя управлять восстановлением может и один администратор, подумайте о том, чтобы этим занимались сразу двое или больше человек. Создание группы администраторов позволит избежать угрозы для безопасности, связанной с тем, что один администратор имеет доступ ко всем ID-файлам. Когда существует группа администраторов, можно сделать так, чтобы только часть из них должна была присутствовать при восстановлении ID-файла. Например, если 5 администраторов назначены ответственными за восстановление ID, а для разблокирования ID-файла требуется присутствие только трех из них, то разблокировать ID- файл смогут любые 3 из пяти человек. Если существует группа ответственных и при этом для разблокирования нужна только часть этой группы, это также позволяет предотвратить проблемы, если один из администраторов недоступен или ушел из компании.

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

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

Администраторы экспортируют информацию для восстановления из файла ID. сертификатора и заставляют пользователей принять ее

(Только для серверов Domino 6 и выше.) Администраторы изменяют информацию для восстановления при помощи клиента Domino Administrator 7. После этого информация добавляется автоматически в пользовательские Notes ID при аутентификации пользователей на домашнем сервере.

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

3.3 Как работает восстановление ID

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

Например, администратор Notes по имени Laurent Hoerni имеет уникальный пароль восстановления для пользователя Noel Doyle и этот пароль находится в ID-файле пользователя Noel Doyle. Также администратор Notes по имени Jean-Jacques Chambaz имеет уникальный пароль восстановления для пользователя Daniel Coddron и этот пароль находится в ID-файле пользователя Daniel Coddron.

3.3.1 Возможность определения надежности пароля восстановления

В Domino 7 теперь возможно выбрать число символов или длину пароля восстановления, которые определяют надежность пароля или вероятность его взлома.

Если длина пароля не превышает 16 символов, при его генерации используются буквенно-числовые символы и шестнадцатеричные цифры. Пароли длиной 16 символов генерируются только из шестнадцатеричных цифр.

Хотя надежность пароля имеет большое значение (надежные пароли труднее взломать), не менее важно удобство использования. Длинный и сложный пароль трудно применять, поэтому администраторы также имеют возможность выбрать меньшую длину пароля.

Кроме того, администраторы теперь могут вводить собственное сообщение, которое помогает провести пользователей через процесс восстановления пароля.

Когда пользователи получают новый общий ключ, выполняют изменение имени или принимают или создают ключ шифрования документов, Domino автоматически посылает обновленные зашифрованные резервные копии ID в централизованную базу данных. Если применяется источник сертификатов на сервере, то база данных для восстановления обновляется после того, как пользователь соединиться с сервером.

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

3.3.2 Переход на другой ID сертификатора

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

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

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

3.4 Журнал восстановления ID

Начиная с Domino 7 важная информация об операциях по восстановлению ID клиента автоматически записывается в локальный файл журнала LOG.NSF, чтобы администраторы могли обращаться к этой информации при устранении ошибок.

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

дата и время, когда информация о восстановлении была записана в ID-файл;

ситуации, когда информация восстановления была отвергнута или не была записана в ID-файл;

события, которые требуют отправки новой резервной копии по почте в базу восстановления;

отправка по почте резервной копии в базу данных восстановления (успешная или неудачная).

На рис. 3.5 показана информация журнала, относящаяся к восстановлению ID.

(рис 3.5) Журналирование восстановления ID

3.5 Процесс установки и конфигурирования восстановления ID

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

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

В Domino Administrator выберите пункт меню Configuration (Конфигурация), а затем Certification (Сертификация).

Нажмите пункт Edit Recovery Information (Редактировать информацию восстановления).

В окне Choose a Certifier (Выберите сертификатор) нажмите Server (Сервер) и выберите имя сервера регистрации из Domino Directory (если нужное имя сервера не появилось сразу).

Выберите сертификатор, для которого вы создаете информацию восстановления:

Если вы используете источник сертификатов (certification authority) на сервере, выберите пункт Use the CA process (Использовать процесс СА) и выберите сертификатор из раскрывающегося списка. Чтобы изменять информацию восстановления, вы должны быть администратором источника сертификатов (СА) для данного сертификатора.

Если вы не используете источник сертификатов на сервере, нажмите Supply certifier ID and password (Указать ID и пароль сертификатора). Если имя ID-файла сертификатора и путь к нему не появились в окне, нажмите Certifier ID (ID сертификатора), выберите файл ID сертификатора и введите пароль.

Нажмите ОК. Появится окно Edit Master Recovery Authority List (Редактирование главного списка уполномоченных по восстановлению). На рис. 3.6 показано окно установки восстановления ID в Domino Administrator 7.

Введите количество уполномоченных лиц, которые должны восстанавливать ID-файл. Мы рекомендуем указать как минимум три.

Выберите длину пароля восстановления в раскрывающемся списке. По умолчанию используется длина в 16 символов.

Нажмите Add (Добавить) и выберите имена администраторов, которые назначаются уполномоченными по восстановлению.

Укажите, будете ли вы использовать существующий почтовый ящик для получения информации для восстановления или создадите новый:

Если у вас уже есть почтовая база данных (mail или mail-in), настроенная на получение информации для восстановления, выберите пункт I want to use an existing mailbox (Я хочу использовать существующий почтовый ящик). Нажмите Address (Адрес) и выберите базу данных в Domino Directory.

Если вы хотите создать новую базу данных для хранения информации для восстановления, выберите пункт I want to create a new mailbox (Я хочу создать новый почтовый ящик). В диалоговое окно Create New Mailbox (Создание нового почтового ящика) введите имя сервера, на котором будет создана база данных, и название для этой базы. Вы можете использовать имя файла, созданное из названия базы или выбрать другое имя.

(рис 3.6) Настройка восстановления ID в Domino Administrator 7

В поле Custom Recovery Message (Настраиваемое сообщение для восстановления) введите свое сообщение для диалогового окна Enter passwords (Ввод паролей), которое открывается в ходе процесса восстановления ID. Например, вы можете указать контактную информацию службы поддержки. Длина сообщения ограничивается 512 символами.Примечание. При любом вводе изменений в этом диалоговом окне кнопка Export (Экспорт) оказывается заблокированной. Вы не можете экспортировать информацию восстановления до тех пор, пока новая или обновленная информация не будет сохранена.

Нажмите ОК.

Если вы используете источник сертификатов на сервере, то в консоль сервера введите команду: load ca Эта команда запустит процесс Certificate Authority, передав ему новую информацию для восстановления, либо обновит его, если он уже запущен. Далее введите следующую команду для обработки запроса на добавление информации восстановления в сертификатор: tell adminp process all

В списке контроля доступа (ACL) базы данных-получателя почты укажите для Default права No access, а администраторам предоставьте права Reader.

Примечани е. Если вы создали дополнительные сертификаторы Notes уровня O, обязательно I выполните перекрестную сертификацию с исходным сертификатором Notes для настройки информации восстановления.

Подготовка ID к восстановлению

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

Внести в пользовательский ID информацию для восстановления пользователи могут одним из двух способов:

(Только для серверов Domino 6 и выше.) Пользователи проходят аутентификацию на своем домашнем сервере после того, как администратор внес информацию для восстановления в сертификатор. Информация для восстановления автоматически записывается в Notes ID.

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

В Domino 7 пользователи могут выяснить, содержится ли в их ID информация для восстановления, посмотрев, активна ли кнопка Mail Recovery ID (Отправить по почте резервную копию ID) в диалоговом окне User Security (Безопасность пользователя). Нажав эту кнопку, пользователь может отправить зашифрованную резервную копию пользовательского ID в централизованную почтовую базу или в базу-получатель почты.

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

Администратор должен выполнить следующие шаги:

В Domino Administrator перейдите к закладке Configuration (Конфигурация) и нажмите Certification (Сертификация).

Нажмите Edit Recovery Information (Редактировать информацию для восстановления).

Выберите сертификатор, для которого вы создаете информацию восстановления:

Если вы используете источник сертификатов (certification authority) на сервере, выберите пункт Use the CA process (Использовать процесс СА) и выберите сертификатор из раскрывающегося списка. Чтобы изменять информацию восстановления, вы должны быть администратором источника сертификатов (СА) для данного сертификатора.

Если вы не используете источник сертификатов на сервере, нажмите Supply certifier ID and password (Указать ID и пароль сертификатора). Если имя ID-файла сертификатора и путь к нему не появились в окне, нажмите Certifier ID (ID сертификатора), выберите файл ID сертификатора и введите пароль.

Нажмите Export (Экспорт), после чего введите пароль ID сертификатора.

Заполните поля (табл. 3.1), после чего нажмите Send (Послать).

Поля, которые должен заполнить администратор

Поле	Введите
To	Имена пользователей и групп, для которых вы хотите создать резервные копии ID
СС	Имена пользователей и групп, которым вы хотите послать копии сообщений
Subject	Информация для пользователей и групп, которая отображается в поле Subject (Тема) сообщения. Если это поле оставить пустым, Notes употребит следующий текст: "New ID file recovery information is attached. Please add it to your ID file by using the Actions menu "Accept Recovery Information" option" (К письму прикреплена новая информация, необходимая для восстановления ID-файла. Пожалуйста, добавьте ее в свой ID-файл, используя пункт Accept Recovery Information (Принять информацию для восстановления) меню Actions (Действия)
Memo	Информация для пользователей и групп, которая отображается в теле сообщения. Domino автоматически прикрепляет к сообщению информацию о зашифрованном файле резервной копии. Вам не нужно писать ее в этом поле

Прием в файл ID информации для восстановления

Пользователь должен выполнить следующие шаги:

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

Выберите пункт меню Actions (Действия) $$\to$$ Accept Recovery Information (Принять информацию для восстановления) и введите пароль.

Заполните поля (табл. 3.2) и нажмите Send (Послать).

Поля, которые должен заполнить пользователь

Поле	Введите
То	Имя почтовой базы данных (mail) или базы-получателя почты (mail-in), в которой будет храниться копия вашего ID. Domino вводит сюда имя, указанное администратором
СС	Имена пользователей и групп, которым вы хотите послать копию сообщения
Subject	Информация для администраторов, которая отображается в поле Subject (Тема) сообщения. Если оставить это поле пустым, Notes использует одно из следующих сообщений: Backup of newly changed recovery information for user name (Резервная копия измененной информации восстановления для имя_пользователя); Backup of recent changes to ID file for user name (Резервная копия последних изменений ID-файла для имя_пользователя)
Memo	Информация для администраторов, которая отображается в теле сообщения. Domino автоматически прикрепляет к сообщению резервную копию ID-файла. Вам не нужно писать об этом в этом поле

Domino автоматически отправляет зашифрованную резервную копию ID- файла в централизованную почтовую базу данных или в базу-получатель почты.

Примечание. Вы можете хранить несколько копий ID-файла в централизованной почтовой базе данных или в базе-получателе почты. Система Domino создает новый документ каждый раз, когда создается резервная копия ID-файла. При попытке восстановить ID-файл используйте самую последнюю копию. Если попытка оказывается неудачной, употребляйте более старые версии. Совет. Используйте переменную ID_Recovery_Suppress_Recovery_Msg файла NOTES.INI, чтобы запретить создание информации о восстановлении, если вы хотите заменить стандартный текст, который появляется в почтовом сообщении о восстановлении, на свое сообщение.

3.7 Процесс восстановления ID

Если пользователь потерял или повредил ID-файл или забыл пароль, он может совместно с администраторами восстановить ID-файл из резервной копии. Если пользователь не имеет доступа к своему ID-файлу, он может получить зашифрованную резервную копию.

Чтобы восстановить ID, пользователь и администраторы должны выполнить следующие шаги:

Пользователь связывается с уполномоченным администратором, чтобы получить от администратора пароль восстановления.

Администратор извлекает пароль восстановления, расшифровав пароль, хранящийся в пользовательском ID-файле, применяя личный ключ администратора.

Администратор сообщает пароль восстановления пользователю.

Пользователь повторяет шаги 1-3 до тех пор, пока не будет достигнуто минимально необходимое для разблокирования файла число администраторов.

Пользователь запускает Notes и нажимает ОК в диалоговом окне ввода пароля, не вводя пароль.

В диалоговом окне Wrong Password (Неверный пароль) пользователь нажимает. Recover password (Восстановить пароль).

Пользователь выбирает файл пользовательского ID, который нужно восстановить, в диалоговом окне Choose ID File to Recover (Выбор ID-файла для восстановления).

Пользователь вводит пароль, предоставленный администратором или администраторами в диалоговом окне Enter passwords (Ввод паролей), повторяя этот шаг, пока не будут введены все пароли.

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

Пользователь должен заменить все резервные и прочие копии своего ID-файла только что восстановленным ID-файлом.

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

Получение пароля восстановления ID-файла

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

Выполните следующие шаги:

Извлеките зашифрованную резервную копию пользовательского ID-файла из почтовой базы данных на локальный жесткий диск.

Если пользовательский ID-файл поврежден, отправьте пользователю копию ID-файла из централизованной почтовой базы данных.

В Domino Administrator перейдите к закладке Configuration (Конфигурация), а затем выберите пункт Certification (Сертификация) $$\to$$ Extract Recovery Password (Извлечь пароль восстановления).

Введите пароль к администраторскому ID-файлу.

Укажите ID-файл, который вам нужно восстановить. Это тот же ID, который вы извлекли в шаге 1.

Обратите внимание на пароль восстановления. Сообщите пользователю пароль восстановления, который отобразился на экране.

Примечание. Теперь в диалоговых окнах Extract Recovery (Извлечение информации для восстановления) и Recover ID File (Восстановление ID-файла) отображается отметка времени для информации восстановления, содержащейся в данной копии восстанавливаемого ID-файла. При каждой генерации информации для восстановления для ID-файла все пароли восстановления изменяются. Иногда восстановительный cookie, получаемый администратором, оказывается не в состоянии разблокировать пользовательский ID-файл; информация для восстановления в какой-то момент была изменена, а администратор использует копию ID-файла, содержащую другой комплект информации для восстановления. В таких ситуациях администратору нужно проверить отметку времени в упомянутых выше диалоговых окнах и посмотреть, не пытается ли он восстановить ID-файл с устаревшей информацией для восстановления.

3.8 Изменение информации об администраторе, предназначенной для восстановления ID

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

Добавление и удаление администраторов

Администратор, имеющий доступ к ID сертификатора, выполняет следующие шаги:

В Domino Administrator выберите пункт меню Configuration (Конфигурация), а затем Certification (Сертификация).

Нажмите пункт Edit Recovery Information (Редактировать информацию восстановления).

В окне Choose a Certifier (Выберите сертификатор) нажмите Server (Сервер) и выберите имя сервера регистрации из Domino Directory (если нужное имя сервера не появилось сразу).

Выберите сертификатор, для которого вы создаете информацию восстановления:

Если вы используете источник сертификатов (certification authority) на сервере, выберите пункт Use the CA process (Использовать процесс СА) и выберите сертификатор из раскрывающегося списка. Чтобы изменять информацию восстановления, вы должны быть администратором источника сертификатов (СА) для данного сертификатора.

Если вы не используете источник сертификатов на сервере, нажмите Supply certifier ID and password (Указать ID и пароль сертификатора). Если имя ID-файла сертификатора и путь к нему не появились в окне, нажмите Certifier ID (ID сертификатора), выберите файл ID сертификатора и введите пароль.

Выполните одно из следующих действий:

чтобы удалить администратора, выделите имя администратора и нажмите кнопку Remove (Удалить);.

чтобы добавить администратора, нажмите Add (Добавить) и выберите имена администраторов, которым предоставляется право восстанавливать ID-файлы.

(Дополнительно.) Измените количество администраторов, необходимое для разблокирования ID.

Закончив добавлять и удалять имена, нажмите ОК.

3.9 Суммарный список действий

В следующем подразделе приводится список общих действий как для настройки восстановления ID, так и для самого восстановления ID.

3.9.1 Первоначальная настройка

Для исходной настройки выполните следующие шаги:

Решите, какой сервер Domino будет сервером СА (certification authority) для всей вашей организации. Эта машина должна быть очень надежной и физически безопасной.

На сервере СА отредактируйте файл NOTES.INI, добавив задачу са в строку ServerTasks=. Перезапустите сервер, чтобы запустить данную задачу.

Создайте базу данных-получатель почты (mail-in database), которая будет использоваться в процессе восстановления ID. Эта база может называться ID Recovery, и она должна быть расположена на защищенном почтовом сервере (который одновременно может представлять собой СА-сервер).

Создание и перенос сертификатора верхнего уровня

Выполните следующие шаги:

Создайте сертификатор верхнего уровня, выбрав пункт Domino Administrator $$\to$$ Configuration (Конфигурация) $$\to$$ Registration (Регистрация) $$\to$$ Organization (Организация). Если у вас уже есть сертификатор верхнего уровня, используйте его. Не создавайте другой.

Перенесете сертификатор верхнего уровня в процесс СА, для чего выберите пункт Domino Administrator $$\to$$ Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Migrate Certifier (Перенести сертификатор). Выполните следующие шаги:

Выберите ID-файл сертификатора верхнего уровня

Перейдите к закладке Basics (Общие) мастера переноса и введите следующую информацию:

укажите имя СА-сервера;

оставьте без изменений имя файла списка интернет-сертификаторов (Internet Certifier List, ICL);.

зашифруйте ID сертификатора с помощью пункта Server ID (ID сервера);

не требуйте пароль активизации;

укажите имена администраторов, ответственных за сертификатор (certifier authority administrators, САА) и администраторов, ответственных за регистрацию (registration authorities, RA).

САА является владельцем сертификатора и может вносить в него любые изменения. RA может использовать этот сертификатор для создания пользователей, серверов и подразделений (отметим что в версии 6 столбец САА по ошибке называется CA). Поскольку мы имеем дело с сертификатором верхнего уровня, рекомендуется, чтобы число людей, являющихся одновременно САА и RA, было небольшим

Перейдите к закладке Certificates (Сертификаты)

Мы рекомендуем оставить неизменными значения, заданные по умолчанию, возможно за исключением первого значения в первом столбце. Здесь указан срок действия ID конечных пользователей, созданных при помощи данного сертификатора, составляющий по умолчанию 24 месяца. В некоторых организациях этот период составляет 12 месяцев.

На рис. 3.7 показано диалоговое окно переноса сертификатора в Administrator 7.

(рис 3.7) Диалоговое окно переноса сертификатора

3.9.2 Изменение сертификатора верхнего уровня

Для выполнения этой операции вы должны быть САА для сертификатора верхнего уровня. Вы также должны иметь права Editor для доступа к Domino Directory (NAMES NSF) в данном домене Notes.

В Domino Administrator выберите пункт Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Modifier Certifier (Модификация сертификатора).

Укажите сервер CA

Укажите сертификатор в Domino Directory (вместо базы ICL).

Выберите изменяемый сертификатор.

Нажмите ОК, чтобы открыть сертификатор.

Внесите необходимые изменения.

Нажмите ОК, чтобы сохранить изменения.

Создание и перенос сертификаторов подразделений

Выполните следующие шаги:

Чтобы создать новые сертификаторы уровня подразделений, выберите пункт Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Registratio n (Регистрация) $$\to$$ Organizational Unit (Подразделение организации). (Этот пункт применим только к новым подразделениям. Существующие подразделения просто переносятся в СА) Выполните следующие шаги:

выберите сервер СА;

выберите пункт Use the CA process (Использовать процесс CA);

из списка сертификаторов в CA выберите сертификатор верхнего уровня, который будет использоваться при создании нового подразделения;

введите стандартную информацию о сертификаторе подразделения и нажмите Register (Зарегистрировать).

Перенесите сертификатор подразделения в процесс СА, выбрав пункт Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Modifier Certifier (Модификация сертификатора). Выполните следующие шаги:

Выберите ID-файл сертификатора подразделения.

Перейдите к закладке Basics (Общие) мастера переноса. Укажите следующую информацию:

имя сервера СА;

оставьте без изменений имя файла ICL;

зашифруйте ID сертификатора с помощью пункта Server ID (ID сервера);

не требуйте пароль активации;

имена администраторов, ответственных за сертификатор (certifier authority administrators, CAA) и администраторов, ответственных за регистрацию (registration authorities, RA).

CAA является владельцем сертификатора и может вносить в него любые изменения RA может использовать этот сертификатор для создания пользователей (отметим, что в версии 6 столбец САА по ошибке называется CA). Поскольку мы имеем дело с сертификатором уровня подразделения, рекомендуется, чтобы число людей, являющихся САА, было небольшим, а число RA, работающих в организации, было больше.

Перейдите к закладке Certificates (Сертификаты).

Мы рекомендуем оставить неизменными значения, заданные по умолчанию, возможно за исключением первого значения в первом столбце. Здесь указан срок действия ID конечных пользователей, созданных при помощи данного сертификатора, составляющий по умолчанию 24 месяца. В некоторых организациях этот период составляет 12 месяцев.

Примечание. Вы должны представить RA следующие дополнительные права:

NAMES.NSF: права Author, привилегия Create Document, роли UserCreator и UserModifier;

CERTLOG.NSF: права Author, привилегия Create Document.

3.9.3 Изменение сертификаторов подразделений

Для выполнения этой операции вы должны быть САА для сертификатора подразделения. Вы также должны иметь права Editor для доступа к Domino Directory (NAMES NSF) в данном домене Notes.

В Domino Administrator выберите пункт Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Modifier Certifier (Модификация сертификатора).

Укажите сервер СА.

Укажите сертификатор в Domino Directory (вместо базы ICL).

Выберите изменяемый сертификатор.

Нажмите ОК, чтобы открыть сертификатор.

Внесите необходимые изменения.

Нажмите ОК, чтобы сохранить изменения.

3.9.4 Настройка восстановления ID

Выполните следующие шаги:

Выберите пункт Domino Administrator $$\to$$ Configuration (Конфигурация) $$\to$$ Certification (Сертификация) $$\to$$ Edit Recovery Information (Редактирование информации для восстановления).

Укажите сервер CA

Выберите пункт Use the CA process (Использовать процесс СА).

Из списка сертификаторов в СА выберите сертификатор, который вы хотите отредактировать.

Введите информацию для восстановления ID.

Настройте длину cookie. Чтобы cookie был длиной больше 16 символов, у вас должен быть установлен Domino Administrator 7 или выше.

Укажите имя ранее созданной базы данных-получателя почты (mail-in).

Нажмите ОК, чтобы сохранить информацию для восстановления.

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

3.9.5 Изменение информации для восстановления ID

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

3.9.6 Восстановление забытого пароля: действия пользователя

Пользователь может проверить доступность информации для восстановления, выбрав пункт File (Файл) $$\to$$ Security (Безопасность) $$\to$$ User Security (Безопасность пользователя) $$\to$$ Basics (Общие). Если кнопка Mail Recovery ID (Отправить резервную копию ID по почте) доступна, это указывает на то, что в ID есть информация для восстановления. Нажмите на эту кнопку, чтобы отправить зашифрованную резервную копию в базу данных для восстановления.

3.9.7 Восстановление потерянного или поврежденного ID-файла

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

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

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