Книги, научные публикации
Pages: | 1 | ... | 9 | 10 | 11 | 12 | 13 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 11 ] --6. В окне командной строки введите ntdsutil и нажмите Enter.
Введите Security account management и нажмите Enter.
7.
Введите Connect to server <имя_сервера> и нажмите Enter.
8.
В приглашении Security account management (Обслуживание учетных записей 9.
безопасности) введите Cleanup Duplicate SID и нажмите Enter.
Программа начнет очистку повторяющихся SID. Результаты выполнения реги стрируются в файле Dupsid.log, расположенном в каталоге, из которого Вы за пустили Ntdsutil.
10. Введите quit и нажмите Enter. Выполните команду quit повторно, чтобы возвра титься в командную строку.
В общем случае дублирование ролей хозяев одиночных операций в конечном счете разрешается автоматически в процессе репликации. Обновления в базе данных бо лее нового владельца роли обладают более высоким порядковым номером обновле ния (update sequence number, USN), и поэтому он замещает предыдущего владель Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 1О ца роли при репликации нового владельца роли в базу данных каталога. Единстнен ное нарушение, которое может произойти, - запись в базу данных предыдущего владельца роли до разрешения механизмом репликации проблемы двойников.
Лучше всего вообще не допускать возникновения двойников. Тем не менее эта про блема решается размещением старого хозяина относительных идентификаторов в сайте нового владельца и немедленным запуском принудительной репликации.
Подробнее об операциях одиночного хозяина и устранении неполадок при таких операциях Ч в главе 7 Управление операциями одиночного хозяина.
Неполадки репликации В Active Directory существует только два вида репликации: синхронная по прото колу RPC (Remote Procedure Call) и асинхронная с использованием службы In tersite Messaging (ISM).
При репликации поддерживаются следующие виды транспорта:
Х синхронный RPC: транспорт, поддерживающий доверительные отношения по протоколу Kerberos v5;
Х асинхронный: транспорт, не поддерживающий доверительные отношения, безо пасность обеспечивается на основе сертификатов каталога.
Примечание Одно важное требование транспортного модуля ISM: он работает меж ду раздельными (disconnected) сетями. Это не требование реализации модуля, а тре бования вызванное особенностями его работы. Среды, в которых он развертывает ся, не поддерживают прямые пути доверия, и сообщения проходят через шлюзы;
некоторые из них передаются по незащищенным сетям. Транспорт в таких средах должен допускать длительные задержки (латентноеть), проходить через шлюзы и поддерживать сохранение и пересылку в случае недоступности одного или несколь ких шлюзов.
^ Устранение неполадок репликации на основе почты 1. Проверьте, нет ли в журнале каких-либо сообщений, относящихся к рассматри ваемой неполадке. Возможные ошибки: проблемы построения топологии служ бой КСС, неполадки при доставке почты в службе SMTP (SMTPSVC), неполад ки чтения сообщений в службе ISM, проблемы NTDS при расшифровке и ис пользовании данных из почты.
2. Убедитесь, что КСС настроена на использование SMTP-соединений между сер верами в выбранных сайтах.
3. Проверьте корректность параметров транспортов для связей репликации. Для этого просмотрите соединения с SMTP-транспортом, воспользовавшись, к при меру, командой repadmin /showreps и просмотрев возвращенные программой со общения со строкой via SMTP.
Обратите внимание, что КСС не создает соединение на базе SMTP, пока не вы полнены следующие условия:
Х серверы размещены в сайтах, объединенных связями сайтов на базе SMTP;
Х стоимость связи между сайтами для SMTP ниже, чем для IP;
Служба каталогов Active Directory 470 ЧАСТЬ Х полные реплики одного домена не передаются по SMTP. (Эта функция не поддерживается.) Таким образом поддерживается репликация глобального каталога, конфигурации и схемы (то есть недоменных разделов каталога);
Х все серверы настроены на получение почты. Web-сервер IIS должен быть ус тановлен на обоих серверах.
Обратите внимание, что связь между сайтами, по определению, осуществляется через серверы-плацдармы (bridgehead). KCC выбирает такие серверы для каж дого сайта самостоятельно, если они не настроены явно. Назначая серверы-плац дармы явно, убедитесь, что они содержат раздел домена, который будет репли цироваться.
4. Перед перемещением сервера в сайт, поддерживающий репликацию только по почте, следует убедиться в наличии у него сертификата контроллера домена (Domain Controller Certificate). На одном из контроллеров доменов на предпри ятии следует установить центр сертификации предприятия (Enterprise Cer tificate Authority). По истечении определенного времени (до 8 часов) после ус тановки все контроллеры данного домена автоматически регистрируются на нем и получают сертификаты контроллера домена. Проверить наличие у компь ютера такого сертификата можно в оснастке Certificates (Сертификаты) [в пап ке Personal (Личные)! или командой repadmin /showcert.
5. Для репликации на базе почты следует определиться, необходима ли маршрути зация почты. Если два сервера обладают прямым IP-соединением и способны об мениваться почтой напрямую, никакой дополнительной настройки не требуется.
Однако, если контроллеры домена должны обмениваться почтой через шлюзы, их следует сконфигурировать для работы со шлюзом электронной почты. Обычно для этого устанавливают Smart Host на Default SMTP Virtual Server (Виртуаль ный SMTP-сервер по умолчанию) в разделе Internet Information Services оснаст ки Computer Configuration (Управление компьютером).
6. Проверьте корректность выполнения репликации по почте, выполнив команду repadmin /showreps. Программа предоставляет сведения о коде текущей ошиб ки и времени последнего успешного обновления. Если текущий код ошибки request is pending (то есть запрос на обновление задерживается) и со времени последнего успешного обновления прошло более часа, это свидетельствует о за держке почты или о том, что сообщение не доставлено. Нужно иметь в виду, что почта не доставляется немедленно, доставка выполняется по механизму сохра нить и переслать, а не по прямому соединению.
Прежде всего следует проверить получение и доставку почты службой SMTP (SMTPSVC). Изучите каталог Inetpub\mailroot\Queue на сервере-приемнике, всех шлюзах и источнике репликации. Queue это очередь исходящей почты.
Если в каталоге Queue Ч много файлов, это обычно означает, что SMTPSVC вы полняет архивирование или не в состоянии обработать всю почту. Чтобы испра вить ситуацию, надо выполнить следующую последовательность команд:
Х net stop iisadmin Х net start stmpsvc Х net start ftpsvc Х net start wwwsvc Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА При этом принудительно отправляется вся текущая корреспонденция.
Х Для проверки синхронизации каталогов на основе почтового обмена можно воспользоваться описанными далее процедурами. Допустим, у нас есть два компьютера - А и В. В окне Windows Explorer (Проводник Windows) в этих компьютерах откройте папку <каталог_базы_данных_Ш(1$>\&гор. Предпо ложим, что обновление выполняется от В к А. На компьютере А проведите принудительную синхронизацию соединения с В средствами оснастки Active Directory Sites and Services (Active Directory сайты и службы). Система А обратиться к В с почтовым запросом об обновлении. В окне Windows Explorer в папке Drop должны появиться один или более временных почтовых фай лов, которые по мере обработки исчезают. После этого временные почтовые файлы должны появиться в папке Drop на компьютере А. Это ответные по чтовые сообщения с данными, отправленными в ответ на запрос. Временные файлы также должны исчезать по мере их обработки.
Х Далее следует проверить, считывает ли почту служба Intersitc Messaging Service (ISM). Изучите содержимое панок <каталог_жур налов _ ntds>\Dmp на получателе и источнике. По умолчанию каталог журналов находится по адресу %Systemroot%\ntds, если только он не перемещен средствами служеб ной программы Ntdsutil. Папка Drop содержит входящую почту. Наличие в пей множества почтовых сообщений свидетельствует об остановке службы или о слишком большом входящем потоке сообщений, которые служба не в состоянии обработать. Остановившуюся службу следует перезапустить. Если поток почтовых сообщений велик, следует увеличить период почтовой реп ликации. Только в качестве крайней меры допускается останов службы ISM, удаление всех сообщений из папки Drop и последующий перезапуск служ бы. Это позволит службе устранить создавшееся отставание, так как, в ко нечном счете, отправители все равно повторно передадут сообщения с обнов лениями, 7. Еще один параметр, который требуется проверить, - отсутствие неполадок при доставке. Убедитесь, что каждое из звеньев почтового маршрута соединено со своими соседями напрямую, по протоколу IP. Кроме этого выясните способность каждого из серверов разрешать имя следующего по маршруту сервера. Почто вый адрес, используемый для подключения между контроллерами домена Ч это лимя на основе GUID, имеющее следующий вид
8. Если SMTPSVC не удается доставить почту, служба возвращает уведомление о состоянии доставки (Delivery Status Notification, DSN). Эти уведомления реги стрируются в журнале при высоком уровне диагностики. Чтобы их увидеть, нужно установить уровень 1 диагностики Active Directory в параметре Inter-site Messaging и перезапустить службу SMTP. Подробнее об уровнях диагностики Active Directory и их установке Ч в разделе Регистрация событий Active Directory ранее в этой главе.
Записи в журнале службы каталогов, относящиеся к репликации Далее перечислены типы записей в журнале службы каталогов, относящиеся к ошибкам репликации:
Служба каталогов Active Directory 472 ЧАСТЬ Х неполадки службы проверки согласованности знаний (Knowledge Consistency Checker, KCC);
Х задержка входящей репликации;
Х конфликт со службой сертификации;
отсутствие RPC;
Х Х неверное имя пользователя и/или пароль;
Х механизму автоматического создания топологии не удалось сформировать то пологию.
Неполадки службы КСС В журнале службы каталогов Бы можете обнаружить следующую запись [с кодом (Ш)1311 и с указанием источника - NTDS КСС]:
The Directory Service consistency checker has determined that either (a) there is not enough physical connectivity published via the Active Directory Sites and Services Manager to create a spanning tree connecting all the sites containing the partition DC=mycorp,DC=com, or (b) replication cannot be performed with one or more critical servers in order for changes to propagate across all sites (most often due to the servers being unreaehable).
For (a), please use the Active Directory Sites and Services Manager to do one of the following:
1. Publish sufficient site connectivity information such that the system can infer a route by which this Partition can reach this site. This option is preferred.
2. Add an ntdsConnection object to a Domain Controller that contains the partition DC=mycorp,DC=com in this site from a Domain Controller that contains the same partition in another site.
For (b), please see previous events logged by the NTDS KCC source that identify the servers that could not be contacted, Такое сообщение свидетельствует, что служба КСС обнаружила потерянный сайт Х выпавший* из топологии репликации.
В каждом сайте один контроллер домена отвечает за создание объектов-подключе ний для входящей репликации от серверов-плацдармов других сайтов. Он называ ется генератором межсайтовой топологии (Inter-Site Topology Generator). Выпол няя анализ связей сайтов и структуру мостов связей сайтов для выявления наибо лее эффективного маршрута синхронизации контекста именования, он может об наружить, что у сайта нет связи сайтов, и поэтому генератор межсайтовой тополо гии не способен создать объект репликации для сервера-плацдарма в своем сайте.
Первый сайт в Active Directory (он получает название по умолчанию Ч Default First-Site-Name) создается автоматически. Этот сайт участвует в заданной по умол чанию связи сайтов (DEFAULTIPSITELINK), создаваемой автоматически и ис пользуемой для связи по RPC поверх TCP/IP. Создавая два дополнительных сай та, администратор обязан определить связь сайтов, к которой они будут относить ся, иначе эти сайты не будут размещены в Active Directory.
С другой стороны, администратор вправе открыть страницу свойств связи сайтов и изменить состав сайтов, к ней относящихся. При попытке удалить сайт из всех свя зей сайтов КСС сообщит об описанной выше ошибке, предлагая внести изменения в конфигурацию.
Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 10 Примечание Отображая это сообщение, КСС находится в режиме, в котором невоз можно удалить никакие подключения. Обычно КСС удаляет старые, оставшиеся от предыдущих конфигураций а также излишние подключения. Поэтому на этом эта пе Вы можете обнаружить новые подключения в неожиданных местах. Эта пробле ма решается коррекцией топологии с созданием связующего дерева.
Причиной такой неполадки может стать сбой репликации из определенного серве ра-плацдарма в сайте в условиях недоступности других таких серверов. Подробнее о серверах-плацдармах - в главе 6 Репликация Active Directory*.
Примеры относящихся к репликации сообщений в окне просмотра событий Ниже показаны примеры ошибок, вызванных задержкой входящей репликация и конфликтами со службой сертификации, а также других относящихся к реплика ции сообщений в оснастке Event Viewer (Просмотр событий), Примечание По умолчанию эти ошибки не регистрируются, и чтобы их увидеть, следует повысить уровень диагностики. Сообщения о таких ошибках довольно ред ки, однако они чрезвычайно полезны для устранения неполадок и оптимизации производительности.
Event Severity=Informational A long running inbound replication has finished. The elapsed time was X1 minutes.
The operation was %2, and the options were X3. The status of the operation was:
The operation specific arguments are:
Parameter 1:
Parameter 2:
Parameter 3:
Parameter 4:
*n This data is for information and may be useful in tuning the replication performance of the system. Since only one inbound replication may occur at a time, long running replications delay other replications from coming in in a timely manner. This system has been delayed from receiving other directory updates because this replication went on as long as it did. A long running replication may indicate a large number of updates, or a n u m b e r of complex updates (DN-valued attributes) occurring at the source server. Performing these updates during non-critical times may prevent replication delays during important times.
A long running replication is normal in the case of adding a new replica to a system, either because of installation, Global Catalog promotion, or connection creation by the KCC. A long running replication may also occur for a system that has been down, or a partition that has been out of touch for an extended period.
The record data is the status code.
logging_level: Event Severity=Warning Due to contention with the Certificate Services for resources, replication was stalled for %~\ minutes, K2 seconds. It took an unusually long time to prepare an asynchronous replication message for transmission. This condition should be transient. If this issue persists, please contact Microsoft Product Support Services for assistance.
Служба каталогов Active Directory 474 ЧАСТЬ logging^level: Event Severity=Warning Due to contention with the Security Descriptor Propagator for resources, inbound replication was stalled for Я1 minutes, 5!2 seconds. This condition should be transient. If this issue persists, please contact Microsoft Product Support Services for assistance.
logging_level: Event Severity=Informational One or more new attributes has been added to the partial attribute set for partition (1. A full synchronization will be performed from source X2 on the next periodic synchronization.
logging_level: Event Severity=Informational A new replica for partition %1 has been added to this server. This server will now perform a full synchronization from source X2 with options ЯЗ.
logging_level: Event Severity=Informational The user has requested a full synchronization of partition X1 from source X2 with options КЗ.
logging_level: Event Severity=Informational The full synchronization of partition X1 from source X2 with options X3 in being continued.
logging_level: Недоступность сервера RFC Сообщение о недоступности сервера RFC (лRFC server is unavailable) обычно сви детельствуют об отключении компьютера.
Примечание В случае невозможности разрешения имени Active Directory возвра щает ошибку, явно информирующую об этом Ч The name can not be resolved.
Подробнее о сообщениях об ошибках недоступности сервера RFC Ч в разделе Раз решение имен ранее в этой главе.
Неверное имя пользователя н/или пароль Для устранения неполадок, сопровождающимися сообщением Unknown user name/ bad password, используйте служебную программу repadmin на контроллере домена.
Например, так:
repadmin /showmeta СН=<имя_контроллвра_домвна>, OU=Domain Controllers, йС=<имя_домена>, №=<иня_домена> Если номера версии атрибута unicodePwd каких-либо объектов различаются на двух или более контроллерах домена, разумно предположить, что пароли не сипхрони Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 10 зированы и репликация не выполнена, и поэтому контроллеры домена не в состоя нии выполнить взаимную проверку подлинности. В такой ситуации следует сбро сить пароли учетных записей компьютера.
Примечание Служебная программа Dcdiag способна сравнивать метаданные объек та компьютер, что позволяет автоматизировать действия, описанные в предше ствующем разделе. Подробнее о программе Dcdiag - в разделе Неполадки кон троллера домена ранее в этой главе.
Сбой репликации из-за нарушения доступа О неполадках, связанных с безопасностью, свидетсльствовуют ошибки разрешения имени получателя (лWrong Target Name) или сообщения о невозможности найти контроллер домепа (лCannot locate domain controller). Важно понимать, что суще ствует взаимозависимость между репликацией и безопасностью распределенных си стем на базе Kerberos v5. Подтверждение подлинности в процессе репликации вы полняется по протоколу Kerberos v5, а участники безопасности Kerberos реплици руются но механизму репликации.
Обычно нарушение доступа при репликации между двумя контроллерами домена вызвано тем, что на один или оба из них не реплицированы данные, необходимые для взаимной проверки подлинности.
В процессе установки Active Directory компьютер становится контроллером доме па (назовем его получатель), он присоединяется к предприятию, общаясь с суще ствующим контроллером домена (назовем его источник). До перезапуска и самона стройки получателя источник является единственным контроллером домепа в пред приятии, который знает о существовании получателя.
Примечание Таким образом, на некоторое время существующий контроллер доме на становится единственным лузким местом (single point of failure) - пока дан ные не реплицируются на другие контроллеры домена. Это одна причина того, что перед удалением Active Directory (то есть перед запуском мастера установки Active Directory) с контроллера домена система должна успешно выполнить исходящую репликацию. Если компьютер полностью выходит из строя будучи источником, данные о новом контроллере домена остаются недоступными для остальных ком пьютеров.
Итак, попытка третьего контроллера домена обменяться репликативными данны ми с новым компьютером может вызвать ошибку доступа, так как сведения о но вой системе не распространились во всем предприятии. Данные о новой системе реплицируются в раздел конфигурации, а сведения об участнике безопасности Kerbcros v5 - в раздел домена. Поэтому возможно временное несоответствие меж ду получением третьим контроллером домена сведений о новом компьютере и мо ментом, когда последний получает возможность проходить проверку подлинности на этом контроллере домена.
Таким образом, обнаружив ошибку нарушения доступа Access Denied, проверьте, распространились ли данные о недавно назначенных контроллерах домена по все му предприятию. Неполадки репликации на компьютерах предприятия способны препятствовать репликации объекта учетной записи недавно назначенного контрол лера домена.
Служба каталогов Active Directory 476 ЧАСТЬ Неудача автоматического создания топологии Сообщение о невозможности создать топологию репликации Automatic topology generator was unable to complete the topology for <составиое_имя_сайта> в жур нале службы каталогов в окне Event Viewer (Просмотр событий) свидетельствует о возникновении исключения в службе проверки согласованности знаний (Know ledge Consistency Checker, KCC).
Для получения более подробных сведений следует увеличить до 3 значение пара метра Internal Processing реестра в разделе HKEY_LOCAL_MACHINE\SYSTEM\ Current Control Set\Services\NTDS\Diagnostics\ и подождать 15 минут.
Дополнительно Вы можете выполнить команду repadmin /kcc и сбросить значение этого параметра реестра до 0.
Примечание Этот метод следует также применять всякий раз, когда репликация информирует о внутренней ошибке сообщением Internal error. Указанное значе ние параметра Internal Processing следует установить на обоих компьютерах, обме нивающихся данными репликации.
Наблюдение за связями репликации Служебная программа администрирования репликации Repadrnin (Replication Administration) применяется для наблюдения за текущими связями контроллера домена, а также контроллерами домена, обменивающимися с ним данными репли кации. Изучая сведения о связях, возвращенных Repadmin, Вы можете изучать то пологию репликации текущего сервера. Сведения о топологии позволяют проверять согласованность репликации между партнерами, осуществлять мониторинг состоя ния и отображать метаданные репликации.
Существенно важнее то, что Вы имеете право управлять топологией репликации, принудительно вызывая определенные события или заставляя КСС выполнять пе рерасчет топологии. Однако выполнять принудительную репликацию следует толь ко на отключенном (offline) контроллере домена или в случае недоступности сете вых подключений. При нормальной работе служба КСС автоматически управляет топологией репликации всех разделов каталога на контроллере домена.
Например, для определения того, какие контроллеры домена получили некое реп лицируемое изменение, выполните следующую команду:
repadmin /showmeta "CN=JSmith, OU=PR, QU=Marketing, DC=Reskit, DC=com" где <имя_контроллерадомено> Ч имя контроллера домена Ч получателя, для ко торого изучается репликация объекта J Smith из подразделения PR, размещенного, в свою очередь, в подразделении Marketing домена Reskit.com, Строки, возвращен ные этой командой, содержат порядковый номер обновления (update sequence number, USN), DSA отправителя, дату и время, номер версии и реплицируемый атрибут.
Изменение режимов домена Для изучения того, реплицируются ли обновления каталога на все контроллеры до мена, Вам следует использовать служебные программы Repadmin и Ldp. Измене ние режима домена Ч одна из самых важных операций, отражающихся в том числе и на согласованности репликации.
ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory К примеру изменение режима домена распространяется по обычному механизму репликации. Для передачи таких сведений служит атрибут ntMixedMode объектов класса domainDNS (например, домена). Отличное от нуля значение зтого атрибута указывает на смешанный режим, а нуль Ч на основной режим. Чтобы проверить распространение изменений режима домена, Вы можете определить значение этого атрибута на всех контроллерах данного домена.
Служебная программа Repadmin применяется для изучения топологии репликации с точки зрения отдельного контроллера домена и получения сведений о матрице JSM (Inter/site Messaging). Кроме того, Repadmin применяют для создания тополо гии репликации вручную (хотя в обычных условиях это не требуется), принуди тельного выполнения операции репликации между контроллерами домена и полу чения информации о метаданных репликации и векторах обновления данных.
Примечание В обычных условиях не требуется создавать топологию репликации вручную. Неправильное использование этой служебной программы способно отри цательно сказаться на топологии репликации. В основном она применяется для наблюдения за репликацией с целью выявления потенциальных проблем, напри мер отключенных серверов или недоступных сетевых соединений в локальных (LAN) и глобальных (WAN) сетях.
Repadmin Repadmin.exe Ч это служебная программа командной строки, позволяющая про сматривать и изменять состояние репликации на контроллерах домена в процессе диагностики и устранения неполадок репликации между контроллерами домена под управлением Windows 2000. Средствами Repadmin Вы можете изучать текущую топологию репликации, создавать топологию репликации вручную и принудитель но выполнять операции репликации.
Примечание В обычных условиях КСС автоматически создает топологию реплика ции, и нет никакой необходимости создавать ее вручную.
Подробнее об использовании Repadmin Ч в справочной системе Windows Support Tools.
Просмотр подключений сервера Служебную программу Repadmin можно использовать для отображения текущих свя зей отдельного контроллера домена, а также контроллеров домена, обменивающихся с этим контроллером данными репликации - как входящими, так и исходящими.
Изучая сведения о связях, возвращенных Repadmin, Вы можете изучать топологию репликации текущего сервера. Некоторые связи оказываются недоступными, что пре пятствует созданию любых новых связей через соответствующий сервер.
При просмотре связей отдельного контроллера домена в Repadmin Вы видите парт неров репликации, поддерживаемых в текущее время службой КСС для данного сервера. Объекты-подключения, расположенные в контейнере Sites, могут отсут ствовать в Repadmin.
^ Просмотр текущих партнеров репликации отдельного сервера Х В командной строке введите;
repadmin /showreps server <контекст_именования> <биЮ_сврвера-источника> 478 ЧАСТЬ 1 Служба каталогов Active Directory Принудительная репликация между партнерами репликации Существуют четыре способа инициации репликации между прямыми партнерами репликации. В трех из них используются административные служебные програм мы, а четвертый метод Ч это сценарий Visual Basic. Подробнее о применении сце нариев - на Web-странице Microsoft Platform SDK по адресу rosoft.com/windows2000/reskit/webresources, ссылка Microsoft Knowledge Base и далее ссылка на статью Q232072.
Далее мы описываем эти методы. Здесь листочник Ч это контроллер домена, от правитель данных репликации, а получатель Ч контроллер домена, получающий сведения об изменениях от источника.
Принудительная репликация средствами оснастки Active Directory Sites and Services В консоли управления Active Directory Sites and Services (Active Directory Ч сай ты и службы) щелкните правой кнопкой мыши объект-подключение и в открывав шемся контекстном меню выберите команду Replicate Now (Реплицировать сей час). (Подробнее о принудительной репликации средствами оснастки Active Di rectory Sites and Services Ч в справочной системе Windows 2000 Server.) Принудительная репликация средствами Repadmin Repadmin - это служебная программа командной строки, входящая в состав средств поддержки, расположенных в папке Support на компакт-диске с операционной сис темой Windows 2000. Она позволяет сначала определить партнеры репликации ка талога для конкретного сервера-получателя, а затем выполнить синхронизацию сер вера-источника с получателем, указав GIJID сервера-источника, >Х Принудительная репликация между двумя серверами средствами Repadmin 1. В командной строке введите следующую строку:
Repadmin /showreps <имя_сервера-получателя> Примечание Выполняя данные инструкции, обратитесь к приведенному здесь примеру использования Repadmin.
2. В разделе Inbound Neighbors протокола выполнения программы найдите раз дел каталога, нуждающегося в синхронизации, и отыщите сервер-источник, с ко торым следует синхронизировать сервер-получатель. Обратите внимание на зна чение атрибута objectGuid сервера-источника.
3. Выполните принудительную репликацию следующей командой:
repadmin /sync <составное_имя_раздела_каталога> <имясервера-получателя>
repadmin /sync dc=support,dc=microsoft,dc=com DC1 d2e3badd-e07a-11d2-b573~ 0000f87a546b В случае успешного выполнения команды появится следующее сообщение:
ReplicaSyncC) from source: d2e3badd-e07a-11d2-b573-0000f87a546b, to dest: DC1 is successful.
Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 10 Дополнительно Вы вправе использовать следующие параметры командной строки:
- /force: Overrides the normal replication schedule.
- /async: Starts the replication event. (Repadmln.exe does not wait for the replication event to finish.) Первый (/force) вынуждает программу игнорировать обычное расписание репли кации, а второй (/async) запускает репликацию, не ожидая окончания текущей реп ликации.
Вот пример выполнения программы repadmin:
repadmin /showreps Washington\NTGROUP DSA Options (none) objectGuid 3a34efb9-f82e-11d2-a68d-00c04fb9d14e invocationID 39216b7e-f828-11d2-8128-00105a68cf ==== INBOUND NEIGHBORS ====================================== DC=dsysreskit,DC=reskit,DC=microsoft,DC=com Bldg\NTGROUP2 via RPC objectGuid: Cc6d76a3-a71a-l1d2-bbd0-00105a24d6db Last attempt о 1999-05-10 22:47.33 failed, result 1722:
The RPC server is unavailable.
Last success @ 1999-05-10 22:02,32.
Б consecutive failure(s).
CN=Schema, CN=Configuration,DC=reskit,DC=microsoft,DC=com Washington\WGRKSTATION1 via RPC objectGuid: ed8a3baO-d439-11d2-99e7-08002ba3ed3b Last attempt e 1999-05-10 22:47.32 was successful.
Washington\RESKIT-DC-07 via RPC objectGuid: 6a7ff635-baeb-11d2-8fda-0008c709d19e Last attempt з 1999-05-10 22:47.33 was successful.
Bldg\NTGROUP2 via RPC objectGuid: Cc6d76a3-a71a-11d2-bbd0-00105a24d6db Last attempt @ 1999-05-10 22:47.33 failed, result 1722:
The HPC server is unavailable.
Last success з 1999-05-10 22:02.32.
6 consecutive failure(s).
CN=Configuration, DC=reskit, DC=microsoft, DC=com Washington\WORKSTATION1 via RPC objectGuid: ed8a3baO-d439-11d2-99e7-08002ba3ed3b Last attempt @> 1999-05-10 22:47.32 was successful.
Bldg\NTGROUP2 via RPC objectGuid: Cc6d76a3-a71a-11d2-bbd0-00105a24d6db Last attempt 1999-05-10 22:47.33 failed, result 1722:
The RPC server is unavailable.
Last success о 1999-05-10 22:02.32.
6 consecutive failure(s).
Washington\RESKIT-DC-07 via RPC objectGuid: 6a7ff635-baeb~11d2-8fda-0008c709d19e Last attempt з 1999-05-10 22:48.26 was successful.
==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============ DC=dsysresklt,DC=reskit,DC=microsoft,DC=com WashingtorADSYSRESKITO via RPC objectGuid: abbf2810-f51b-11d2-84aO-00105a68cf Washington\RESKIT-DC-07 via RPC objectGuid: 6a7ff635-baeb-11d2-8fda-0008c709d19e Служба каталогов Active Directory 480 ЧАСТЬ CN=Schema,CN=Configuration,DC=reskit,DC=fnicrosoft,DC=com WashingtonXDSYSRESKITO via RPC objectGuid: abbf2810-f51b-11d2-84aO-00105a68cf Washington\RESKIT-DC-07 via RPC objectQuid: 6a7ff635-baeb-11d2-6fda-0008c709d19e Washington\WORKSTATION1 via RPC objectGuid: ed8a3baO-d439-11d2-99e7-08002ba3ed3b CH=Configuration,DC=reskit,DC=microsoft,DC=coin WashingtonXDSYSRESKITO via RPC objectGuid: abbf2810-f51b-11d2-84aO-00105a68cf Washington\RESKIT-DC-07 via RPC objectGuid: 6a7ff635-baeb-11d2-8fda-Q008c709d19e Washington\WORKSTATION1 via RPC objectGuid: 9d8a3baO-d439-11d2-99e7-08002ba3ed3b Просмотр состояния и производительности репликации Replmon.exe (Active Directory Replication Monitor) - это служебная программа с графическим интерфейсом пользователя, позволяющая наблюдать за низкоуровне вым состоянием и производительностью репликации между контроллерами доме на Active Directory. Она:
Х автоматически обнаруживает все разделы каталога на выбранном сервере, а так же серверы глобального каталога. Программа отображает сведения о том, явля ется ли данный компьютер сервером глобального каталога, автоматически об наруживает разделы каталога на текущем компьютере, отображает эту инфор мацию в графическом интерфейсе и предоставляет сведения о партнерах входя щей репликации для каждого раздела каталога. ReplMon раздельно отображает прямые и транзитивные партнеры репликации, серверы-плацдармы и удаленные из сети серверы. Сбойные партнеры репликации отображаются соответствую щим значком;
Х отображает серверы, с которыми компьютер обменивается данными реплика ции Ч как напрямую, так и опосредствованно (транзитивно);
Х отображает свойства данного сервера, в том числе: имя сервера, DNS-имя ком пьютера, положение учетной записи компьютера в Active Directory, состояние основного сервера-плацдарма, все специализированные флаги сервера (напри мер, эмулятор РОС данного домена), сведения о владельцах ролей одиночного хозяина и подключениях репликации (Replmon различает подключения, создан ные автоматически и вручную администратором);
Х для прямых партнеров репликации приводится информация о значении поряд кового номера обновления (update sequence number, USN), число неудачных по пыток, причины и флаги каждого партнера. На вкладках страниц свойств каж дого прямого партнера репликации содержатся следующие сведения: имя кон троллера домена, его GUID, раздел каталога, реплицируемый из него на данный сервер, вид используемого транспорта (RPC или SMTP, а также данные о внут ри- и межсайтовом транспорте в случае использования RPC), время последних успешных и предпринятых событий репликации, порядковый номер обновления (USN) и любые другие свойства подключения между этими двумя серверами;
Х содержит мастер сервера, позволяющий администраторам выбирать партнеры из списка, даже не зная имени сервера. Администратор также вправе создать файл с расширением.ini, содержащий список имен серверов для наблюдения. При Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 10 загрузке этого файла в ReplMon программа отображает в графическом интер фейсе пользователя сведения об указанных серверах;
автоматически определяет домен клиента и отображает эту информацию;
создает графическое представление внутрисайтовой топологии и предоставляет администратору контекстное меню каждого контроллера домена для быстрого отображения свойств сервера и существующих межсайтовых подключений. Под держивает режим отображения атрибутов, реплицированных в текущий сервер от его партнеров репликации;
отображает конфигурацию отдаленных контроллеров домена (например, сведе ния об обладании ролью эмулятора PDC);
в режиме Automatic Update регулярно опрашивает сервер с заданной админист ратором периодичностью для получения текущей статистики и состояния реп ликации. Эта функция создает хронологию изменений каждого наблюдаемого сервера и его партнеров репликации, позволяя администратору следить за из менениями топологии для отдельных серверов;
администраторы получают возможность синхронизировать между собой только два контроллера домена. Позволяет администраторам выполнять репликацию сервера с определенным партнером репликации, со всеми остальными контрол лерами домена в сайте или всеми контроллерами домена в данном и остальных сайтах, (Партнеры репликации задаются на основе данных, которые они содер жат. Не все контроллеры домена вовлекаются в этот процесс;
выбор определя ется синхронизируемым контроллером домена.);
администраторы вправе принуждать КСС к пересчету топологии репликации;
регистрирует действия, выполняемые служебной программой;
поддерживает журнал с хронологией состояния репликации сервера. Журнал доступен для просмотра в режиме Details. Программа ведет историю состояния репликации на уровне отдельных разделов каталога и партнеров репликации, предоставляя детальные сведения о событиях, происходящих с двумя контрол лерами домена;
поддерживает счетчик неудачных попыток репликации. Когда порядковый но мер сбоя достигает или превышает заданное администратором значение, про грамма регистрирует это событие в журнале или отправляет почтовое сообще ние. Число неудачных попыток репликации регистрируется для каждого парт нера репликации, и для них создается почтовое сообщение;
показывает администраторам, какие объекты еще не реплицированы из конкргт ного сервера;
отображает метаданные атрибутов объектов Active Directory, в том числе: имя атрибута, номер версии, время последнего изменения атрибута, контроллер до мена - источник последних изменений атрибута и номера обновлений (USN) на наблюдаемом сервере и на компьютере, где изменение инициировано;
предоставляет контекстные сведения и команды об использовании функций при размещении указателя мыши над ними;
генерирует отчеты для отдела технической поддержки. Позволяет администра тору создавать отчет о состоянии наблюдаемого сервера. В него включены дан ные о разделах каталога на сервере, о состоянии каждого партнера репликации ЧАСТЬ 1 Служба каталогов Active Directory (прямой и транзитивной) в каждом разделе каталога и о любых объектах груп повой политики, сведения о контроллерах домена, выполняющих FSMO-роли, моментальный снимок счетчиков производительности компьютера и информа ция о конфигурации реестра сервера (в том числе параметры КСС, Active Di rectory, Jet и LDAP). Кроме того, администратор способен добавить (в этот же отчет) данные о конфигурации предприятия, содержащие все сайты, связи сай тов, мосты связей сайтов, подсети и контроллеры любых доменов и свойства всех перечисленных объектов. Например, для контроллера домена приводятся информация о его GUID, соответствующей этому идентификатору записи в DNS и используемой для репликации, местонахождение учетной записи компьютера в Active Directory, почтовый адрес службы ISM (если он существует), имя ком пьютера и специальные флаги для сервера (например, флаг, указывающий на сервер глобального каталога). Эти сведения чрезвычайно полезны для устране ния неполадок репликации Active Directory;
Х поддерживает предоставление различных реквизитов проверки подлинности, позволяя ReplMon одновременно наблюдать за состоянием репликации контрол леров домена в нескольких лесах.
Требования, предъявляемые Replmon Монитор репликации Active Directory (Replmon) разрешается устанавливать на компьютере под управлением Microsoft Windows 2000 Professional или Win dows 2000 Server Ч на контроллере домена, рядовом сервере, рабочей станции до мена или на изолированном компьютере. Кроме того, Replmon применяют для од новременного наблюдения за контроллерами доменов в различных лесах.
Использование Ldp.exe для определения GUID объекта DSA GUID-идентификатор сервера Ч это основная информация, используемая в Active Directory и DNS для поиска контроллера домена в процессе репликации. Такой уникальный и повторно не используемый идентификатор автоматически присваи вается каждому контроллеру домена, Примечание Существуют различные GUID-идентификаторы, используемые для различных целей. GUID-идентификаторы в служебной программе Repadmin называ ются ^ Определение GUID объекта DSA контроллера домена 1. Средствами Ldp.exe выполните поиск раздела конфигурации со следующими параметрами: Base DN: CN=Sites,CN=Configuration,DC=ffoot0omainWame,DC=Corc Filter : (cn=NTDS Settings) Scope: Subtree Attributes: objectGUID Параметр RootDomainName замените на имя первого домена, созданного в пред приятии (корневой домен леса). 2. В результатах поиска Вы получите запись, представляющую сервер, GUID ко торого разыскивается. В возвращенных данных также должен присутствовать ат рибут objectGUID. Вот примерный вид сообщений программы: Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА ***Searching... ldap_search_s(ld, "cn=sites,cn=configuration,dc=reskit,dc=cora", 1, "(cn=NTDS Settings)", attrLlst, 0, &msg) Result <0>: (null) Matched DNs: Getting 1 entries: Dn: CN=NTDS Settings,CN='server-name',CN=Servers,CN='site name',CN=Sites,CN=Configuration, DC=reskit, DC=com 1> objectGUID: e99e82d5-deed-11d2-b15c-00c04f5cb503; В последней строке содержится искомое значение атрибута objectGUID объекта DSA. Подробнее о служебных программах командной строки для Active Directory - в справочной системе Windows 2000 Resource Kit. Восстановление после сбоя При отказе контроллера домена, вызванном внешней средой или сбоем оборудова ния, прежде всего следует восстановить сам контроллер домена, а затем приступать к восстановлению данных. Поскольку Active Directory Ч это не только транзакционная база данных, но и служба каталогов на основе этой базы данных, она способна восстанавливать поте рянную информацию: Х база данных восстанавливает потерянную информацию, используя сведения журналов; Х служба каталогов восстанавливает данные, обращаясь за ними и получая их от других серверов домена. Существует ряд служебных программ, предназначенных для восстановления как самого контроллера домена, так и службы каталогов Active Directory. Подробнее о защите от сбоев в Windows 2000, в том числе об архивировании, вос становлении и коррекции Ч в книге Сопровождение сервера. Ресурсы Microsoft Windows 2000 Server (Русская Редакция*, 2001), а также в документации к опе рационной системе и в справочной системе Microsoft Windows 2000 Server. Восстановление контроллера домена Существует несколько способов восстановления потерпевшего сбой контроллера домена под управлением Windows 2000 Server. Вы вправе использовать как одно, так и все эти средства и методы восстановления. Х Мастер Emergency Repair Disk (ERD) wizard (мастер Диск аварийного вос становления) служебной программы Ntbackup (Архивация). Войдите в сис тему под учетной записью Administrator (Администратор) или Backup Operator (Оператор архива). Используйте этот мастер для создания набора дисков, кото рые понадобятся в дальнейшем для восстановления контроллера домена. Х Переустановка операционной системы Windows 2000 и выполнение Active Directory Installation Wizard (Мастер установки Active Directory) (Dcp romo.exe). В случае серьезного сбоя, требующего полного восстановления ком Служба каталогов Active Directory 484 ЧАСТЬ ньютера, повторно установите операционную систему. Обеспечьте такое же, как и прежде, или большее число и размер дисковых томов. Повторно настройте се тевые подключения и DNS, как Вы это делали при первичной установке и на стройке. Х Служебная программа Netdom. При необходимости удалить домен запустите мастер установки Active Directory и удалите Active Directory со всех контрол леров удаляемого домена. Далее воспользуйтесь программой netdom для удале ния самого домена (в том числе объектов перекрестных ссылок и доверенных доменов). Например, введите в командной строке: netdom trust /remove /force Х Команда Cleanup служебной программы Ntdsutil. Чтобы удалить метаданные, оставшиеся после понижения роли или сбоя контроллера домена, воспользуй тесь командой Cleanup. Она удаляет ставшую неактуальной информацию о кон троллере домена и устаревшие данные из каталога. Кроме этого Вам, вероятно, придется дополнительно установить Active Directory (Dcpromo) и присвоить новому контроллеру домена старое имя. Обновленные данные и сведения о партнерах контроллер домена получит в процессе репликации. Подробнее об установке и удалении средствами Active Directory Installation Wizard (Мастер установки Active Directory) (служебная программа Dcpromo) Ч в главе Хранение данных в Active Directory. Подробнее о служебной программе Ntdsutil Ч в приложении В Ntdsutil.exe Ч служебная программа диагностики Active Directory. Восстановление резервного контроллера домена под управлением Windows NT 4. Важной задачей является восстановление потерянной учетной записи резервного контроллера домена под управлением Windows NT 4.0 в среде смешанного режима. Следует знать, как поступать в случае разрушения или случайного удаления такой учетной записи Примечание При случайном удалении компьютера Ч резервного контроллера до мена смешанного режима следует выполнить команду dsacls. ^ Восстановление учетной записи резервного контроллера домена 1. Войдите локально под административной учетной записью в систему проблем ного компьютера. 2. Запустите Server Manager. В меню Start щелкните Run и в открывшемся окне введите svrmgr. Откроется окно диспетчера сервера под управлением Windows NT 4.0/З.х. 3. Повторно создайте учетную запись резервного контроллера домена. (На самом деле эта операция выполняется на основном контроллере домена.) 4. Воспользуйтесь командой force sync для корректного сброса пароля. Восстановление после удаления учетной и доменной записи компьютера под управлением Windows Вот пример сообщения об ошибке, отображаемого при перезапуске компьютера пос ле удаления его учетной и доменной записи: Выявление и устранение неполадок, а также восстановление Active Directory ГЛАВА 10 event id 26 application pop-up Application popup: lsass.exe - System Error : Security Accounts Manager initialization failed because of the following error: No mapping between account names and security IDs was done. Error Status: Oxc0000073. Please click OK to shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information. После удаления учетной записи компьютера обязательно подождите, пока сведе ния об удалении не реплицируются во все контроллеры данного домена. До этого нельзя предпринимать никаких действий, в том числе выполнять присоединение к домену или запуск мастера установки Active Directory. В противном случае меха низм присоединения или мастер установки Active Directory повторно используют существующую учетную запись, и после репликации удаления возникнут пробле мы с загрузкой компьютера и/или входом в систему. Неполадки такого типа устраняются по-разному на клиентах, серверах и контрол лерах домена: Х в случае клиента или рядового сервера решение тривиально - попросту выпол ните присоедините его к домену; Х в случае контроллера домена следует учесть данные состояния системы, такие, как относительные идентификаторы (RID), основные имена служб (Service Principal Name) и подписку службы репликации файлов (FRS). Удаление учет ной записи влияет на данные состояния системы, и поэтому единственный вы ход Ч это повторная установка компьютера в качестве контроллера домена или принудительное восстановление учетной записи контроллера домена. Вот стандартный сценарий некорректного восстановления. Х Администратор удаляет учетную запись компьютера. Х Администратор повторно присоединяет сервер к домену. Х Процедура присоединения пытается найти контроллер домена с указанной учет ной записью. Это делается для проверки возможного наличия двойников учет ных записей на контроллере домена. Х Если удаление еще не успело распространиться на все контроллеры домена (на пример, если после удаления прошло времени меньше, чем требуется на репли кацию), обязательно найдется контроллер, который еще не получил сведений об удалении. Х Этот контроллер домена присоединяет компьютер к домену, устанавливает па роль, выполняет прочие дополнительные операции, после чего сообщает об ус пешном присоединении. Х Сведения об удалении реплицируются по всему домену, приводя к повторному уничтожению учетной записи. Восстановление Active Directory После восстановления самого контроллера домена следует восстановить на нем Active Directory. Служба каталогов Active Directory 486 ЧАСТЬ Х Репликация. Если в домене более одного контроллера домена, Active Directory восстанавливается посредством стандартной процедуры репликации данных от партнеров репликации, Х Ntbackup Backup and Restore Wizards [Мастеры архивации и восстановления служебной программы Архивация (Ntbackup)], Используйте их для восстанов ления состояния системы из архива, при этом восстанавливаются Active Directory, FRS (в том числе SYSVOL) и службы сертификации (если они были ранее уста новлены). К этому варианту следует обращаться, когда в домене нет других кон троллеров, с которых данный компьютер мог бы реплицировать данные. В случаях восстановления Active Directory после отказа или замены оборудования, когда данные на других контроллерах домена заведомо обновлены и устойчивы, Вы должны выполнять только непринудительное восстановление из последнего архи ва, После непринудительного восстановления механизм репликации Active Di rectory автоматически заполняет базу данных данного контроллера обновленной информацией из других контроллеров домена об изменениях, произошедших с мо мента создания архива. Дополнительные материалы Подробнее об Active Directory Ч на Web-странице Web Resources по адресу ссылка Microsoft Platform SDK. Подробнее о конкретных примерах неполадок, упомянутых в данной главе, а так же о текущих рекомендациях по диагностике и устранению неполадок Ч на Web странице Web Resources по адресу reskit/webresources, ссылка Microsoft Product Support Services. ЧАСТЬ Безопасность в распределенных системах и* Зашита и безопасность системы чрезвычайно важна как для руководителей, так и администраторов - независимо от масштаба управляемых ими сетей. В это части описаны функции Microsoft Windows 2000, используемые для защиты доступа к сетям и ресурсам, а также для обеспечения конфиденциальности и целостное)и данных и сообщений. В этой части Глава 11 Проверка подлинности Глава 12 Управление доступом Глава 13 Обеспечение безопасности средствами технологии открытого ключа Глава 14 Криптография в сетевых информационных системах Глава 15 Шифрованная файловая система Глава 16 Службы сертификации и инфраструктура открытого ключа в Windows 2000 I 7 Зак. ГЛАВА Проверка подлинности По умолчанию для сетевой проверки подлинности в Microsoft Windows 2000 ис пользуется протокол Kerberosv5. Этот недавно появившийся стандарт проверки подлинности применяется для взаимодействия различных систем, а также позво ляет повысить безопасность сетевой проверки подлинности в масштабах предпри ятия. Основные особенности реализации данного протокола, характерные Win dows 2000, Ч это интеграция входной проверки подлинности с архитектурой разо вого входа в систему (служба Winlogon), использование Active Directory в качестве базы учетных записей безопасности домена, реализация клиента Kerberos в каче стве поставщика безопасности в Windows 2000 через интерфейс SSP[ (Security Support Provider Interface). В этой главе Основы проверки подлинности Протоколы проверки подлинности Основы работы протокола Kerberos Компоненты Kerbcros в Windows 2000 Данные авторизации Интерактивный вход в систему 51М См. также Х Подробнее о том, как сетевые клиенты находят контроллер домена, - в главе Разрешение имен в Active Directory. Х Подробнее об авторизации Ч в главе 12 Управление доступом. Основы проверки подлинности Проверкой подлинности называют процесс выяснения аутентичности чего-либо или кого-либо. При проверке подлинности объекта требуется удостовериться в его неподдельности, а при проверке подлинности человека, Ч что он именно тот, за кого себя выдает. Проверка подлинности ГЛАВА 11 Проверка подлинности обоих типов производится при пересечении государствен ной границы. В ответ на просьбу пограничника предъявить документы въезжаю щий показывает свой паспорт. Пограничник проверяет подлинность паспорта (объекта), выясняя выдан ли он органом, пользующимся доверием властей его стра ны (или, по крайней мере, признаются ли в стране въезда выдаваемые таким орга ном паспорта). Кроме того, пограничник сличает лицо въезжающего (человека) с фо тографией в паспорте. Убедившись, что паспорт действителен и именно въезжающий является его владельцем, пограничник разрешает въезд. Если результат хотя бы од ной операции не удовлетворителен, въезжающему будет отказано во въезде в страну. Проверка подлинности при пересечении границы основана на действии механизма доверительных отношений. Власти страны въезда лично Вас не знают, но они дове ряют властям Вашей страны. Властям своей страны Вы также лично незнакомы, но при выдаче паспорта они доверяют Вашему свидетельству о рождении. Орган, выдавший свидетельство о рождении в свою очередь доверяет врачу, подписавше му акт о Вашем рождении. Доверительные отношения, передаваемые подобным образом - через доверенных посредников, называются транзитивными. Транзитив ное доверие между центрами безопасности (security authority) является основопо лагающим принципом сетевой безопасности в Windows 2000. Интерактивный вход в систему Вход в систему с клавиатуры компьютера под управлением Windows 2000 напоми нает пересечение границы. Пограничник просит предъявить удостоверение лично сти, а въезжающий показывает документы, выданные органами власти. В нашем случае пограничник - это Winlogon, служба подсистемы безопасности, выполняю щаяся в процессе диспетчера локальной безопасности (Local Security Authority, LSA). Winlogon открывает диалоговое окно, где требует указать учетную запись и имя создавшего его центра безопасности. В системах под управлением Windows 2000 права па учетную запись подтверждаются паролем. В системах, ос нащенных специальным оборудованием, данные, необходимые для проверки под линности, разрешается считывать со смарт-карты. Полученные идентификацион ные данные Winlogon упаковывает в структуру данных определенного формата и направляет в LSA для проверки. После того как LSA установит, что указанная учет ная запись существует, и подтвердит полномочия входящего в систему, Winlogon от кроет интерактивный сеанс. В противном случае доступ в компьютер будет закрыт. Способ подтверждения подлинности в LSA зависит от того, где создана учетная запись. Созданную им самим учетную запись диспетчер локальной безопасности проверяет по своей базе данных учетных записей. Для проверки учетной записи, созданной диспетчером безопасности данного или доверенного домена, LSA связы вается с соответствующим диспетчером безопасности и запрашивает сведения о ее наличии и владельце. Удаленный вход в систему Независимо от того, где подтверждается подлинность, она всегда подтверждается только одним диспетчером безопасности - LSA компьютера, с которого произво дится вход в систему. Доступность учетных записей домена обусловлена тем, что LSA данной рабочей станции доверяет центру безопасности домена. Аналогично ему доверяют и другие компьютеры под управлением Windows 2000, принадлежа щие этому домену, однако, чтобы получить доступ к их ресурсам, необходимо вой 490 ЧАСТЬ 2 Безопасность в распределенных системах ти в систему с каждого из них. В данном случае не имеет значения, что Ваш пас порт проштампован при входе в систему с последнего используемого компьютера. Паспорт нужно предъявлять всякий раз при входе в систему в качестве сетевого клиента под управлением Windows 2000. При попытке получить доступ к ресурсам удаленного компьютера под управлени ем Windows 2000 по сети Ч с локальною компьютера Ч вводить информацию в диалоговое окно с клавиатуры уже не нужно. LSA текущей рабочей станции уста новит Вашу подлинность, обратившись к LSA удаленного компьютера и восполь зовавшись данными, помещенными в кэш во время первичного интерактивного вхо да в систему. Участники безопасности Любой объект, способный инициировать действие в системе под управлением Windows 2000 является участником безопасности (security principal). Участниками безопасности могут быть не только пользователи, но и компьютеры, и службы (лде моны в терминологии UNIX). Участник безопасности согласно сценарию предос тавляет системе, в которой собирается работать, свои верительные грамоты, вы данные доверенным центром безопасности. Например, входящие в домен компью теры под управлением Windows 2000 должны поддерживать связь с контроллером домена даже в то время, когда никто из пользователей не находится в системе. Для входа в домен компьютеру необходимо иметь свою учетную запись, реквизиты ко торой он должен предъявлять при входе. Прежде чем компьютер войдет в домен, LSA контроллера домена проверяет его подлинность таким же способом, как и под линность пользователей, В отличие от приложений, запускаемых пользователем и выполняющихся в его контексте безопасности, служба в Windows 2000 запускается контроллером служб. Зачастую служба запускается автоматически при загрузке компьютера и продол жает работу даже после того, как последний пользователь покинет систему. Подоб но пользователям, чтобы получить доступ к ресурсам домена, службы должны в него войти. В процессе запуска службы контроллер служб входит в систему под учетной записью этой службы и предоставляет LSA ее реквизиты. Например, при входе компьютера под управлением Windows 2000 в домен служба Net Logon (Сетевой вход в систему) текущего компьютера соединяется с контрол лером домена и создает безопасный капал связи. Чтобы успешно пройти проверку подлинности при соединении с контроллером домена, Net Logon необходимо пред ставить реквизиты, которым доверяет LSA удаленного компьютера, при этом она, как и прочие службы, выполняющиеся в контексте локальной системы, использует реквизиты учетной записи компьютера в домене. Служба, не работающая в контек сте локальной системы, должна иметь собственную учетную запись в домене. Протоколы проверки подлинности Windows 2000 поддерживает несколько протоколов, предназначенных: для удостове рения подлинности пользователей, имеющих учетные записи в системе. К ним так же относятся протоколы проверки подлинности удаленных соединений и пользова телей, входящих в сеть через Интернет. Вместе с тем для сетевой проверки подлин ности внутри и между доменами Windows 2000 используется всего два протокола. Протокол Kerberos v5 Ч применяется по умолчанию для проверки подлинности пользователей, входящих в домен с компьютеров под управлением Windows 2000. Проверка подлинности ГЛАВА 11 Протокол NTLM. Использовавшийся по умолчанию в Microsoft Win dows NT версии 4.0, он сохранен в Windows 2000 для обратной совместимости с клиентами и серверами под управлением более ранних версий Windows NT. Kerberos применяется всегда, когда есть возможность выпора между двумя выше указанными протоколами. Во всех случаях, когда требуется обеспечить совмести мость с предыдущими версиями Windows, применяется протокол NTLM. On исполь зуется клиентами под управлением Microsoft Windows 3.11, Microsoft Windows 95, Microsoft Windows 98 и Windows NT 4.0 в доменах Windows 2000 и клиентами под управлением Windows 2000 в доменах Windows NT 4.0. Основы работы протокола Kerberos В протоколе Kerberos реализован механизм взаимной проверки подлинности при создании сетевого соединения между клиентом и сервером. Протокол предназна чен для обеспечения взаимодействия клиента и сервера в открытой сети Ч в окру жении, в котором большинство клиентов и серверов не защищены физически и пе редающиеся по сети пакеты можно перехватить и изменить. Другими словами, дан ный протокол разработан для применения в подобном Интернету сетевом окруже нии, где злоумышленник может легко выступать как в качестве клиента, так и сер вера, и перехватывать или подменять пакеты, которыми обмениваются атакуемые объекты сети. Основы Kerberos Протокол Kerberos использует технологию проверки подлинности, основанную на секретной информации, известной только избранным. Сущность этой технологии весьма проста: если секрет известен только двоим лицам, то каждый из них может быть уверен, что имеет дело именно со вторым партнером, если тому известен этот секрет. Предположим, что Алиса переписывается с Бобом, а Боб, прежде чем воспользо ваться заключенной в ее сообщении информацией, желает убедиться в авторстве Алисы. Они договариваются о пароле, который известен только им двоим. Если послание однозначно указывает на то, что его отправитель знает пароль, Боб мо жет быть уверен в том, что сообщение написала именно Алиса. Неясным остается вопрос, каким образом Алиса подтвердит знание пароля. Пред положим, что она напишет его в тексте своего сообщения сразу после подписи. Та кой способ подтверждения оправдан только при условии, что никто кроме Боба и Алисы не в состоянии прочитать сообщения, которыми они обмениваются. К сожа лению, системы электронной почты этого не обеспечивают. Нет никаких гарантий, что какой-нибудь другой пользователь (назовем ее Кэрол) не воспользуется сете вым анализатором и не начнет просматривать трафик сети, пытаясь перехватить пароли. Совершенно очевидно, что Алиса не сможет просто сказать Бобу установ ленный пароль (например, по телефону). Таким образом, Алисе придется доказать, что она знает пароль, не разглашая его. В протоколе Kerberos эта проблема решается с помощью криптографии с секрет ным ключом. Партнеры используют не общий пароль, а общий криптографический ключ, то есть знание секретного ключа является подтверждением аутентичности. При таком способе проверки подлинности необходим симметричный ключ, то есть один и тот же ключ должен применяться как для шифрования, так и расшифровки. В процессе обмена каждая из сторон подтверждает свое знание общего ключа, не Безопасность в распределенных системах 4!)2 ЧАСТЬ пользуя его для шифрования сообщений; то. что другая сторона способна расшиф ровать сообщение и становится подтверждением ее аутентичности. Аутентификаторы Для проверки подлинности желающего войти в защищенную систему применяется простой протокол, использующий секретный ключ. При входе инициатор соедине ния предъявляет свой аутентификатор (authenticator) в виде информации, зашиф рованной секретным ключом. Предоставляемая в качестве аутентификатора инфор мация должна быть уникальна для каждого сеанса проверки, что исключит возмож ность ее перехвата и повторного использования для незаконного проникновения в систему. Служба безопасности защищенной системы получает этот аутентифика тор и расшифровывает его. Если эта операция прошла успешно, служба безопасно сти уверена в том, что предъявитель аутентификатора владеет верным ключом. Так как владеть данным ключом могут только двое, а служба безопасности - одна из них, то владельцем второго является предъявитель аутентификатора. Если инициатор соединения требует взаимного подтверждения подлинности, опи санная выше процедура с небольшими изменениями выполняется в обратном по рядке. Служба безопасности, получив и расшифровав предъявленный аутентифи катор, извлекает из него часть информации и зашифровывает ее в новый аутенти фикатор, который и отправляет инициатору соединения. Тот расшифровывает его и сравнивает со своим оригиналом. Совпадение данных является подтверждением того, что служба безопасности смогла расшифровать оригинал, и следовательно, ее ключ верен. Проиллюстрируем описанную выше процедуру. Предположим, что Алиса и Боб условились, что, прежде чем начать обмен данными, каждый из них установит под линность партнера, применив знание общего секретного ключа. Если Алиса высту пает в роли осторожного гостя, а Боб Ч недоверчивого хозяина, то они, по обоюд ной договоренности, будут соблюдать порядок, описанный ниже. 1. Алиса передаст Бобу сообщение, содержащее ее имя открытым текстом и аутен тификатор, зашифрованный общим секретным ключом. Согласно договоренно сти, данные в аутентификаторе хранятся в структуре, состоящей из двух полей. В первом поле находится информация о самой Алисе (для простоты Ч ее имя). Второе поле содержит метку времени на рабочей станции Алисы. 2. Получив сообщение от отправителя, называющего себя Алисой, Боб расшифро вывает аутентификатор общим ключом и оценивает достоверность штампа вре мени. Синхронизация времени на компьютерах существенно облегчит Бобу его зада чу, поэтому предполагается, что синхронизация часов Алисы и Боба обеспечи вается сетевой службой времени. Допустим, что временной сдвиг не может пре вышать пяти минут. Боб сравнивает время, указанное в аутентификаторе, с по казаниями своих часов. Если разница оказывается больше пяти минут, аутенти фикатор автоматически отвергается. Если разница во времени находится в пределах допустимого сдвига, то вполне возможно, что аутентификатор прислала Алиса. Тем не менее существует вероят ность, что некто, просматривая сетевой трафик, перехватил предыдущую попыт ку Алисы установить соединение <: Бобом и воспроизвел ее со своего компьюте ра. Однако, проследив историю меток времени, заключенных в аутентификато Проверка подлинности ГЛАВА pax, присланных Алисой в течение последних пяти минут, Боб сможет обнару жить попытки воспроизвести предыдущие запросы и отвергнуть сообщения с мет ками времени более ранними или идентичными метке в последнем аутентифика торе. Алиса признается автором сообщения только при условии, что метка време ни в аутентификаторе более поздняя, чем в предыдущем аутентификаторе. 3. Боб зашифровывает метку времени из сообщения Алисы с помощью обшего ключа и отправляет сообщение обратно. Обратите внимание, что Боб отправляет обратно не всю информацию из аутен тификатора Алисы, а только метку времени. В противном случае (если зашиф ровать всю информация их аутентификатора) Алиса не сможет убедиться в под линности сообщения Ч нет никаких гарантий, что некто, выдающий себя за Боба, не скопировал аутентификатор и не отправил его обратно р неизменном виде. Передавая лишь часть информации, Боб демонстрирует, что ему удалось расшифровать аутентификатор и изменить информацию, находившуюся в нем. Выбор метки времени определяется его уникальностью и тем, что он заведомо известен Алисе. 4. Получив от Боба ответ, Алиса расшифровывает его и сравнивает присланную метку времени с меткой в исходном аутентификаторе. При совпадении она мо жет быть уверена, что ее сообщение дошло до кого-то, кто владеет секретным ключом, тот смог расшифровать его и извлечь данные. Так как общий ключ из вестен только Бобу, то получается, что прочитал сообщение и ответил на него именно Боб. Описанная процедура проиллюстрирована на рис. 11-1. "Я Алиса 1, КДБЙЛИСЭ, метка времени} Алиса КдЕ,(метка времени! "-л*" Рис. 11-1. Простой протокол взаимной проверки подлинности Распространение ключей Однако остается неясным, как и откуда Алиса и Боб получили секретный ключ. Люди могут где-нибудь встретиться и согласовать секретный ключ. Но, если Алиса - программа-клиент, выполняющаяся на рабочей станции, а Боб Ч служба, запу щенная на сетевом компьютере, такой способ не подходит. Проблема может усу губляться тем, что клиенту Алиса требуется много служб, для каждой из которых необходим свой ключ, а служба Боб взаимодействует со множеством клиентов, для которых тоже нужны ключи. Распространение ключей в условиях, когда от каждо го клиента требуется наличие ключа для каждой службы и от каждой службы наличие ключа для каждого клиента, быстро становится трудноразрешимой зада чей. Кроме того, чрезвычайно сложно обеспечить безопасность такого количества ключей, хранящихся на многочисленных компьютерах. Название протокола Kerberos указывает на то, как его средствами решается пробле ма распространения ключей. Согласно греческой мифологии, Kerberos (в русской транскрипции Цербер*) Ч это трехглавый пес, охраняющий царство мертвых. По Безопасность в распределенных системах 494 ЧАСТЬ добно мифологическому сторожевому псу, одноименный протокол также может по хвастаться тремя головами - это клиент, сервер и доверенная третья сторона, вы полняющая роль посредника между первыми двумя. Такой доверенный посредник называется центром распространения ключей (Key Distribution Center, KDC). KDC - это служба, выполняющаяся на физически защищенном сервере. Она под держивает базу данных, содержащую информацию обо всех учетных записях всех участников безопасности в своей сфере (realm) - эквиваленте домена Windows применительно к протоколу Kerberos. Вместе с прочей информацией об участни ках безопасности КОС хранит криптографический ключ, известный только участ нику безопасности и KDC. Этот ключ называется долгосрочным (long-term key) и используется для обмена данными между участником безопасности и КОС. В боль шинстве реализаций протокола Kerberos долгосрочный ключ создается на основа нии пользовательского пароля входа в систему. Желая подключиться к серверу, клиент отправляет запрос в KDC, и тот выдает обо им участникам безопасности уникальный ключ сеанса (session key), который сторо ны используют для взаимной проверки подлинности (рис. 11-2). Серверный экзем пляр ключа сеанса шифруется долговременным ключом сервера, а клиентский долговременным ключом клиента. ^^ КЛИЕНТ желает.mscs создает подключиться к серверу ключ ^клиент Шля обмена с "* КсерНер1Для обмена с ЩЧ| сеанса Клиент сервером использовать ключ клиентом использовать ключ S(; gS Сервер S CS Рис. 11-2. Распространение ключей (в теории) Теоретически КОС может играть роль доверенного посредника, отправляя ключ сеанса непосредственно каждому из участников безопасности так, как это изобра жено на рис. 11-2. Однако на практике реализовать указанную процедуру чрезвы чайно сложно, так как серверу придется хранить ключ сеанса до момента получе ния запроса от клиента. Кроме того, серверу придется хранить ключи не только для данного, но и для всех остальных клиентов, которые могут запросить соединение. Управление ключами в таком случае потребует значительных ресурсов сервера, ог раничивая его масштабируемость. В связи с непредсказуемостью сетевого трафика запрос клиента иногда достигает сервера раньше, чем сообщение от KDC с ключом сеанса. В этом случае серверу придется отложить обслуживание клиента до полу чения ответа KDC, а для этого Ч сохранить состояние соединения, что потребует дополнительных ресурсов. Б действительности Kerberos действует намного эффек тивнее. Билеты сеансов В ответ на запрос клиента о создании соединения с сервером служба КОС отправ ляет ему обе копии ключа сеанса (рис. 11-3). Ключ клиента шифруется ключом, общим для КОС и клиента. Ключ сервера находится вместе с информацией об ав торизации клиента в структуре данных, именуемой билетом сеанса (session key) и зашифрованной ключом, общим для КОС и сервера. Билет сеанса и заключенный в нем серверный ключ сеанса находятся в распоряжении клиента до момента его обращения к серверу. Проверка подлинности ГЛАВА К" Г! Г, Клиент желает подключиться к серверу Создает ключ сеанса К к л и е н т (Для обмена с сервером использовать ключ Scgl, билет SGS сеанса = Ксервер|Для обмена с клиентом использовать ключ SQS) Рис. 11-3, Распространение ключей (на практике) Обратите внимание, что KDC занимается только выдачей ключей, но не контроли рует их доставку клиенту. Возможность перехвата ключа не представляет опаснос ти, так как только владелец секретного ключа клиента сможет расшифровать кли ентский экземпляр ключа сеанса и только владельцу секретного ключа сервера уда стся прочитать билет сеанса. Получив ответ от KDC, клиент извлекает билет сеанса и свой ключ сеанса и поме щает их в безопасный, невыгружаемый на диск кэш в оперативной памяти. Когда клиенту требуется доступ к серверу, он отправляет сообщение, состоящее из биле та сеанса, зашифрованного секретным ключом сервера, и аутентификатора, зашиф рованного ключом сеанса (рис. 11-4). Билет сеанса и аутентификатор являются верительными грамотами, которые клиент предъявляет серверу. Зс$1клиент; метка времени!, билет сеанса = КсепВер1Для обмена с клиентом использовать ключ $csl Клиент Сервер Рис. 11-4. Взаимная проверка подлинности клиента и сервера Получив от клиента эти данные, сервер своим секретным ключом расшифровывает билет сеанса и извлекает из него ключ сеанса, которым расшифровывает аутенти фикатор клиента. При успешном завершении всех операций сервер получает под тверждение того, что верительные грамоты клиента выданы доверенным центром безопасности Ч KDC. Если клиенту требуется взаимная проверка подлинности, сервер шифрует ключом сеанса метку времени, извлеченную из аутентификатора клиента, и возвращает ее обратно так же, как Боб возвращал Алисе зашифрован ную метку времени в примере, описанном ранее (см. рис. 11-1). Главное преимуще ство билетов сеанса Ч это отсутствие необходимости хранить ключи сеанса на сер вере. Теперь клиент сам отвечает за хранение билета сеанса в безопасном кэше и передачу его серверу. А серверу достаточно, получив от клиента билет сеанса, из влечь из него при помощи своего секретного ключа свой ключ сеанса. По оконча нии сеанса сервер уничтожает ставший ненужным ключ. Другое преимущество билетов сеанса заключается в том, что клиенту не приходит ся обращаться к КОС каждый раз, когда требуется подключиться к серверу. Биле ты сеанса разрешается использовать многократно. В качестве меры безопасности против возможной кражи билета применяется ограничение срока его действия, све дения о котором КОС размещает в структуре данных билета. Срок действия биле та сеанса определяется политикой Kerberos для домена. Обычно билеты действи тельны не более восьми часов (средняя продолжительность сеанса работы в систе ме). При выходе пользователя из системы безопасный кэш очищается, и все биле ты и ключи сеанса уничтожаются. Безопасность в распределенных системах 496 ЧАСТЬ Билеты TGT Долгосрочный ключ пользователя создается на основе пароля. Например, когда Али са входит в систему, клиент Kerberos рабочей станции принимает ее пароль и при помощи односторонней хэш-функции преобразует его в криптографический ключ. КОС извлекает долгосрочный ключ Алисы из базы данных учетных записей. По лучив запрос от клиента Kerberos рабочей станции Алисы, KDC находит в своей базе данных учетную запись Алисы и извлекает из соответствующего поля ее дол госрочный ключ. В действительности процедура преобразования пароля в первый экземпляр ключа и извлечения второго экземпляра ш записи в базе данных выполняется только один раз при первом входе пользователя в сеть. Получив пользовательский пароль и преобразовав его в долгосрочный ключ, клиент Kerberos рабочей станции пользо вателя сразу запрашивает у КОС билет и ключ сеанса, которые применяются в по следующей работе с KDC до окончания текущего сеанса в системе. КОС отвечает на запрос клиента, возвращая билет сеанса для работы с самим KDC. Этот особый билет сеанса называется билетом TGT (ticket-granting ticket). Подоб но обычному билету сеанса, TGT содержит ключ сеанса, которым служба (в дан ном случае КОС) пользуется для связи с клиентом. Вместе с TGT в сообщении от КОС находится ключ сеанса для связи клиента с центром распространения клю чей. TGT шифруется долговременным ключом КОС. Клиентский экземпляр клю ча сеанса шифруется долговременным ключом клиента. Получив ответ из центра распространения ключей, клиент расшифровывает свой экземпляр ключа сеанса находящимся в кэше долговременным ключом пользова теля. После этого необходимость в долговременном ключе отпадает, и он уничто жается. Впоследствии для связи с KDC клиент использует ключ сеанса. Как и все ключи сеансов, этот ключ временный, он действует до окончания срока действия билета TGT или до выхода пользователя из системы, поэтому его еще называют ключом сеанса в системе (logon session key), С точки зрения клиента TGT Ч это просто еще одна разновидность билета. Преж де чем отправить службе запрос на соединение, клиент проверяет наличие билета сеанса в своем безопасном кэше. Если его там нет, клиент снова проверяет кэш, пытаясь найти в нем билет TGT. Если TGT отыскивается, клиент берет из кэша соответствующий ключ сеанса в системе, шифрует им свое аутентификатор и на правляет в КОС сообщение, содержащее данный аутентификатор, TGT и запрос билета сеанса для службы. Другими словами, процедура получения доступа к KDC ничем не отличается от процедуры получения доступа к любой другой службе доме на, для нее требуется ключ сеанса, аутентификатор и билет (в данном случае TGT). TGT позволяет сократить время, затрачиваемое КОС на обработку клиентских за просов. КОС только один раз выполняет поиск долговременного ключа клиента, после чего предоставляет ему TGT. В последующих соединениях с клиентом КОС расшифровывает TGT своим долговременным ключом, извлекает из него ключ се анса в системе и применяет его для расшифровки и проверки пользовательского аутентификатора. Проверка подлинности между доменами Работу центра распространения ключей обеспечивают две четко разделенные служ бы: служба проверки подлинности, занимающаяся выдачей билетов TGT, и служба Проверка подлинности ГЛАВА 11 TGS (ticket granting service), ответственная за выдачу билетов сеансов. Такое раз деление обязанностей позволяет протоколу Kerberos простирать свое влияние за пределы отдельного домена. Клиент вправе получить билет TGT в службе провер ки подлинности одного домена и воспользоваться им для получения билетов сеан са в службе TGS другого домена. Чтобы пояснить, как проверяется подлинность между доменами, рассмотрим самый простой вариант Ч сеть, состоящую из двух доменов, например East и West. Если администраторы доменов работают в одной организации или по каким либо при чинам требуется, чтобы пользователи одного домена имели право подключаться к ресурсам другого, администраторы могут разрешить проверку подлинности меячду доменами с помощью общих междоменных ключей. (В Windows 2000 это происхо дит автоматически при установлении доверительных отношений между доменами.) В этом случае служба TGS каждого из доменов будет зарегистрирована в качестве участника безопасности в КОС другого домена. Это значит, что служба TGS каж дого из доменов рассматривает аналогичную службу другого домена как обычную службу, для доступа к которой клиенты, чья подлинность проверена, могут запра шивать и получать билеты сеансов. Если пользователь домена East желает получить доступ к серверу в домене West, клиент Kerberos рабочей станции пользователя запросит билет сеанса у службы TGS своего домена. Служба TGS домена East, обнаружив, что запрашиваемый сер вер не является участником безопасности данного домена, возвратит клиенту би лет перенаправления (referral ticket), представляющий собой билет TGT, зашифро ванный междоменным ключом, общим для КОС доменов East и West. Клиент ис пользует билет перенаправления в своем повторном запросе, который на этот раз направляет службе TGS в домене сервера West. Служба TGS домена West расшиф ровывает полученный билет перенаправления своим междоменным ключом и, если расшифровка прошла успешно, высылает клиенту билет сеанса с сервером. Процедура перенаправления более сложна в сетях, состоящих из трех и более до менов. Теоретически KDC каждого из доменов способен устанавливать прямые свя зи с KDC других доменов в сети, создавая для каждой отдельный общий междо менный ключ. На практике такие связи, из-за их большого числа и сложности, по чти невозможно контролировать, особенно в условиях больших сетей, В протоколе Kerberos эта проблема решена - прямые связи в нем просто не нужны. Клиент мо жет получить билет сеанса с сервером другого домена, пройдя по цепи перенаправ лений через один или несколько промежуточных доменов. В качестве примера рассмотрим сеть из трех доменов: East, West и CorpHQ. Допу стим, что у центров распространения ключей доменов East и West нет общего мсж домешюго ключа, однако оба владеют общими ключами с доменом CorpHQ. Цепь перенаправлений запроса пользователя из домена East к серверу в домене West бе рет начало из центра распространения ключей домеш пользователя - East, далее проходит через промежуточный домен CorpHQ и в результате попадает в КОС до мена сервера (West). В приведенном примере, клиент трижды отправляет запрос билета сеанса, каждый раз различным КОС. 1. Клиент запрашивает билет сеанса с сервером в домене West у КОС домена Ea--t. КОС домена East возвращает клиенту билет перенаправления к КОС домена CorpHQ, зашифрованный общим междоменным ключом доменов East и CorpHQ. ЧАСТЬ 2 Безопасность в распределенных системах 2, Клиент запрашивает билет сеанса с сервером в домене West у КОС домена CorpHQ. KDC домена CorpHQ отсылает клиенту билет перенаправления к КОС домена West, зашифрованный общим междоменным ключом доменов CorpHQ и West. 3. Клиент запрашивает билет сеанса с сервером в домене West у КОС домена West. КОС домена West направляет клиенту билет сеанса с сервером в домене West, Подпротоколы В состав Kerberos входят три подпротокола: AS Exchange (Authentication Service Exchange - AS-обмен) применяется КОС для отправки клиенту ключа сеанса в системе и билета TGT; TGS Exchange (Ticket-Granting Service Exchange Ч TGS обмен) служит КОС для распространения ключей сеансов и билетов сеансов со службами и CS Exchange (Client/Server Exchange Ч CS-обмен) используется кли ентом для передачи билета сеанса соответствующей службе. AS Exchange AS-обмен начинается, когда Алиса входит в сеть. Она вводит имя пользователя и пароль. Клиент Kerberos ее рабочей станции преобразует пароль в ключ шифрова ния и помещает его в кэш удостоверений (credentials cache). Клиент направляет запрос клиента Kerberos (сообщение формата Kerberos Authen tication Service Request, KRB_AS_REQ) службе проверки подлинности КОС. В первой части этого сообщения указывается имя пользователя (Алиса) и служба, доступ к которой запрашивается (служба TGS), как показано на рис. 11-5. Вторая часть сообщения содержит предварительную информацию для проверки подлин ности, она подтверждает, что Алиса знает пароль. Обычно это метка времени, за шифрованная долгосрочным ключом Алисы, хотя протокол допускает использова ние и другой информации для предварительной проверки. KRB_AS_REO КОС Алиса запрашивает службу TGS. AS создает Кдлц С а 1Алиса, метка времени! Алиса ключ сеанса Кд л и с а Щля обмена с TGS использовать ключ 5длиса1, ^Алиса Т6Т = KJGS Шля обмена с Алисой использовать ключ 5д П иса KRB_AS_REP Рис. 11-5. AS Exchange Получив запрос KRB_AS_REQ, КОС находит пользователя (Алису) в своей базе данных, извлекает его долгосрочный ключ, расшифровывает сообщение и проверя ет содержащуюся в нем метку времени. В случае успеха КОС может быть уверен в подлинности клиента, то сеть что сообщение зашифровано долгосрочным ключом Алисы. Получив подтверждение подлинности Алисы, KDC создает реквизиты, которые клиент Kerberos ее рабочей станции может предъявить службе TGS. Б первую оче редь КОС создает ключ сеанса в системе и шифрует его долгосрочным ключом Алисы. Затем заключает второй экземпляр ключа сеанса в системе в билет TGT вместо с информацией о самой Алисе (о ее авторизации), шифрует билет TGT соб Проверка подлинности ГЛАВА 11 ственпым долгосрочным ключом и, наконец, отправляет все эти документы обрат но клиенту Kerberos (сообщение формата Kerberos Authentication Service Reply, KRB_AS_REP). Получив ответ, клиент при помощи ключа, полученного из пароля Алисы, извлека ет ключ сеанса в системе и билет TGT и сохраняет их в кэше удостоверений. TGS Exchange Для получения доступа к службе (например, к службе по имени Боб) клиент Kerberos рабочей станции Алисы направляет КОС сообщение-запрос KRB_TGS_RKQ (Kerberos Ticket-Granting Service Request), как показано на рис. 11-6. Данное сооб щение содержит имя пользователя, аутентификатор, зашифрованный пользователь ским ключом сеанса в системе, билет TGT, полученный в результате А3~обмсна ; и имя службы, для которой запрашивается билет. KRB_TGS_REQ *Щ Алиса запрашивает службу Боб, Кд л ^ с а {Алиса, метка времени]. обмена с Алисой использовать ключ 5д л и с а ) Алиса ЗДписаШля обмена с Бобом использовать ключ Бд^], ключ обмена с Алисой использовать ключ KRB_TGS_REP Рис. 11-6. TGS Exchange Получив KRB_TGS_REQ, центр распространения ключей расшифровывает билет TGT собственным секретным ключом и извлекает из него принадлежащий Алисе ключ сеанса в системе. Затем этим ключом KDC расшифровывает и проверяет аутептификатор. При положительном результате проверки КОС извлекает инфор мацию об авторизации Алисы из билета ТОТ и создает общий ключ сеанса для кли ента (Алисы) и службы (Боба). Первый экземпляр этого ключа шифруется клю чом сеанса в системе Алисы, а второй вместе с информацией об авторизации Али сы заключается в билет, зашифрованный долгосрочным ключом Боба. Далее все документы отправляются обратно клиенту в сообщении-ответе KRB_TGS_RKP (Kerberos Ticket-Granting Service Reply). Получив ответ KDC, клиент (Алиса) рас шифровывает своим ключом сеанса в системе ключ сеанса со службой и записыва ет его в кэш удостоверений. Затем, он извлекает билет сеанса со службой и также сохраняет его в кэше удостоверений. CS Exchange Чтобы получить доступ к службе Боб, клиент Kerberos рабочей станции Алисы на правляет ей сообщение-запрос KRB_AP_REQ (Kerberos Application Request), как показано на рис. 11-7. Указанное сообщение содержит аутентификатор, зашифро ванный ключом сеанса со службой, билет, полученный в результате TGS-обмена и флаг, указывающий, нужна ли клиенту взаимная проверка подлинности. (Прото кол Kerberos обеспечивает взаимную проверку подлинности, которая, тем не менее, не является обязательной. Клиенты под управлением Windows 2000 всегда требу ют взаимной проверки подлинности. Клиенты, работающие с другими реализация ми протокола, могут этого не делать.) ЧАСТЬ 2 Безопасность в распределенных системах KRB_AP_REQ 5дБ1Алиса, метка времени], билет сеанса = обмена с Алисой использовать ключ Алиса. | - Щ - - Ч Заметка времени] Щлл*ЩЩ*-Щ л- -Щ- ** KRB_APJ*EP Рис. 11-7. CS Exchange Получив сообщение KRB_AP_REQ, служба Боб расшифровывает билет, извлекает информацию об авторизации Алисы и ключ сеанса, расшифровывает им аутенти фикатор Алисы, после чего проверяет содержащуюся в аутентификаторе метку вре мени. Если проверка прошла успешно, Боб проверяет состояние флага взаимной проверки подлинности. Если флаг установлен, Боб шифрует метку времени из аутентификатора Алисы ключом сеанса и возвращает его клиенту в сообщении-от вете KRB_AP_REP (Kerberos Application Reply). Получив сообщение KRB_AP_REP, клиент на рабочей станции Алисы расшифро вывает аутентификатор Боба общим ключом сеанса и сравнивает возвращенный службой метку времени с оригиналом. В случае совпадения клиент убеждается в подлинности службы и продолжает работу с пей. Во время соединения стороны могут шифровать данные приложений существующим ключом сеанса или поменять его и использовать для этих целей другой ключ. Билеты При настройке политики протокола Kerberos важно знать, что содержится в биле те, как определяется срок его действия и что из содержания билета известно кли енту. Поэтому билеты мы рассмотрим более тщательно. Содержание билета Сообщения и билеты Kerberos формируются в соответствии с установленной струк турой данных и форматом. Подробнее о полях билетов и флагах Ч на Web-страни це Web Resources по адресу: webresources, ссылка Request for Comments (RFC) и далее Ч ссылка RFC; 15'0. Ограничение срока действия билета средствами КОС У билетов Kerberos есть начало и окончание срока действия. Клиент, владеющий билетом сеанса с определенной службой, имеет право предъявить его и получить доступ к службе в любой момент времени между началом и окончанием срока дей ствия билета независимо от того, сколько раз этот билет уже использовался. Что бы снизить риск компрометации билета или соответствующего ключа сеанса, ад министраторы могут устанавливать максимальный срок действия билета. Такой срок является элементом политики Kerberos в домене. Клиент, запрашивающий у КОС билет сеанса со службой, вправе указать опреде ленное время начала действия. Если это время в запросе опущено или уже прошло, КОС заносит в поле starttime начала действия билета текущее время. Независимо от того, указывает ли клиент время начала действия или нет, в запросе обязательно должно быть обозначено время окончания действия билета. КОС вы числяет значение поля endtime окончания действия билета, прибавляя к значению Проверка подлинности ГЛАВД 11 поля starttime максимальный срок действия билета согласно действующей полити ки Kerberos. Затем он сравнивает результат со временем, указанным в запросе, и присваивает полю endtime самое раннее из двух значений. Возобновляемые билеты Ключи шифрования со временем устаревают. Чем чаще используется ключ, тем больший объем данных, им зашифрованных, может быть перехвачен, и тем сильнее искушение взломать его испытывает злоумышленник. Большинство ключей, ис пользуемых протоколом Kerberos, являются ключами сеансов. Клиенты применя ют для связи с сервером один и тот же ключ, пока действует билет сеанса. Когда срок действия билета истекает, клиент получает новый билет со свежим ключом сеанса, но до этого момента ключ не меняется. Частая смена ключей Ч один из способов защитить их от потенциальных злоумыш ленников. Для этого специальным образом конфигурируется политика Kerberos, в частности устанавливается относительно короткий максимально возможный срок действия билета. Другая стратегия заключается в разрешении обновления клю чей, то есть ключи сеанса могут периодически изменяться, при этом не надо со здавать новый билет. Если политика Kerberos допускает использование возобнов ляемых билетов, КОС устанавливает во всех выдаваемых билетах сеанса флаг RENEWABLE (возобновляемый) и создает в них две даты окончания срока дей ствия: первая срок действия до очередного обновления, а вторая -- общий срок действия билета. Время окончания действия данного билета содержится в поле endtime. Как и в не возобповляемых билетах, в поле endtime указана сумма значений поля starttime и максимального срока действия билета, установленного политикой Kerberos. Кли ент Ч владелец возобновляемого билета Ч должен предоставить его КОС для об новления до окончания срока действия, указанного в endtime, предъявив вместе с ним новый аутентификатор. Получив запрос на обновление билета сеанса, KDC проверяет второе ограничение срока действия, заданное в поле renew-till. Значение этого поля вычисляется при создании билета, как сумма значений поля starttime и общего срока действия билета, установленного политикой Kerberos. Прежде чем обновить билет, KDC проверяет наступил ли срок, определенный в поле rcnew-l ill. Если нет, билет получает новое значение поля endtime и новый ключ сеанса. Из сказанного выше следует, что администраторы могут настроить политику Ker beros так, чтобы билеты сеансов обновлялись через относительно короткие проме жутки времени, например ежедневно. При обновлении билетов создастся новый ключ, что делает практически бессмысленным использование скомпрометирован ных ключей. В то же время администраторы вправе устанавливать достаточно про должительный общий срок действия билетов (месяц, год и т.д.). В конце этого периода билет сеанса становится недействительным и в дальнейшем не подлежит возобновлению. Окончание срока действия билета Когда срок действия билета заканчивается, текущие операции не прерываются. Билеты сеансов служат только для проверки подлинности новых соединений. Пос ле установки соединения не имеет значения, действителен билет или нет. Вместе с тем, по истечении срока действия TGT клиент Kerberos может прервать сеанс пользователя и запросить пароль. Безопасность в распределенных системах 502 ЧАСТЬ Центр распространения ключей не предупреждает клиентов о приближении окон чания срока действия билетов сеансов или TGT. На самом деле он не регистрирует свой обмен с клиентами за исключением кратковременных записей, необходимых для того, чтобы предотвратить атаки с использованием перехваченных сообщений. Клиент, предъявивший просроченный билет TGT службе TGS центра распростра нения билетов, в ответ получает сообщение об ошибке. Получив просроченный би лет, сетевые серверы также сообщают об ошибке. Вся ответственность за обновле ние или замену билетов возлагается на клиента. Что клиентам известно о билетах Чтобы управлять своим кэшем удостоверений, клиенту необходимо знать часть ин формации, находящейся в билетах сеансов и TGT. Когда KDC в результате AS- или TGT-обмена возвращает билет и ключ сеанса, клиентский ключ упаковывается в структуру данных, которая содержит информацию полей flags, authtime, starttime, endtime и renew-till билета. Вся эта структура шифруется ключом клиента и воз вращается ему в сообщениях-ответах KRB_AS_REP и KRB_TGS_REP. Делегирование проверки подлинности Многоуровневые клиент-серверные приложения представляют собой особый слу чай применения протокола Kerberos. В приложениях такого рода клиент иногда подключается к серверу, который, в свою очередь, должен соединиться с другим сервером. Для этого первый сервер должен иметь билет сеанса со вторым сервером. В идеале этот билет ограничивает доступ промежуточного сервера к ресурсам вто рого сервера в соответствии с полномочиями клиента. В Kerberos эта задача решается с помощью механизма делегирования проверки под линности (delegation of authentication). По существу, клиент перепоручает провер ку подлинности промежуточному серверу-представителю, сообщая КОС, что тот олицетворяет клиента. Делегирование выполняется двумя способами. Во-первых, клиент сам получает билет сеанса с целевым сервером и передает его серверу-представителю. Билеты, которые получает клиент, а использует посредник, называются прокси-билетами (proxy tickets). Применение прокси-билетов осложнено тем, что клиент должен знать имя целевого сервера. Избежать этого позволяет второй способ: клиент мо жет передавать серверу-представителю билет TGT, необходимый последнему при запросе билета сеанса с целевым сервером. Билеты сеансов, полученные посред ством TGT клиента, называются пересылаемыми билетами (forwarded tickets). Спо собность клиентов получать от KDC прокси-билеты или пересылаемые билеты TGT определяется параметрами политики Kerberos в домене. Прокси-билеты При создании TGT для клиента центр распространения ключей руководствуется политикой Kerberos в домене. Если выдача прокси-билетов разрешена, КОС уста навливает в билете TGT флаг PROXIABLE. Чтобы получить прокси-билет, клиент предъявляет TGT службе TGS и запраши вает билет сеанса с целевым сервером. В запросе устанавливается флаг, свидетель ствующий, что запрашивается нрокси-билет, а также указывается имя сервера, ко торый будет представлять клиента. Получив такой запрос, КОС создает билет се анса с целевым сервером, устанавливает в нем флаг PROXY и направляет билет Проверка подлинности ГЛАВА 11 клиенту. Клиент в свою очередь пересылает этот билет серверу-представителю, ко торый может воспользоваться им для получения доступа к целевому серверу. Пересылаемые билеты Клиент, которому требуется делегировать определенному серверу право получения билетов сеансов с другим сервером, должен запросить у центра распространения ключей пересылаемый TGT. Для этого клиент при помощи AS-обмена передает в KDC имя сервера, который будет действовать от лица клиента. Если передача би летов разрешена политикой Kerbcros, KDC создает билет TGT для сервера-пред ставителя, которым тот будет пользоваться от имени клиента, устанавливает в этом TGT флаг FORWARDABLE и направляет его клиенту. Затем клиент передает этот TGT серверу-представителю. Сервер-представитель, запрашивая билет сеанса с промежуточным сервером, предъявляет центру распространения ключей TGT клиента. КОС, обнаружив флаг FORWARDABLE в предъявленном TGT, создаст билет сеанса с запрашиваемым сервером, устанавливает в нем флаг FORWARDED и возвращает внешнему серве ру. Возможность установки флага FORWARDED в билете сеанса обеспечивает до полнительный уровень безопасности, позволяя администраторам конфигурировать отдельные серверы так, чтобы те отвергали пересылаемые билеты сеансов. Компоненты Kerberos в Windows В Windows 2000 центр распространения ключей реализован как служба домена. При этом KDC использует Active Directory в качестве базы данных учетных запи сей и получает дополнительную информацию об участниках безопасности из гло бального каталога. Как и в других реализациях протокола Kerberos, центр распространения ключей представлен двумя службами, выполняющимися в рамках единого процесса. Служба проверки подлинности (Authentication Service) выдает билеты TGT для доступа к службе TGS домена. Прежде чем получить билеты сеансов со службами, сетевым клиентам необходимо обзавестись TGT от службы проверки подлинности в домене, в котором зарегистрирована учетная запись пользователя. Служба TGS выдает билеты для доступа к другим службам или к службе TGS до веренного домена. Клиент, которому требуется получить доступ к службе, обязан предъявить TGT и запросить билет сеанса у службы TGS домена, в котором нахо дится учетная запись запрашиваемой службы. Клиенту, у которого пет билета TGT для службы TGS удаленного домена, надо его получить, пройдя но цепочке пере направлений, начинающейся в службе TGS домена пользователя и заканчивающей ся в службе TGS домена, где расположена учетная запись запрашиваемой службы. KDC, как и Active Directory, выполняется на каждом контроллере домена. Обе службы запускаются автоматически диспетчером локальной безопасности (LSA) контроллера домена и выполняются в пространстве процесса LSA. Ни одну из этих служб нельзя остановить. Доступность этих служб в Windows 2000 обеспечивается наличием в домене нескольких равноправных контроллеров, любой из которых спо собен обрабатывать запросы к службам проверки подлинности и службам TGS, на правленные в KDC домена, В системах Windows 2000 существует стандартизованное в соответствии с RFC 15! О имя участника безопасности krbtgt для центра распространения ключей. Учетная ЧАСТЬ 2 Безопасность в распределенных системах запись KDC создается автоматически вместе с новым доменом Windows 2000. Ее невозможно удалить или переименовать. Учетной записи КОС автоматически при сваивается пароль, который, как и пароли учетных записей доверия доменов, пери одически меняется. Пароль учетной записи КОС используется при создании сек ретного ключа для шифрования и расшифровки билетов TGT, создаваемых цент ром распространения ключей. Пароль учетной записи доверия доменов применяет ся при создании межсферного ключа Kerberos, необходимого для шифрования и расшифровки билетов перенаправления (referral tickets). Все экземпляры доменного КОС используют единую учетную запись участника безопасности krbtgt. Клиенты, обращаясь к KDC домена, включают в свои сообще ния как имя участника безопасности (krbtgt), так доменное имя. Для идентифика ции центра, выпустившего билет, КОС включает эту же информацию в билеты. База данных учетных записей КОС получает информацию об участниках безопасности из базы данных, которой является Active Directory домена. Каждый участник безопасности представлен в Active Directory объектом учетной записи. Криптографический ключ, применяемый в обмене с пользователем, компьютером или службой, хранится как атрибут объек та учетной записи участника безопасности. Серверами Active Directory могут быть только контроллеры домена. Каждый кон троллер домена хранит полную изменяемую копию каталога, поэтому создание учетных записей, изменение паролей и членства в группах разрешается проводить на любом контроллере домена. Изменения любой из реплик автоматически переда ются во все остальные реплики. Вместе с тем в Windows 2000 не реализован про токол репликации Kerberos (Kerberos replication protocol). Вместо него использует ся собственный протокол репликации с несколькими хозяевами, позволяющий реп лицировать хранилище информации Active Directory по безопасному каналу, созда ваемому между партнерами репликации. Физическое хранение данных учетных записей управляется агентом системы ка талогов (directory system agent, DSA) Ч защищенным и интегрированным с LSA процессом на контроллере домена. Клиентам службы каталога не предоставляется прямой доступ к хранилищу данных. Клиент, которому необходим доступ к инфор мации каталога, для подключения к DSA должен воспользоваться одним из под держиваемых интерфейсов службы Active Directory (Active Directory Service Interfaces, ADSI), средствами которого он может проводить поиск, чтение или за пись объектов каталога и их атрибутов, Запросы на доступ к объекту или атрибуту в каталоге подлежат проверке, осуще ствляемой механизмами управления доступом Windows 2000. Подобно файлам и папкам в файловой системе NTFS, объекты Active Directory защищены списками управления доступом (access control list, ACL), в которых указано, кто и как может получить доступ к объекту. В отличие от ACL файлов и папок списки управления доступом объектов Active Directory предоставляют или запрещают доступ не толь ко ко всему объекту, но и к отдельным его атрибутам. Таким образом, атрибуты, несущие секретную информацию об учетных записях, удается защитить более стро гими разрешениями, чем прочие атрибуты объекта учетной записи. Наиболее секретной информацией об учетной записи считается, конечно же, па роль. Несмотря на то, что атрибут пароля объекта лучетная запись содержит не Проверка подлинности ГЛАВА 11 Предварительная проверка подлинности По умолчанию КОС обязывает все учетные записи использовать предварительную проверку подлинности. Это значительно осложняет попытки подобрать пароль. Вместе с тем предварительную проверку подлинности разрешается отключать для отдельных учетных записей, если это необходимо для совместимости с другими реализациями протокола. Чтобы отключить предварительную проверку подлинно сти, щелкните правой кнопкой мыши объект пользователя в оснастке Active Directory Users and Computers (Active Directory - пользователи и компьютеры), в контекстном меню выберите Properties (Свойства), в диалоговом окне Properties (Свойства) перейдите на вкладку Account (Учетная запись) и установите флажок Do not require Kerberos preauthentication (Без предварительной проверки подлин ности Kerberos). Поставщик поддержки безопасности Kerberos Протокол проверки подлинности Kerberos реализован в виде поставщика поддер жки безопасности (security support provider, SSP) Ч динамически подключаемой библиотеки (DLL), поставляемой с операционной системой. В Windows 2000 так же имеется поставщик поддержки безопасности для проверки подлинности по про токолу NTLM. По умолчанию при загрузке системы на компьютере под управле нием Windows 2000 LSA загружает оба протокола (Kerberos и NTLM). В доменах Windows 2000 для проверки подлинности сетевого входа в систему и соединений клиента и сервера можно применять любой из указанных SSP. Выбор SSP зависит от возможностей компьютера-партнера по обмену, но если есть возможность выбо ра, используется Kerberos SSP. Системные службы и приложения транспортного уровня получают доступ к постав щику поддержки безопасности через интерфейс SSPI (Microsoft Security Support Provider Interface). SSPI является интерфейсом Microsoft Win32. Он предоставля ет методы перечисления доступных SSP, выбор одного из них для прохождения проверки подлинности и установление аутентифицированного соединения. Эти методы представляют собой общие процедуры (лчерные ящики), которые разра ботчики применяют, не вникая в детали конкретного протокола. Например, прове ряя подлинность во время соединения клиента и сервера, приложение с клиентской стороны направляет данные серверу через интерфейс SSPI с применением метода IrntializeSecurityContext. В случае Kerberos SSP метод InitializeSecurityContext фор мирует сообщение-запрос клиента KRB_AP_REQ, а сервер использует для ответа метод AcceptSecurityContext интерфейса SSPI, который формирует сообщение-от вет KRB_AP_REP. После завершения проверки соединения LSA сервера применя ет информацию из клиентского билета сеанса для создания маркера доступа. На конец, сервер прикрепляет маркер доступа к потоку, олицетворяющему данную службу, вызывая метод IinpersonateSecurityContext. После того как LSA установит контекст безопасности пользователя, процесс, вы полняющийся в этом контексте, может загрузить еще один экземпляр Kerberos SSP для поддержки подписывания сообщений и шифрования. Для проверки подлинности в доменах Windows 2000 все распределенные службы используют интерфейс SSPI. Таким образом, все службы домена поддержипают Kerberos. Далее перечислены некоторые службы, осуществляющие проверку под линности по протоколу Kerberos: Безопасность в распределенных системах 508 ЧАСТЬ Х службы спулера печати; Х удаленный доступ к файлам посредством CIFS/SMB (Common Internet File System/Server Message Block); Х запросы в Active Directory по протоколу LDAP; Х управление файловой системой DFS и перенаправление; Х межузловая проверка подлинности центров безопасности посредством IPSec (Internet Protocol Security); Х запросы резервирования ресурсов для сетевой службы качества (QoS); Х проверка подлинности в интранетс для IIS; Х удаленное управление серверами и рабочими станциями посредством удаленно го вызова процедур (RPC) с проверкой подлинности; Х запросы сертификатов у службы сертификации для пользователей и компьюте ров домена. Кэш удостоверений Windows 2000 храпит билеты и ключи, полученные от KDC в кэше удостоверений Ч области оперативной памяти, защищенной LSA. Доступ к этому кэшу имеют толь ко процессы, выполняющиеся в контексте безопасности LSA, и он никогда не выг ружается па диск. Все хранящиеся в нем объекты уничтожаются, когда участ ник безопасности выходит из системы или система завершает работу. Кэш удостоверений управляется Kerberos SSP, выполняющимся в контексте безо пасности LSA. Всегда, когда требуется получить или обновить билеты и ключи, LSA для выполнения этой задачи вызывает Kerberos SSP. Кроме того, в кэше удостоверений хранится экземпляр ключа локального пользо вателя, преобразованный из его пароля. Если срок действия ТОТ пользователя ис текает во время сеанса в системе, Kerberos SSP применяет свой экземпляр преоб разованного из пароля ключа, чтобы получить новый TGT, не прерывая сеанса пользователя в системе. Преобразованный из пароля ключ не хранится на компью тере постоянно, его экземпляр разрушается при очистке кэша удостоверений. С преобразованными из пароля ключами служб система обращается по-другому. Они хранятся в безопасной области реестра компьютера, то есть так же, как и в Windows NT. Реестр также содержит преобразованные из пароля ключи учетных записей пользователей в локальной системе, которые применяются исключитель но для получения доступа к компьютерам в автономном режиме. Эти ключи ни когда не используются для сетевого доступа. Обнаружение КОС Прежде чем послать первый запрос проверки подлинности в КОС домена пользо вателя, Kerberos SSP должен найти контролер этого домена. Для этого предназна чен локатор контроллера домена. Подробнее о локаторе Ч в главе 1 Логическая структура Active Directory. Локатор способен обнаруживать только КОС доменов с Active Directory. Если ком пьютеры под управлением Windows 2000 участвуют в других сферах Kerberos, в реестре клиентского компьютера должны быть записаны DNS-имена серверов КОС. SSP протокола Kerberos находит в реестре DNS-имя сферы Kerberos пользователя и, запросив сервер DNS, узнает его IP-адрес. Проверка подлинности ГЛАВА 11 IP-транспорт Согласно RFC 1510, клиент, соединяясь с KDC, должен отправить по IP-адресу центра распределения ключей UDP-дейтаграмму в порт 88. В ответ КОС посылает дейтаграмму на IP-адрес отправителя. UDP (User Datagram Protocol) Ч это транспортный протокол без создания соеди нения, используемый для предваряющего подключение обмена сообщениями, не обходимого для принятия решения о возможности соединения. Этот протокол так же хорошо подходит для приложений, которым необходим разовый обмен типа со общение Ч ответ, как, например, обмен между клиентом и KDC. UDP работает лучше всего, когда дейтаграмма передается, как единое целое, то есть в одном кад ре. Максимально допустимая единица передачи (Maximum Transmission Unit, MTU) для Ethernet-кадров составляет 1500 октетов. Это значит, что если в качестве фи зической сети используется Ethernet, сообщения Kerberos, отправленные в виде UDP-дейатаграмм, могут содержать до 1500 октетов данных. В Windows 2000 информация авторизации зачастую занимает гораздо больше октетов. Но так как эта информация необходима только компьютерам под управ лением Windows 2000, ее исключают из билетов сеансов для компьютеров, работа ющих под управлением других операционных систем. В результате размер этих со общений не превышает ограничений UDP-транспорта, которым они и передаются. Сообщения, несущие билеты сеансов компьютерам под управлением Windows 2000, передаются при помощи протокола TCP, способного передавать большие объемы информации, чем UDP Использование TCP-транспорта в Windows 2000 согласу ется с недавно предложенными поправками к RFC 1510. Данныеавторизации Kerberos является протоколом проверки подлинности, а не авторизации. Он прове ряет, являются ли участники безопасности теми, за кого себя выдают, но не опре деляет объекты, к которым они могут получить доступ, и тип этого доступа. В би летах сеансов имеется поле для данных авторизации, однако протокол Kerberos не устанавливает форму предоставления этих данных и способ их использования сер вером. Она полностью определяется существующим в системе механизмом управ ления доступом. Отличия авторизации на основе имени и на основе идентификатора В некоторых операционных системах приложения применяют собственные меха низмы для определения уровня авторизации пользователей. Зачастую для этого используются частные списки, содержащие имена пользователей, которым разре шен доступ. Например, многие приложения баз данных поддерживают специаль ные таблицы авторизации для управления доступом конкретных пользователей к просмотру или изменению полей записей. Описанный механизм управления дос тупом можно объединить с проверкой подлинности Kerberos, попросту задав, что бы билет сеанса в поле с данными авторизации содержал в какой-либо форме имя участника безопасности, К сожалению, специализированные механизмы авторизации так и остаются специ ализированными. Приложение базы данных не сможет воспрепятствовать не< анк Безопасность в распределенных системах 510 ЧАСТЬ ционированным действиям пользователя, запустившего другое приложение и при меняющего его для изменения файла с данными. В Windows 2000 доступ к ресур сам контролируется самой операционной системой. Приложения могут содержать собственные механизмы авторизации, но в любом случае механизм управления до ступом операционной системы Windows 2000 защищает все файлы и объекты, ко торые разрешается использовать более чем одному процессу. Заголовок каждого защищенного объекта содержит дескриптор безопасности со списком управления доступом (access control list, ACL). ACL поддерживается вла дельцем объекта, который решает, кто из участников безопасности может получать доступ к объекту и каким образом. Операционная система обеспечивает выполне ние указаний владельца, всякий раз проверяя права доступа, когда приложение за прашивает описатель защищенного объекта. Прежде чем возвратить описатель, опе рационная система проверяет ACL объекта, выясняя, есть ли у участника безопас ности, в чьем контексте безопасности исполняется приложение, доступ к запраши ваемому объекту. Если участник безопасности не имеет такого права, приложению в доступе отказывается. Еще одно важное отличие данного механизма управления доступом заключается в том, что ни операционная система, ни ACL не идентифицируют участников инфор мации по имени. Вместо этого каждому участнику информации назначается уни кальный идентификатор безопасности (security identifier, SID) - буквенно-цифро вое выражение, структура которого напоминает телефонный номер. Подобно на чальным цифрам международного телефонного номера, обозначающим код страны, первая часть SID обозначает домен, в котором он был создан, а вторая часть, ука зывающая на учетную запись в этом домене, аналогична местному номеру. Домен ная часть SID уникальна в пределах предприятия, а значение второй части учет ной записи Ч уникально в домене. В отличие от номеров телефонов SID никогда не применяется повторно. Пользователю нельзя присвоить SID, который уже ког да-то принадлежал другому пользователю. Третья отличительная особенность описываемого метода управления доступом авторизация каждого из пользователей определяется не только индивидуально, но и обусловливается его членством в одной или нескольких группах безопасности. Предпочтительнее предоставить доступ группам, а не индивидуальным пользова телям, при этом уровень полномочий группы подстраивается под нужды ее членов. Этот метод упрощает своевременное обновление ACL в сетях, где пользователи ис числяются тысячами, а объекты - миллионами. Членством в группах разрешается управлять централизованно, администраторы могут менять уровень полномочий отдельных пользователей, включая или исключая их из групп. Кроме того, администрирование облегчается имеющейся в Windows 2000 функци ей вложения групп. Созданную в одном домене группу можно добавить к группе, созданной в другом домене или к универсальной группе всего дерева доверенных доменов. В результате уровень авторизации сотрудников, меняющих место работы внутри предприятия, удается легко изменить не прибегая к корректировке отдель ных объектов ACL. Как и отдельные участники безопасности, группы в Windows 2000 тоже имеют свои идентификаторы безопасности. Таким образом, уровень авторизации пользователя определяется списком идентификаторов безопасности, который включает в себя его собственный SID и S1D всех групп безопасности, в которые он входит. ГЛАВА 11 Проверка подлинности Подробнее о том, как операционная система определяет уровень авторизации пользователя, Ч в главе 12 Управление доступом. Подготовка данных авторизации средствами КОС Когда для проверки подлинности используется протокол Kerberos, список SID, идентифицирующих участника безопасности и группы, в которые тот входит, пере дается на локальный компьютер в поле данных авторизации билета сеанса. Сбор данных авторизации выполняется в два этапа: когда КОС домена Windows создает билет TGT и при создании билета сеанса с сервером в домене. Когда пользователь запрашивает TGT, центр распространения ключей его домена обращается к Active Directory. В учетной записи пользователя имеется атрибут с его SID. а также атрибуты с SID каждой группы безопасности домена, членом ко торой этот пользователь является. Возвращаемый в ответ на запрос КОС список STD помещается в поле данных авторизации билета TGT. В многодоменном окру жении КОС также запрашивает в глобальном каталоге универсальные группы, включающие самого пользователя или одну из его доменных групп безопасности, Если таковые обнаруживаются, SID этих групп также добавляются к списку в поле данных авторизации билета TGT. Когда пользователь запрашивает билет сеанса с сервером, KDC серверного домена копирует содержание поля данных авторизации TGT в соответствующее поле би лета сеанса. Если домен сервера отличается от домена пользователя, КОС запра шивает у Active Directory группы безопасности локального домена, включающие самого пользователя или одну из групп безопасности, в которую тот входит. Если такие группы существуют, их SID добавляются к списку в поле данных авториза ции билета сеанса. Использование службами данных авторизации В Windows 2000 службы действуют в собственном контексте безопасности, только если они пытаются получить доступ к ресурсам от своего имени. Обычно это про исходит, когда они обслуживают сами себя -- считывают или записывают инфор мацию реестра, осуществляют привязку к коммуникационным портам, а также лю бые другие действия, не связанные с обработкой клиентских запросов. Служба, выполняющая какие-либо действия для клиента, представляет этого клиента и дей ствует в его контексте безопасности. Это означает, что кроме верификации клиен та, службам Windows 2000 приходится учитывать некоторые его характеристики, а именно его уровень авторизации в системе. Когда служба обслуживает сама себя на компьютере под управлением Win dows 2000, она вызывает метод AcquireCredentialsIIandle интерфейса SSPI, чтобы получить доступ к своим реквизитам (секретному ключу учетной записи, под кото рой данная служба выполняется). Затем она подключается к коммуникационному порту и ожидает сообщений от предполагаемых клиентов. Получив клиентский запрос на соединение и билет сеанса, служба просит Kerbcros SSP проверить предъявленные им удостоверения, вызывая метод Accept Security Context интерфейса SSPI и передавая в аргументе билет сеанса клиента вместе с описате лем секретного ключа службы. SSP проверяет аутентичность этого билета, откры вает его и передает LSA содержание поля данных авторизации. Если в этих данных содержатся списки SID, LSA использует их для создания маркера доступа, пред Безопасность в распределенных системах 512 ЧАСТЬ ставляющего пользователя в локальной системе. Кроме того, LSA запрашивает соб ственную базу данных, чтобы выяснить, не является ли пользователь или одна из его групп членом группы безопасности локальной системы. Если такие группы су ществуют, LSA добавляет их идентификаторы безопасности в маркер доступа. Затем LSA подтверждает вызывающей службе, что клиент идентифицирован, и при лагает ссылку на клиентский маркер доступа. Получив подтверждение, служба закрывает соединение с клиентом и, вызвав ме тод ImpersonateSecurityContext, присоединяет маркер доступа клиента к олицетво ряющему его потоку. Запрашивая доступ к объекту, этот поток предъявляет маркер клиента. Операционная система проверяет права доступа, сравнивая SID, заклю ченные в маркере клиента, и SID в ACL объекта. Обнаружив одинаковые иденти фикаторы безопасности, операционная система проверяет ACL, предоставлен ли этому SID уровень доступа, запрошенный потоком. Если авторизованный уровень доступа соответствует запрошенному, потоку разрешается доступ к объекту. В про тивном случае доступ не предоставляется, Подписывание данных авторизации Билеты сеанса шифруются секретным ключом учетной записи, под которой запус кается служба. Получая доступ к описателю своих удостоверений, служба получа ет доступ и к этому ключу. Вероятна ситуация, когда недобросовестный пользова тель, обладающий подлинной сетевой учетной записью, но с ограниченными пра вами на локальном компьютере установит да нем свою службу. Далее этот пользо ватель может запросить билет сеанса со своей службой. Служба, расшифровывав билет, изменит данные авторизации, добавив S1D привилегированной группы, за ново зашифрует измененный билет и, вызвав метод AcceptSecurityContext, предъя вит его LSA. В результате уровень полномочий пользователя на компьютере, на котором выполняется служба, повысится. Для предотвращения такой ситуации КОС подписывает данные авторизации пе ред внесением их в билет сеанса. При изменении данных подпись теряет силу. LSA на компьютере под управлением Windows 2000 всегда проверяет подпись данных авторизации в билетах сеанса, которые предъявляют в вызовах AcceptSecurity Context службы, не относящиеся к доверенным, то есть не выполняющиеся под учетной записью локальной системы. Эта учетная запись применяется службами, которые устанавливаются вместе с операционной системой, как, например, основ ная служба сервера. Другие службы тоже способны выполняться под учетной за писью локальной системы, однако разрешить это могут только члены группы Administrators (Администраторы). Предполагается, что установивший службу ад министратор гарантирует ее безопасность. Если билет сеанса предъявляет приложение, не выполняющееся в контексте ло кальной системы, LSA запрашивает у KDC подтверждение подписи данных авто ризации билета. Обмен происходит по механизму удаленного вызова процедур по безопасному каналу, открытому службой Net Logon (Сетевой вход в систему) меж ду компьютером и контроллером домена. Запросы на подтверждение подписи не выходят за границы домена, так как билеты сеансов всегда выдаются, и следова тельно, содержащиеся в них данные авторизации всегда подписываются КОС до мена, в котором находится запрашиваемый компьютер, Проверка подлинности ГЛАВА 11 Интерактивный вход в систему Пользователям свойственно полагать, что вход в систему под учетной записью до мена Windows 2000 предоставляет им доступ в сеть, что, конечно же, Ч полнейшее заблуждение. В действительности, если сетевая проверка подлинности выполняется по протоколу Kerberos, входящий в систему пользователь получает доступ только к службе проверки подлинности, точнее, ему предоставляется билет TGT, который он может предъявлять, запрашивая билеты сеансов с другими службами домена. Для входа в систему под доменной учетной записью с компьютера под управлени ем Windows 2000 всегда нужен по крайней мере один билет сеанса билет для ком пьютера, с которого этот вход осуществляется. Этому есть весьма простое объясне ние: нельзя работать на компьютере под управлением Windows 2000, не используя хотя бы некоторых из его системных служб. Пользователь системной службы ста новится ее клиентом, подлинность которого должна быть проверена, а для такой проверки требуется билет сеанса. Системные службы компьютера под управлени ем Windows 2000 выполняются под учетной записью локальной системы, а при при соединении компьютера к домену Ч под учетной записью компьютера в домене. Пользователи домена получают доступ к службам, выполняющимся в контексте ло кальной системы, предъявляя билет сеанса для компьютера, на котором эти служ бы выполняются, и для интерактивно входящих в систему пользователей исключе ния не делаются. Для получения доступа к службам компьютера пользователям также приходится предъявить билет сеанса. Процедура входа в систему Вход пользователя с учетной записью в домене Windows 2000 в систему с клавиа туры компьютера под управлением Windows 2000 выполняется в три этапа. 1. Пользователь запрашивает доступ к службе TGS домена. Запрос осуществляется при помощи AS-обмена между Kerberos SSP компьюте ра и КОС домена учетной записи пользователя. В ответ пользователь получает билет TGT, который понадобится при последующем обмене с этим КОС. 2. Пользователь запрашивает билет для компьютера. Запрос выполняется при помощи TGS-обмена между Kerberos SSP компьютера и КОС домена учетной записи компьютера. В ответ пользователь получает би лет сеанса, который понадобится для последующих запросов к системным служ бам компьютера. 3. Пользователь запрашивает доступ к службам локальной системы компьютера, При этом Kerberos SSP компьютера предъявляет билет сеанса LSA компьютера. Если учетные записи компьютера и пользователя находятся в разных доменах, не обходимо выполнить дополнительные процедуры. Прежде чем запросить билет се анса с компьютером, поставщик Kerberos SSP должен получить от КОС домена пользователя билет TGT для службы распространения ключей домена компьюте ра. Поставщик поддержки безопасности может получить билет сеанса с компьюте ром, предъявив TGT центру распространения ключей домена компьютера. Процесс входа в систему зависит от настройки и конфигурации компьютера. При обычной конфигурации Windows 2000 интерактивные пользователи входят в сис тему с помощью пароля. Специальная конфигурация Windows 2000 позволяет Безопасность в распределенных системах 514 ЧАСТЬ пользователям входить в систему по смарт-карте. Несмотря на сходство основных процедуры, эти способы входа в систему немного различаются. Вход в систему с помощью пароля Предположим, что учетные записи Алисы и компьютера Workstation, которым она обычно пользуется, хранятся в домене West. Чтобы войти в систему, Алиса нажи мает CTRL+ALT+DEL. Эта комбинация клавиш называется последовательностью безопасного обращения к системе (Secure Attention Sequence, SAS), или SAS-после довательностыо, для компьютеров с обычной конфигурацией Windows 2000. В ответ служба Winlogon переключает рабочий стол в режим входа в систему и вызывает GINA (Graphical Identification and Authentication) динамически под ключаемую библиотеку поддержки графического интерфейса идентификации и проверки подлинности. GINA загружается в процесс службы Winlogon и отвечает за получение от пользователя информации для входа в систему, упаковку ее в спе циальную структуру данных и пересылку в LSA для проверки. Существуют, конеч но же, версии США, созданные сторонними разработчиками, однако мы рассмот рим только загрузку службой стандартного компонента (MSGINA.dll) операцион ной системы Windows 2000. MSGINA отображает стандартное диалоговое окно вхо да в систему. Алиса вводит свое имя пользователя и пароль и выбирает West в списке имен до менов. Когда она щелкает кнопку ОК, диалоговое окно закрывается и MSGINA передает введенную информацию службе Winlogon. Winlogon направляет эту ин формацию на подтверждение в LSA, вызывая метод LsaLogonUser. Получив структуру данных, содержащую входную информацию Алисы, LSA неза медлительно при помощи односторонней хэш-функции преобразует пароль в сек ретный ключ. LSA сохраняет преобразованный пароль в кэше удостоверений, от куда его извлекают для шифрования или расшифровки. Чтобы подтвердить входную информацию Алисы и создать для нее сеанс в системе на компьютере, LSA должен получить: Х действительный билет TGT для доступа к службе TGS; Х действительный билет сеанса для доступа к компьютеру. LSA получает эти билеты при помощи Kerheros SSP, который обменивается сооб щениями непосредственно с KDC домена, как это показано на рис. 11-8. Центр распределения ! ключей (KDC) I Х Служба проверки Билет TGT для домена LSA прдл_и_нн_о_сти [ASJ Служба TGS S Билет для компьютера S р Рис. 11-8. Обмен по протоколу Kerberos при интерактивном входе в систему Ниже приведены содержание и последовательность сообщений. Проверка подлинности ГЛАВА 1. LSA направляет службе проверки подлинности КОС домена West сообщение запрос KRB_AS_REQ, в котором содержатся: Х основное имя пользователя (Алиса); Х имя домена, в котором хранится учетная запись (West); Х информация предварительной проверки подлинности, зашифрованная сек ретным ключом, полученным из пароля Алисы. 2. Служба проверки подлинности КОС возвращает сообщение-ответ KRB_AS_REP, в котором содержатся: Х общий ключ сеанса для Алисы и КОС, зашифрованный секретным ключом, полученным из пароля Алисы; Х билет TGT для центра распространения ключей домена West, зашифрован ный секретным ключом КОС. В билете TGT находятся общий ключ сеанса для КОС и Алисы и данные авторизации Алисы. Данные авторизации состоят из SIO учетной записи Алисы, SID групп безопас ности домена West, членом которых является Алиса, а также SID универсаль ных групп предприятия, в которые входит Алиса или одна из ее доменных групп. 3. LSA направляет службе TGS центра распространения билетов домена West со общение-запрос KRB_TGS_REQ, в котором содержатся: Х имя компьютера (Workstation); Х имя домена, к которому относится компьютер (West); Х билет TGT Алисы; Х аутентификатор, зашифрованный общим ключом сеанса Алисы и KDC. 4. КОС направляет сообщение-ответ KRB_TGS_REP, в котором содержатся: Х общий ключ сеанса для Алисы и Workstation, зашифрованный общим клю чом сеанса Алисы и КОС; Х билет сеанса с Workstation для Алисы, зашифрованный общим секретным ключом Workstation и КОС. Билет сеанса содержит общий ключ сеанса Workstation и Алисы, а также дан ные авторизации из билета TGT Алисы. Книги, научные публикации