Книги, научные публикации Pages: | 1 | ... | 7 | 8 | 9 | 10 | 11 | ... | 15 |

Distributed Systems Guide Microsoft 2000 Server Microsoft Press Распределенные системы Книга 1 2000 Server Москва 2001 Я fl I (I Г К I P УДК 004 ББК 32.973.26-018,2 М59 Microsoft ...

-- [ Страница 9 ] --

08/16 16:23:23 [INFO] Setting security on the domain controller and Directory files and registry keys 08/16 16:23:27 [INFO] Securing 08/16 16:23:27 [INFO] Securing 16:23:27 [INFO] Securing storage system provider 08/16 16:23:27 [INFO] Securing 08/16 16:23:28 [INFO] Securing 08/16 16:23:49 [INFO] Securing processor 08/16 16:23:49 [INFO] Securing 08/16 16:23:49 [INFO] Securing signing 08/16 16:23:49 [INFO] Securing 08/16 16:23:49 [INFO] 08/16 16:23:49 [INFO] Securing signing 08/16 16:23:49 [INFO] Securing 08/16 16:23:49 [INFO] Securing 08/16 16:23:49 [INFO] Securing storage system 08/16 16:23:49 Securing 08/16 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing policy 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 454 ЧАСТЬ 1 Служба Active Directory 08/16 Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing drivers 08/16 16:23:50 [INFO] r 08/16 16:23:50 [INFO] Securing file execution options 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 [INFO] 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing zones OB/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] Securing 08/16 16:23:50 [INFO] :

08/16 16:24:31 [INFO] 08/16 16:24:31 [INFO] Securing 08/16 16:24:31 Securing 08/16 16:24:31 [INFO] Securing [INFO] Securing 08/16 16:24:40 Securing 08/16 16:24:40 [INFO] Securing 08/16 16:24:40 [INFO] Securing 08/16 16:24:41 [INFO] Securing 08/16 16:24:41 [INFO] Securing 08/16 16:24:41 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 08/16 16:24:51 [INFO] Securing 16:24:51 [INFO] Securing 08/16 16:24:52 [INFO] Securing 16:24:52 [INFO] Securing 08/16 16:24:52 [INFO] Securing LanNanServer ГЛАВА 10 и устранение неполадок, а также Active Directory 08/16 16:24:57 [INFO] to 2 08/16 16:24:57 [INFO] The attempted domain controller operation has completed Сведения об (или завершении работы мастера Active Directory:

08/16 16:24:58 [INFO] returned Подробнее об и удалении Active Directory - главе 2 Хранение дан ных в Active Подробнее об объектах перекрестных ссылок - в главе Разрешение в Active Неполадки данных Если контроллер домена не в завершить работу (обычно за сбоя в питании), база так как самые свежие стра ницы из памяти не записываются на диск. Для базы данных ис пользуются журналы транзакций. Любое изменение в базе данных также фиксиру ется в этом журнале, дисковый образ которого немедленно обновляется при изме нении журнала. в следующей последовательности:

1. записывает изменение в базы данных в буфере памяти;

2. Lsass.exe записывает изменение в журнал;

3. Lsass.exe ожидает журнала на диск;

4. после сброса Lsass.exe подтверждает и фиксирует Если при останове Active Directory база данных не была сохранена на при запуске выполняется По существу, база дан ных приводится в непротиворечивое и обновленное состояние считы записей журналов но порядку и повторного внесения обновлений.

Имя журнала по Ч Edb.log. (Extensible Storage Engine), ядро базы данных, может создавать новые журналы после заполнения текущего (non-circular) метод ведения журнала] или перезаписывать самый старый файл, когда число файлов журнала превышает определенное значение метод ведения |. В первом случае объем журнала непрерывно растет, администратор вручную не удалит старые файлы журнала после или перезапуска. Некруговой метод позволяет сохранять все базы при этом журналы никогда автоматически не удаляются.

По умолчанию в Windows 2000 применяется круговое ведение журналов, Папка обычно содержит файлы:

Х Х Х Х Res2.log.

Объем каждого из файлов с равен точно 10 Мб. Edb.log - эта текущий журнал. Когда круговой метод отключен, после заполнения файла Edb.log он в Edb00001.log и создается новый с Edb.log. В дальнейшем файлы нумеруются числами в системе Таким образом состояние журналов можно определить, проверив наличие всех по следовательно пронумерованных файлов.

456 ЧАСТЬ 1 Служба каталогов Active Directory Файлы Resl.bg и Res2.log - это (placeholders), предназначенные для (в рассматриваемом случае) последних 20 Мб дискового про странства на данном диске или в каталоге. Они журналам резерв ное пространство для корректного завершения в случае дискового про странства. Обратите что при круговом методе ведения журналов вопрос о нехватке дискового пространства вообще не возникает.

Файл контрольной точки, создается базой данных Jet. Он сохраняет конт рольную точку базы данных, позволяя при необходимости воспроизвести операции, начиная с контрольной точки. Файл Edb.chk Ч это указатель последовательности записей, поддерживающий сведения о соответствии информации в памяти и в фай ле базы данных на диске. В случае сбоя он указывает на точку в журнале, с кото рой следует начать восстановление. Файл Edb.chk чрезвычайно важен для быстро го восстановления: если его нет, база данных должна начинать восстановление с начала самого старого журнала на диске и просмотреть все страницы во всех жур налах, определяя, какие изменения уже внесены в базу данных. Конечно же, этот занимает много особенно если единственная цель - обеспечить непротиворечивость базы данных.

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

Этот файл также обновляется в конце процесса восстановления, а также ус пешном завершении работы и закрытии базы данных.

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

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

ГЛАВА 10 Выявление и устранение неполадок, также восстановление Active Directory Команда integrity также проверяет корректность существуюпщх заголовков в базе данных, а также доступность и таблиц. Короче говоря, она проверяет целостность файлов службы каталогов. Такая проверка прово дится в режиме Directory Service Restore (Восстановление службы каталогов).

Ошибки регистрируются в журналах.

Время работы команды integrity зависит от и разме ра данных каталога. (Для баз данных скорость 2 Гб в час считалась удовлетворительной.) При выполнении этой команды программа отображает про выполнения и процент обработанных данных.

Выполнение служебной программы и ко манды integrity должны осуществляться в режиме Directory Services Restore (Вос становление службы каталогов).

Вот пример протокола проверки целостности Ntdsutil вво димые с клавиатуры, выделены курсивом):

file maintenance: Integrity Opening database.

Executing Command: /g 10240 /8 /v /x /o Initiating INTEGRITY Database:

Temp. Database:

failed to get 515126 buffers checking database header checking database integrity Scanning Status ( X complete ) 10 20 30 40 50 60 70 80 90 I--I checking SystemRoot (OE) SystemRoot (AE) checking system table Name RootObjects rebuilding and comparing indexes checking table (6) checking data checking long value tree (24) checking index checking index (122) checking index (121) checking index (120) checking index (119) checking index (118) checking index (117) checking index (116) checking index (115) checking index (114) 45В ЧАСТЬ 1 Служба Active Directory index (113) checking index (112) "INDEX checking index (111) checking index checking index (109) checking index (108) (107) index checking index (106) checking index (105) checking Index checking index (103) checking index (102) checking index (101) checking index (100) checking index (99) checking index (98) (97) checking index checking index (96) checking index (95) checking index (94) checking index (93) checking index (92) checking index (91) checking index (90) checking index (89) checking index "INDEX (88) checking index (85) checking index (84) checking (83) checking index (80) checking index (77) checking index INDEX (76) checking index (75) checking index (74) checking index (73) checking index (72) checking index (71) checking index (69) checking index (66) checking index (65) checking index (62) checking index (60) checking index (58) checking index (56) checking index (55) checking index (52) checking index (51) checking index (50) checking index (49) checking index (48) index (47) checking index (42) index (39) checking index (36) checking index (32) checking index (25) ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory checking index (13) checking index checking index (11) checking index checking index checking index (8) checking index (7) rebuilding and indexes checking table (16) checking data rebuilding and comparing indexes checking table (14) checking data checking (15) rebuilding and comparing indexes checking table (123) data checking index (124) rebuilding and comparing indexes checking table (17) checking data checking index (19) checking index (18) rebuilding and comparing indexes integrity check completed.

Operation completed successfully in 13.640 seconds.

Spawned Process Exit code 0x0(0) If integrity was successful, it is recommended you semantic database analysis to insure semantic database consistency as well.

Обнаружение местоположения файлов базы данных и журналов Чтобы файлы данных, журнал и каталог, можно воспользоваться командой info, в состав служебной программы строки Эта команда:

Х анализирует и информирует о свободном пространстве на всех дисках, установ ленных на компьютере;

Х считывает информирующих о местоположении Active Directory, и отображает эти сведения;

Х сообщает о размерах файла данных, рабочего и журнала;

Х вот стандартный протокол работы команды info вводимые с клавиа курсивом):

file maintenance:

Drive Information:

C:\ NTFS (Fixed Drive ) Gb) Gb) DS Path Information:

Database :

- 12.1 Mb Backup dir :

Working dir :

460 ЧАСТЬ 1 Служба каталогов Active Directory Log - 40.0 total - 10.0 Mb - 0.0 Kb edb00001.log - 10, - 10.0 Mb Перемещение базы Для перемещения базы данных с места диска в другое используется служеб ная программа командной строки Ntdsutil в режиме Directory Services Restore (Вос становление службы каталогов). Например, перемещение журнала или файла Ntds.dit на другой диск необходимо при возникновении неполадок на выделенном ранее диске или каталоге. В частности, команда move db to перемещает файл данных Ntds.dit в новый каталог, в параметре и обновляет параметры реест ра, переопределяя стандартное положение этого файла, используемое службой ка талогов.

Порядок перемещения базы данных Active Directory 1. Заархивируйте Active Directory. Механизм архивирования в Windows 2000 под держивает архивирование Active Directory в подключенном состоянии. Это про исходит автоматически выборе варианта архивирования всех данных на компьютере или только данных состояния системы в Backup Wizard (Мастер архивации и восстановления Windows 2000).

2. Перезапустите контроллер домена и в меню загрузки нажмите F8, чтобы перей ти в меню Windows 2000 Advanced Options Menu (Меню дополнительных ва риантов загрузки Windows 2000).

3. Выберите Directory Services Restore Mode (Восстановление службы каталогов) и нажмите Enter. Чтобы запустить процесс загрузки, снова нажмите Enter.

4. Войдите в систему под учетной Administrator (Администратор), исполь зуя заданный для локальной учетной записи Administrator в автоном ном SAM.

5. В меню Start (Пуск) последовательно выберите Programs (Программы), Acces sories (Стандартные) и затем щелкните Command Prompt (Командная строка).

6. В окне командной строки введите и нажмите Enter.

7. Введите files и нажмите Enter.

8. Введите info и нажмите Enter. Программа предоставит текущие сведения о пути и размере базы данных Active Directory и ее журналов. Запомните этот путь.

9. Выберите диск, где дискового пространства достаточно, чтобы разместить фай лы базы данных.

10. Введите следующую командную строку и нажмите Enter:

move DB to где и Ч путь к месту, выбранному в предыдущем пункте.

Примечание следует определить путь к каталогу. Если он содержит про белы, его следует заключать в кавычки (например, move DB to Папка").

База данных Ntds.dit будет перемещена в указанное место, ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory Введите quit и нажмите Enter. Выполните quit повторно, чтобы возвра титься в командную строку.

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

12. компьютер в обычном режиме.

Таким же образом можно перемещать журналы. Команда Move logs to где %s - новое местоположение, перемещает файлы журналов и обновляет реестр, чтобы при следующем запуске служба каталогов искала их в новом месте.

в автономном режиме Active Directory автоматически выполняет базы данных в подклю ченном состоянии с определенной периодичностью (по умолчанию Ч каждые сов). Эта операция выполняется процессом сбора в ключенном состоянии не уменьшает размер файла базы данных (Ntds.dit), а только оптимизирует хранение информации в базе данных и освобождает пространство для новых объектов. Автономная сжимает файл базы данных. Степень сжатия зависит от уровня исходного файла базы данных.

Дефрагментация базы данных Active Directory в автономном режиме 1. Active Directory. Механизм архивирования в Windows 2000 под держивает архивирование Directory в подключенном состоянии. Это про исходит автоматически при выборе варианта архивирования всех данных на ком пьютере или только состояния системы в Backup Wizard (Мастер архивации и восстановления Windows 2000).

4. Войдите в систему под учетной Administrator (Администратор), исполь зуя пароль, заданный для локальной учетной записи Administrator в автоном ном SAM.

5. В меню Start (Пуск) последовательно выберите Programs (Программы), Ac cessories (Стандартные) и затем Command Prompt (Командная строка).

6. В окне командной строки введите ntdsutil и нажмите Enter.

7. Введите files и нажмите Enter.

8. Введите info и нажмите Enter. Программа предоставит текущие сведения о пути и размере базы Active Directory и ее журналов. этот путь.

9. Выберите диск, где достаточно места, чтобы разместить файл уплотненной данных.

10. Введите следующую командную строку и нажмите Enter:

to где и Ч путь к месту, выбранному в предыдущем пункте.

462 ЧАСТЬ 1 Active Directory Примечание Обязательно следует определить путь к каталогу. Если путь содер жит пробелы, его следует заключать в кавычки (например, move DB to вая Папка").

Новая база данных по имени Ntds.dit будет создана в указанном месте.

11. Введите quit и нажмите Enter. Выполните команду quit чтобы возвра титься в командную строку.

12. старый Ntds.dit файл базы данных Active Directory, путь к которому Вы запомнили (пункт 8), новым файлом Ntds.dit.

13. Перезапустите компьютер в обычном режиме.

Мягкое восстановление журналов В случае сбоя питания стоит выполнить восстановление По скольку данные транзакций вносятся в журналы до записи в файлы данных, Вы можете повторно выполнить зарегистрированные в журналах, и внести необходимые изменения данных. Команда Recover служебной программы команд ной строки Ntdsut.il вызывает другую служебную программу Esentutl для выполне ния такого мягкого восстановления. все журналы и проверя ется внесение всех зафиксированных в файл данных.

Примечание Мягкое выполняется автоматически при загрузке DSA (Directory System Agent Ч агент системы каталогов), если работа завершена некорректно.

Вот типовой пример протокола выполнения команды Recover (курсивом выделены команды, вводимые с maintenance:

Executing Command: /г /8 /о Initiating RECOVERY Log files:

System files:

Performing soft Operation completed in 4.717 seconds.

Spawned Process Exit code If recovery was successful, it is recommended you run semantic database analysis to insure semantic database consistency as well.

базы данных Корректировка (repair) базы данных требуется после сбоя питания. Исполь зуйте для этого служебную программу командной строки Ntdsutil. Команда repair вызывает служебную программу Esentutl, выполняющую низкоуровневое (на дво ичном уровне) файла базы данных, то есть информации, с которой работает ESENT.

ГЛАВА Выявление и устранение неполадок, а также восстановление Active Directory Внимание! Следует соблюдать осторожность при использовании команды так как ее может привести к случайной потере данных. Это происхо дит, если в базе имеется информация, необходимая для безопасной работы Active Directory, но неизвестная ядру ESE. Заранее точно сказать, какие дан ные могут быть утрачены.

Целостность базы данных Поскольку Active Directory реализована на основе ядра базы ESE, или, как его обычно называют, Jet, журналы используются для поддержки се мантики отката, что позволяет обеспечить транзакций.

Служебная программа содержит процедуру семантики, мую командой Semantic database analysis. Задача этой процедуры Ч целостности содержимого базы данных Active Directory.

Данная служебная программа выполняется в режиме Directory службы каталогов) и регистрирует ошибки в журналах Информация о ходе отображается на индикаторе хода работы.

При проверке следующие операции:

Х числа ссылок. Пересчитываются все ссылки в таблицах данных и ссылок, и полученное число сверяется с хранящим ся числом ссылок. (Подробнее о таблицах данных и ссылок в главе 2 Хране данных в Active Также проверяется наличие у каждого объекта составного имени и счетчика ссылок. Для удаленных объектов проверяется наличие времени и даты удаления и отсутствие или составного имени;

Х проверка удаленных объектов. у таких объектов вре мени и даты удаления и относительного составного Х проверка наследования. Выясняется соответствие тэга составного имени (Dis tinguished Name Tag, DNT) списку наследования родителя и текущего DNT;

Х проверка дескриптора безопасности, то есть действительность дескриптора и наличие информации доступом, а также наличие непустой избира таблицы (discretionary access control list, Программа информирует об обнаружении удаленных объектов без Х проверка репликации. Проверяется вектор обновления данных в заголовке раздела каталога и соответствие числа Также наличие вектора метаданных свойств у объектов. Для объекта опре класса проверяются метаданные, векторы ссылки и частичные атрибуты.

Выполнение проверки семантики базы данных 1. Заархивируйте Directory. Механизм архивирования в Windows 2000 под держивает архивирование Directory в подключенном состоянии. Это исходит автоматически при выборе варианта всех данных на пьютере или только состояния системы в Backup Wizard (Мастер и восстановления Windows 2000).

464 ЧАСТЬ 1 Служба каталогов Active Directory 2. Перезапустите контроллер домена и в меню загрузки нажмите F8, чтобы перей ти в меню Windows 2000 Advanced Options Menu (Меню дополнительных ва риантов загрузки Windows 2000).

4. Войдите в систему учетной записью Administrator (Администратор), исполь зуя пароль, заданный для учетной записи Administrator в автоном ном SAM.

5. В меню Start (Пуск) последовательно выберите Programs (Программы), Ac cessories (Стандартные) и затем щелкните Command Prompt (Командная строка).

6. В окне командной строки введите ntdsutil и нажмите Enter.

7. Введите Semantic database analysis и нажмите Enter.

8. Введите Verbose on и нажмите Enter.

9. Введите go и нажмите Enter. Эта команда запускает проверку семантики без исправления ошибок.

Примечание Для выполнения проверки семантики с исправлением ошибок при меняется команда Go Fixup.

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

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

ntdsutil: Semantic database analysis checker: Verbose on Verbose semantic checker: Go Opening database, Done.

Getting record records Writing into log file Records scanned: Неполадки схемы Обычно неполадки схемы возникают при ее обновлении. В случае возникновения ошибок при обновлении схемы прежде всего нужно изучить файл Schupgr.log расположенный в папке Далее перечислены наиболее неполадки, возникающие в процессе обнов ления схемы.

Х Недостаточно прав. Обычно файлы сценариев формата LDIF содержат инфор мацию для обновления как так и раздела конфигурации. По умолчанию только члены группы Schema Admins (Администраторы схемы) обладают пра вом изменять объекты в разделе схемы, а изменять объекты в разделе ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory рации могут только члены Enterprise (Администраторы предпри ятия) или администраторы корневого домена.

должен войти в систему под учетной записью, обладающей пра вами обеих групп Ч Schema Admins и Enterprise Admins, так как выполняется в контексте безопасности пользователя. Иногда при вы полнении этого условия система все равно информирует о недостаточности Обычно это происходит при недоступности глобального так как обеспечивает определение членства в группах администраторов схемы или пред приятия. В отсутствие каталога сведения о членстве не попадают в маркер доступа пользователя. Обеспечьте доступность глобального каталога, после чего выйдите и повторно войдите в систему.

Вот пример сообщения о недостаточности прав:

Opened Connection to succeeded Found Naming Context Found Naming Context Found Naming Context Current Schema Version is Upgrading schema to version Converting ONs in file Failed to current owner: 50 (Insufficient Rights) Ошибка импорта, ldifde.exe создает файлы ldif.log и (последний Ч толь ко в случае неполадок). Изучите их и найдите записи, вызвавшие ошибки. Да лее попытайтесь импортировать данные вручную средствами служебной про граммы или из отдельного LDIF-файла, содержащего только эти записи. За тем запишите след анализатора пакетов программы Event Viewer со бытий) и воспользуйтесь им для определения причины неполадки.

Schupgr выполняется, но не обновляет версию схемы. Номер версии обновля ется последней записью LDIF-файла. Это значение не обновится при возникно вении ошибки на любой из предыдущих записей. Если в файле нет никаких сообщений об ошибках, а версии все равно не обновляется, это обычно свидетельствует о неполадках в программе Проверьте кор ректность ее работы. Чаще всего сбой LDIFDE нарушением доступа при загрузке программы.

Ошибка Schupgr: Cannot obtain schema version to upgrade to (не удается по лучить номер следующей версии схемы). Причина в отсутствии файла, ко торый копирует на Ваш компьютер при выполнении schupgr для обнов ления сборки. Неполадка устраняется при обновлении путем выполнения про граммы которая блокирует обнаружение несоответствия версий схемы и создаст два-три нужных файла. Далее повторно запустите schupgr.

Запись в журнале schupgr: ERROR: Failed to transfer the schema FSMO role:

52 Это означает, что текущий контроллер домена не является хо зяином схемы, и попытка перемещения этой роли с контроллера домена ла неудачу. Ошибка недоступности (Unavailable) возникает из-за множества ных причин, например из-за недоступности или неготовности нужного контрол лера домена. попытку через некоторое время Ч может, сбой вызван временными затруднениями в сети или другими преходящими причинами.

466 ЧАСТЬ 1 Служба каталогов Active Directory Узнать, какой контроллер обладает хозяина схемы, можно в осна стке Schema Active Directory (Схема Active Directory) или посредством служеб ной программой Примечание средствами программ не удается определить хозяина схемы, обратитесь к служебной программе Ldp или Edit и узнайте значение Role Owner контейнера схемы Ч в нем хранятся о текущем владельце роли схемы.

Для повышения уровня диагностики каталогов, на котором регистрируются ошибки, по которым удается узнать о причинах неполадок, увеличьте до 3 зна чение Internal Processing в разделе Операции одиночного хозяина Некоторые выполняются специально назначенными до называемыми хозяевами операций. Говорят, что они обладают определенной ролью одиночного хозяина операции или FSMO-ролью (Flexible Single Master Operations). К таким операциям модификация схемы, создание доменов в лесе, создание относительных идентификаторов (R1D) участников безо обновление доменов Windows NT 4.0 и более ранних версий, а также ссы лок на объекты в других доменах.

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

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

неполадки начните с сервера владельца роли хозяина относительных идентификаторов - и проверки сетевого соединения средствами ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Netdiag. Кроме в окне Event Viewer (Просмотр собы тий) нет ли в журнале службы каталогов ошибок, относящихся к хо зяину t:0x398 00279 Enter t:0x398 00280 Enter 00281 Exit massageUserName dcpromoui 00282 Calling 00283 : Reskit dcpromoui t:0x398 00284 : reskit-rdp.com dcproraoui t:0x398 00285 :

dcpromoui 00286 : reskit t:0x398 00287 fJoinOptions : 0x dcpromoui t:0x398 00288 Error 0x2010 (!0 => error) dcpromoui 00289 Exit 00290 Exception caught dcpromoui 00291 catch completed dcpromoui t:0x398 00292 handling exception dcpromoui 00293 Error dcpromoui 00294 The service was to allocate a relative identifier.

00295 Enter result The directory service unable to allocate a relative identifier.

dcpromoui 00296 Exit FAILURE message: The directory service was unable to allocate a relative identifier.

Хозяева операций и их двойники В Windows NT 4.0 NetBIOS-имя основного контроллера домена уникально, поэто му конфликт двойников основного контроллера разрешался автоматически. Такие двойники иногда возникают при роли резервного контроллера во вре мя недоступности исходного контроллера и дальнейшего возвращения последнего из состояния недоступности.

В Windows 2000 контроллера домена не настолько важна, но в любом случае конфликты нежелательны. Наличие двойников хозяина относи тельных идентификаторов способно привести к образованию одинаковых иденти безопасности (security ID, SID).

Далее перечислены операции, для предупреждения двойников хозяина относительных Х синхронизация сервера с другими серверами перед роли операций;

Х репликация состояния (доступного) пула относитель ных идентификаторов, чтобы возможные на роль хозяина относи тельных идентификаторов содержали самые свежие* данные;

Х если хозяин относительных идентификаторов выделит контроллеру домена пул RID, перекрывающийся с пулом другого контроллера контроллер на, чей набор перекрывается с новым набором относительных заметит это при репликации, отбросит свой текущий пул и затребует у RID новый. Такая процедура предотвращает дальнейшее использование одина ковых RID и быстро заставляет все контроллеры домена с пулами запросить и получить новые наборы относительных идентификаторов;

468 ЧАСТЬ 1 Служба каталогов Active Directory Х операционная система поддерживает обнаружение и обработку одинаковых от носительных идентификаторов.

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

Служебная программа Ntdsutil содержит команду Security account management для обнаружения и устранения повторяющихся Учетные запи си с одинаковыми идентификаторами безопасности удаляются, Обнаружение и SID 1. Заархивируйте Active Directory. архивирования в Windows 2000 под держивает архивирование Active Directory в подключенном состоянии. Это про исходит автоматически при выборе варианта архивирования всех данных на компьютере или только состояния системы в Backup Wizard (Мастер архивации и восстановления Windows 2000).

3. Выберите Directory Services Restore Mode (Восстановление службы каталогов) и нажмите Enter. Чтобы запустить загрузки, снова нажмите Enter.

4. Войдите в систему под учетной записью Administrator (Администратор), исполь зуя пароль, заданный для локальной учетной записи Administrator в автоном ном SAM.

5. В меню Start (Пуск) последовательно выберите Programs (Программы), Ac cessories (Стандартные) и затем щелкните Command Prompt (Командная строка).

6. В окне командной строки введите ntdsutil и нажмите Enter.

7. Введите Security account management и нажмите 8. Введите Connect to server и нажмите Enter.

9. В приглашении Security account management (Обслуживание учетных записей безопасности) введите Cleanup Duplicate SID и нажмите Enter.

Программа начнет очистку повторяющихся SID. Результаты выполнения стрируются в файле расположенном в каталоге, из которого Вы за пустили Ntdsutil.

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

В общем случае дублирование ролей хозяев одиночных операций в конечном счете разрешается автоматически в процессе репликации. Обновления в базе данных бо лее нового владельца роли обладают высоким порядковым номером обновле ния (update sequence number, и поэтому он замещает предыдущего владель ГЛАВА Выявление и неполадок, а также восстановление Active Directory ца роли при репликации нового владельца роли в данных каталога.

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

Лучше всего вообще не допускать возникновения двойников. Тем не менее эта блема решается размещением старого хозяина относительных идентификаторов в сайте нового владельца и немедленным запуском принудительной репликации.

Подробнее об операциях одиночного хозяина и устранении неполадок при таких операциях Ч в главе 7 Управление операциями одиночного хозяина.

Неполадки репликации В Active Directory существует только два вида репликации: синхронная по прото колу RPC (Remote Procedure и асинхронная с использованием службы tersite Messaging (ISM).

При репликации поддерживаются следующие виды Х синхронный RPC: транспорт, поддерживающий доверительные отношения по протоколу Kerberos v5;

Х асинхронный: транспорт, не поддерживающий доверительные отношения, пасность обеспечивается на основе сертификатов каталога.

Примечание Одно важное требование транспортного модуля ISM: он работает ду раздельными (disconnected) сетями. Это не требование реализации модуля, а тре бования вызванное особенностями его работы. Среды, в которых он ся, не поддерживают прямые пути и проходят через некоторые из них передаются по незащищенным Транспорт в таких средах должен допускать длительные задержки (латентноеть), проходить через шлюзы и поддерживать сохранение и пересылку в случае недоступности одного или несколь ких шлюзов.

неполадок репликации на основе почты 1. Проверьте, нет ли в журнале каких-либо сообщений, относящихся к рассматри ваемой неполадке. Возможные проблемы топологии служ бой КСС, неполадки при доставке почты в службе SMTP неполад ки чтения сообщений в службе ISM, проблемы NTDS при расшифровке и ис пользовании из почты.

2. Убедитесь, что КСС настроена на использование SMTP-соединений между сер верами в выбранных сайтах.

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

Х серверы размещены в сайтах, объединенных связями сайтов на SMTP;

Х стоимость связи между сайтами для SMTP чем для IP;

470 ЧАСТЬ 1 Служба каталогов Active Directory Х реплики одного домена не по SMTP. (Эта функция не Таким образом поддерживается репликация глобального каталога, и схемы (то есть недоменных разделов каталога);

Х все серверы настроены на получение почты. Web-сервер IIS должен ус тановлен на обоих серверах.

Обратите внимание, что связь между сайтами, по осуществляется через (bridgehead). KCC выбирает такие серверы для каж дого сайта самостоятельно, если они не явно. Назначая серверы-плац дармы явно, убедитесь, что они содержат раздел домена, который будет репли цироваться.

4. Перед перемещением сервера в поддерживающий репликацию только по почте, следует убедиться в у него сертификата контроллера (Domain Controller Certificate). На одном из контроллеров доменов на предпри ятии следует установить центр сертификации предприятия (Enterprise Cer tificate Authority). По истечении определенного времени (до 8 часов) после ус тановки все контроллеры данного домена автоматически регистрируются на нем и получают сертификаты контроллера домена. Проверить наличие у компь ютера такого сертификата в оснастке Certificates (Сертификаты) [в пап ке Personal или командой 5. Для репликации на базе почты следует определиться, необходима ли маршрути почты. Если два сервера обладают прямым IP-соединением и способны об почтой никакой дополнительной настройки не требуется.

Однако, контроллеры домена обмениваться почтой через шлюзы, их следует сконфигурировать для работы со шлюзом электронной почты. Обычно для этого устанавливают Smart Host на Default SMTP Virtual Server (Виртуаль ный SMTP-сервер по умолчанию) в разделе Internet Information Services оснаст ки Computer Configuration (Управление компьютером).

6. Проверьте корректность выполнения репликации по почте, выполнив команду repadmin Программа предоставляет сведения о коде текущей ошиб ки и времени последнего успешного обновления. Если текущий код ошибки request is pending (то есть запрос на обновление задерживается) и со времени последнего успешного обновления прошло более часа, это свидетельствует о за держке почты или о том, что сообщение доставлено. Нужно иметь в виду, что почта не доставляется немедленно, доставка выполняется по механизму нить и переслать, а не по соединению.

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

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

Х net stop Х net start stmpsvc Х net start ftpsvc Х net start ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory При отправляется вся текущая корреспонденция.

Х Для проверки синхронизации каталогов на основе обмена можно описанными процедурами. Допустим, у нас есть два компьютера - А и В. В окне Windows Explorer (Проводник Windows) в этих откройте папку ложим, что обновление выполняется от В к А. На компьютере А проведите с В средствами Active Directory Sites and Services (Active Directory сайты и службы). Система А обратиться к В с почтовым запросом об обновлении. В окне Windows Explorer в папке Drop должны появиться один или более временных почтовых фай лов, которые по мере обработки исчезают. После этого временные файлы должны появиться в папке Drop на компьютере А. Это ответные по чтовые сообщения с данными, отправленными в ответ на Временные файлы также должны исчезать по мере их обработки.

Х Далее следует проверить, считывает ли почту служба Intersitc Messaging Service (ISM). Изучите содержимое панок _ на получателе и источнике. По умолчанию каталог журналов находится по адресу если только он не перемещен средствами служеб программы Ntdsutil. Папка Drop содержит входящую почту. Наличие в пей множества почтовых сообщений свидетельствует об остановке службы или о слишком большом входящем потоке сообщений, которые служба не в обработать. Остановившуюся службу следует перезапустить. Если поток почтовых сообщений велик, следует увеличить период почтовой реп ликации. Только в качестве крайней меры допускается останов службы удаление сообщений из папки Drop и последующий перезапуск служ бы. Это позволит службе устранить создавшееся так как, в ко отправители все равно передадут с обнов лениями, 7. Еще один параметр, который требуется проверить, - отсутствие неполадок при доставке. Убедитесь, что каждое из звеньев почтового маршрута соединено своими соседями напрямую, по протоколу IP. Кроме этого выясните способность каждого из серверов разрешать имя следующего по маршруту сервера. Почто вый адрес, используемый для подключения между контроллерами домена Ч на основе имеющее следующий вид Необходимо убедиться выполнения команды ping для этого имени.

8. Если не удается доставить почту, служба о состоянии доставки (Delivery Status Notification, DSN). Эти реги стрируются в журнале при высоком уровне диагностики. Чтобы их увидеть, нужно установить уровень 1 диагностики Active Directory в параметре Inter-site и перезапустить службу SMTP. Подробнее об уровнях диагностики Active Directory и их установке Ч в разделе Регистрация событий Active Directory ранее в этой главе.

в журнале службы каталогов, относящиеся к репликации Далее перечислены типы записей в журнале службы каталогов, к ошибкам репликации:

472 ЧАСТЬ 1 Служба каталогов Active Directory Х неполадки службы проверки согласованности знаний (Knowledge Consistency KCC);

Х задержка входящей репликации;

Х конфликт со службой сертификации;

Х отсутствие Х имя пользователя и/или пароль;

Х автоматического создания топологии не удалось сформировать то пологию.

Неполадки КСС В журнале службы каталогов Бы можете обнаружить запись [с кодом и с указанием источника 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 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 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 to a Domain Controller that contains the partition in this site from a Controller that contains the same partition in another site.

For (b), please 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) создается автоматически. Этот сайт участвует в заданной по умол чанию связи сайтов создаваемой автоматически и ис пользуемой для связи по поверх TCP/IP. Создавая два сай та, администратор обязан определить связь сайтов, к которой они будут относить ся, иначе эти сайты не будут размещены в Active Directory.

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

ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory Примечание Отображая это сообщение, находится в режиме, в котором можно никакие подключения. Обычно КСС удаляет старые, оставшиеся от предыдущих конфигураций а также излишние подключения. Поэтому на этом Вы можете обнаружить новые подключения в неожиданных местах. Эта пробле ма решается коррекцией топологии с созданием связующего дерева.

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

Event A running inbound has The elapsed was minutes.

The operation was and the options were The status of the operation was:

The operation specific arguments Parameter Parameter 2:

Parameter 3:

Parameter 4:

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 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 number of complex updates attributes) at the 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, because of installation, Global Catalog promotion, or connection creation by the KCC. A long running may also occur for a system that has been down, or a partition that has been out of touch an period.

The record data is the status code.

logging_level: Event Due to contention with the Certificate Services for resources, replication was stalled for minutes, 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.

474 ЧАСТЬ 1 каталогов Active Directory Event Due to contention with Security Propagator for resources, inbound replication was stalled seconds. This condition should be transient. If this issue persists, please contact Microsoft Product Support Services for assistance.

Event One or more new attributes has been to the partial attribute set for partition (1. A full synchronization will be performed from source on the next periodic Event A new replica for partition has been added to this server. This server will now a full from source with options ЯЗ.

logging_level: Event Severity=Informational The user has requested a full synchronization of partition from source with options КЗ.

Event The full synchronization of partition from source with options in being continued.

logging_level: сервера Сообщение о недоступности сервера server is unavailable) обычно сви детельствуют об отключении компьютера.

Примечание В случае невозможности разрешения имени Active Directory щает ошибку, явно информирующую об этом Ч The name can not be resolved.

Подробнее о сообщениях об ошибках сервера Ч в разделе решение ранее в этой главе.

Неверное имя пользователя н/или пароль Для устранения сопровождающимися сообщением Unknown user name/ bad служебную программу на контроллере домена.

Например, так:

Controllers, Если номера версии атрибута каких-либо объектов различаются на двух или более контроллерах домена, разумно предположить, что пароли не ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory и не и поэтому не в состоя нии выполнить проверку подлинности. В такой ситуации следует сбро пароли учетных записей компьютера.

способна сравнивать метаданные объек та что позволяет автоматизировать описанные в предше ствующем Подробнее о программе - в Неполадки кон троллера домена ранее в этой главе.

репликации из-за нарушения доступа О неполадках, связанных с безопасностью, ошибки разрешения имени получателя Target Name) или сообщения о невозможности контроллер locate domain Важно понимать, что суще ствует между репликацией и безопасностью распределенных си стем на Подтверждение подлинности в процессе репликации вы полняется по протоколу Kerberos а участники Kerberos реплици руются механизму репликации.

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

В процессе установки Active Directory компьютер становится контроллером доме па (назовем его получатель), к предприятию, общаясь с суще ствующим контроллером домена (назовем его источник). До перезапуска и самона получателя источник контроллером домепа в пред приятии, который знает о существовании получателя.

Примечание Таким образом, на некоторое время существующий контроллер доме на становится единственным (single point of - пока ные не реплицируются на другие контроллеры домена. Это одна того, что перед удалением Active Directory (то перед запуском мастера установки Active Directory) с контроллера домена система должна успешно выполнить исходящую Если компьютер полностью выходит из строя будучи источником, данные о новом контроллере домена остаются недоступными для остальных ком пьютеров.

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

Таким образом, обнаружив ошибку нарушения доступа Access Denied, распространились ли данные о недавно контроллерах домена по все му предприятию. репликации на компьютерах способны репликации объекта учетной записи недавно назначенного контрол лера 476 ЧАСТЬ 1 Служба каталогов Active Directory Неудача создания Сообщение о создать топологию репликации Automatic topology generator was unable to complete the topology for в жур нале службы каталогов в окне Event Viewer (Просмотр событий) о возникновении исключения в службе проверки согласованности знаний (Know ledge Consistency Checker, Для получения более подробных сведений следует увеличить до 3 значение пара метра Internal Processing реестра в разделе Current Control и подождать 15 минут.

Дополнительно Вы можете выполнить команду и сбросить значение параметра реестра до 0.

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

Наблюдение за связями репликации Служебная программа администрирования репликации (Replication Administration) применяется для наблюдения за текущими связями контроллера домена, а также контроллерами обменивающимися с ним данными репли кации. Изучая сведения о связях, Repadmin, Вы можете изучать то пологию репликации текущего сервера. о топологии позволяют проверять согласованность репликации между осуществлять мониторинг состоя ния и отображать метаданные репликации.

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

Например, для определения того, какие контроллеры домена получили некое реп изменение, выполните следующую команду:

repadmin где Ч имя контроллера домена Ч получателя, для ко торого изучается репликация объекта из подразделения PR, размещенного, в свою очередь, в подразделении Marketing домена Reskit.com, Строки, ные этой командой, содержат порядковый номер (update sequence number, USN), DSA отправителя, дату и время, номер версии и реплицируемый атрибут.

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

ГЛАВА и устранение неполадок, а также восстановление Active К примеру режима домена распространяется по обычному механизму репликации. Для передачи таких сведений служит атрибут объектов класса домена). Отличное от нуля значение указывает на смешанный режим, а нуль Ч на основной режим. Чтобы проверить распространение домена, Вы можете определить значение этого атрибута на всех контроллерах данного домена.

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

В обычных условиях не требуется создавать топологию Неправильное использование служебной способно отри цательно сказаться на топологии репликации. В основном она применяется для наблюдения за репликацией с целью выявления потенциальных проблем, напри мер отключенных серверов или недоступных сетевых соединений в локальных (LAN) и глобальных (WAN) сетях.

Repadmin Repadmin.exe Ч служебная программа командной строки, позволяющая про и изменять состояние репликации на контроллерах домена в процессе диагностики и устранения неполадок репликации между домена под управлением Windows 2000. Средствами Repadmin Вы можете изучать текущую топологию репликации, создавать топологию репликации вручную и принудитель но выполнять операции репликации.

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

Подробнее об использовании Repadmin Ч в системе Windows Support Tools.

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

Изучая сведения о связях, возвращенных Repadmin, Вы можете изучать топологию репликации текущего сервера. Некоторые связи оказываются недоступными, что пре пятствует созданию любых новых связей через соответствующий сервер.

При просмотре связей отдельного контроллера домена в Repadmin Вы видите парт неров репликации, поддерживаемых в текущее время службой КСС для данного сервера. расположенные в контейнере Sites, могут отсут ствовать в Repadmin.

Просмотр текущих партнеров репликации отдельного сервера Х В командной строке server 478 ЧАСТЬ 1 каталогов Active Directory Принудительная репликация между партнерами Существуют четыре способа инициации репликации между прямыми партнерами репликации. В трех из них используются административные служебные програм мы, а четвертый метод Ч это сценарий Visual Basic. Подробнее о сце нариев на Microsoft Platform SDK по адресу ссылка Microsoft Knowledge Base и далее ссылка на статью Далее мы описываем эти методы. Здесь листочник Ч это контроллер домена, от данных репликации, а Ч контроллер домена, получающий сведения об изменениях от источника.

репликация Active Services В консоли управления Active Directory Sites Services (Active Directory Ч сай ты и службы) щелкните кнопкой мыши и в открывав шемся контекстном меню выберите команду Replicate Now (Реплицировать сей час). (Подробнее о принудительной репликации средствами оснастки Active Di rectory Sites and Services Ч в справочной системе Windows 2000 Server.) Принудительная репликация это программа командной строки, входящая в состав средств поддержки, расположенных в папке Support на компакт-диске с операционной сис темой Windows 2000. Она позволяет сначала определить партнеры репликации ка талога для конкретного сервера-получателя, а затем выполнить сер вера-источника с получателем, указав сервера-источника, Принудительная репликация между двумя серверами средствами Repadmin 1. В командной строке введите следующую строку:

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

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

3. Выполните принудительную репликацию следующей командой:

Например, для выполнения принудительной репликации изменений в разделе до мена support.reskit.com из сервера DC1 в сервер DC2 следует выполнить следую щую команду:

repadmin /sync DC1 d2e3badd-e07a-11d2-b573~ В случае успешного выполнения команды появится следующее from to dest: DC1 is successful.

ГЛАВА 10 Выявление и устранение неполадок, а также восстановление Active Directory Вы вправе использовать следующие параметры командной строки:

- /force: Overrides the normal replication schedule.

- /async: Starts the replication event. does not wait for the replication event to finish.) Первый вынуждает программу игнорировать обычное расписание репли кации, а второй запускает репликацию, не ожидая окончания текущей реп ликации.

Вот пример выполнения программы repadmin:

repadmin DSA Options (none) INBOUND ====================================== via RPC objectGuid:

Last о 1999-05-10 22:47.33 failed, result 1722:

The RPC server is unavailable.

Last success 1999-05-10 22:02,32.

Б consecutive via RPC objectGuid:

Last attempt 1999-05-10 22:47.32 was successful.

via RPC objectGuid:

Last attempt з 1999-05-10 22:47.33 was successful.

via RPC objectGuid:

Last attempt 22:47.33 failed, result 1722:

The server is unavailable.

Last success з 1999-05-10 22:02.32.

6 consecutive CN=Configuration, DC=reskit, 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).

via RPC objectGuid:

Last attempt з 1999-05-10 22:48.26 was successful.

==== OUTBOUND FOR CHANGE NOTIFICATIONS ============ via RPC via RPC objectGuid:

480 ЧАСТЬ 1 Служба каталогов Active via RPC objectGuid:

via RPC via RPC objectGuid:

via RPC objectGuid:

Просмотр состояния и производительности репликации (Active Directory Replication Monitor) - это служебная программа с графическим интерфейсом позволяющая наблюдать за низкоуровне вым состоянием и производительностью репликации между контроллерами доме на Active Directory. Она:

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

Х отображает серверы, с которыми компьютер обменивается данными реплика ции Ч как напрямую, так и опосредствованно Х отображает свойства данного сервера, в том числе: имя сервера, DNS-имя ком пьютера, положение учетной записи компьютера в Active Directory, состояние основного сервера-плацдарма, все специализированные флаги мер, эмулятор домена), сведения о владельцах ролей одиночного хозяина и подключениях репликации различает создан ные автоматически и вручную администратором);

Х для прямых партнеров репликации приводится информация о значении кового номера обновления (update sequence number, USN), число неудачных по пыток, причины и флаги каждого партнера. На вкладках страниц свойств каж дого прямого репликации содержатся следующие сведения: имя кон троллера домена, его каталога, реплицируемый из него на данный сервер, вид используемого транспорта (RPC или SMTP, а также данные о внут ри- и транспорте в случае использования RPC), время последних и событий порядковый номер обновления и любые другие свойства подключения между этими двумя серверами;

Х содержит мастер сервера, позволяющий администраторам выбирать партнеры из списка, даже не зная сервера. Администратор также вправе создать файл с расширением список имен серверов для наблюдения. При 10 Выявление и устранение неполадок, а также восстановление Active Directory загрузке этого файла в ReplMon программа отображает в графическом интер фейсе пользователя сведения об указанных серверах;

автоматически домен клиента и отображает эту информацию;

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

отображает конфигурацию отдаленных контроллеров домена (например, сведе ния об обладании ролью эмулятора PDC);

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

администраторы получают возможность синхронизировать между собой только два контроллера домена. Позволяет администраторам выполнять репликацию сервера с определенным партнером репликации, со всеми остальными контрол лерами домена в сайте или всеми контроллерами домена в данном и остальных сайтах, (Партнеры репликации задаются на основе данных, которые они содер жат. Не все контроллеры домена вовлекаются в этот процесс;

выбор определя ется синхронизируемым контроллером администраторы вправе принуждать КСС к пересчету топологии регистрирует действия, выполняемые служебной программой;

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

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

показывает администраторам, какие еще из ного отображает метаданные атрибутов объектов Active Directory, в том числе: имя атрибута, номер версии, время последнего атрибута, контроллер до мена - источник последних изменений атрибута и номера обновлений (USN) на наблюдаемом сервере и на компьютере, где изменение инициировано;

предоставляет контекстные сведения и об использовании функций при размещении указателя мыши над ними;

генерирует отчеты для отдела технической поддержки. Позволяет администра создавать отчет о состоянии наблюдаемого сервера. В него включены дан ные о разделах каталога на сервере, о состоянии каждого партнера репликации 482 ЧАСТЬ 1 Служба каталогов Active Directory (прямой и разделе каталога и о любых объектах груп политики, сведения о домена, моментальный снимок счетчиков производительности компьютера и ция о реестра сервера (в том числе параметры КСС, Active Di rectory, Jet и Кроме того, администратор способен добавить (в этот же отчет) данные о конфигурации предприятия, содержащие все сайты, связи сай мосты связей сайтов, подсети и контроллеры любых доменов и свойства всех перечисленных объектов. для контроллера домена приводятся информация о его идентификатору записи в DNS и используемой для учетной записи компьютера в Active Directory, адрес службы (если он существует), имя ком пьютера и специальные флаги для сервера (например, флаг, указывающий на сервер глобального каталога). Эти сведения чрезвычайно полезны для ния неполадок репликации Active Directory;

Х предоставление реквизитов проверки позволяя ReplMon одновременно наблюдать за состоянием репликации контрол леров домена в нескольких лесах.

Требования, предъявляемые Монитор репликации Active Directory (Replmon) разрешается устанавливать на компьютере под управлением Microsoft Windows 2000 Professional или Win dows 2000 Server Ч на контроллере домена, рядовом сервере, рабочей станции до мена или на изолированном компьютере. Кроме того, Replmon применяют для од наблюдения за контроллерами доменов в различных лесах.

Использование для определения GUID объекта DSA сервера Ч основная информация, используемая в Active Directory и DNS для поиска домена в процессе репликации. Такой уникальный и повторно не используемый идентификатор автоматически присваи вается каждому контроллеру домена, Примечание Существуют для различных целей. GUID-идентификаторы в программе называ ются

Base Filter : (cn=NTDS Settings) Scope: Subtree Attributes: objectGUID Параметр на имя первого домена, созданного в пред приятии домен леса).

2. В результатах поиска Вы получите сервер, GUID ко торого В данных также должен ат рибут objectGUID. Вот вид сообщений программы:

ГЛАВА Выявление и устранение неполадок, а также восстановление Active Directory 1, attrLlst, 0, Result (null) Matched DNs:

Getting 1 entries:

CN=NTDS 1> objectGUID:

В последней строке содержится искомое значение атрибута objectGUID объекта DSA.

о служебных программах командной строки для Active Directory - в справочной системе Windows 2000 Resource Kit.

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

Поскольку Active Directory Ч это не только база данных, но и служба каталогов на основе этой базы данных, она способна восстанавливать поте информацию:

Х база данных восстанавливает потерянную информацию, используя журналов;

Х каталогов восстанавливает данные, обращаясь за ними и их от других серверов домена.

Существует ряд служебных предназначенных для восстановления как самого контроллера домена, так и службы каталогов Active Directory.

Подробнее о защите от сбоев в Windows 2000, в том об архивировании, вос становлении и коррекции Ч в книге Сопровождение сервера. Ресурсы Windows 2000 Server (Русская 2001), а также в документации к опе рационной системе и в справочной системе Microsoft Windows 2000 Server.

Восстановление контроллера домена Существует несколько способов восстановления потерпевшего сбой контроллера домена под управлением Windows 2000 Server. Вы вправе как одно, так и все эти средства и методы Х Мастер Emergency Repair Disk (ERD) wizard (мастер Диск аварийного служебной программы Ntbackup (Архивация). в тему учетной (Администратор) или Backup (Оператор архива). этот мастер для создания набора дисков, кото рые понадобятся в дальнейшем для контроллера домена.

Х Переустановка операционной системы Windows 2000 и выполнение Active Directory Installation Wizard (Мастер установки Active Directory) romo.exe). В случае серьезного сбоя, требующего полного восстановления ком 484 ЧАСТЬ 1 Служба каталогов Active Directory повторно установите систему. Обеспечьте такое же, как и прежде, или большее число и размер дисковых томов. настройте се тевые подключения и DNS, как Вы это делали первичной установке и на стройке.

Х Служебная программа Netdom. При необходимости удалить домен запустите мастер установки Active Directory и удалите Active Directory со всех контрол леров удаляемого домена. Далее программой netdom для удале ния самого (в том числе объектов перекрестных ссылок и доверенных доменов). Например, введите в командной строке:

trust /remove /force Х Команда Cleanup служебной программы Ntdsutil. Чтобы удалить метаданные, оставшиеся после понижения роли или сбоя контроллера домена, воспользуй тесь командой Cleanup. Она удаляет ставшую неактуальной информацию о кон троллере домена и устаревшие из каталога. Кроме этого Вам, вероятно, придется дополнительно установить Active Directory и контроллеру домена старое имя. Обновленные данные и сведения о партнерах контроллер домена получит в процессе репликации.

Подробнее об установке и удалении Active Directory Installation (Мастер установки Active Directory) (служебная программа Dcpromo) Ч в главе Хранение данных в Active Directory. Подробнее о служебной программе Ntdsutil Ч в приложении В Ч служебная программа диагностики Active Directory.

Восстановление резервного контроллера домена под управлением Windows 4. Важной задачей является восстановление потерянной учетной записи резервного контроллера домена под управлением Windows NT 4.0 в среде смешанного Следует знать, как поступать в случае разрушения или случайного удаления такой учетной записи Примечание При случайном удалении компьютера Ч резервного контроллера до мена смешанного режима следует выполнить команду dsacls.

Восстановление учетной записи резервного контроллера домена 1. Войдите локально под административной учетной записью в систему проблем ного компьютера.

2. Запустите Server Manager.

В меню Start щелкните Run и в открывшемся окне введите Откроется окно диспетчера под управлением Windows NT 3. Повторно создайте учетную запись резервного контроллера домена. (На самом эта операция выполняется на основном контроллере домена.) 4. Воспользуйтесь командой force sync для корректного сброса пароля.

Восстановление после учетной и доменной записи компьютера под управлением Windows Вот пример сообщения об ошибке, отображаемого при перезапуске пос ле удаления его учетной и доменной записи:

ГЛАВА 10 Выявление и устранение а также восстановление Active Directory 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: 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.

486 ЧАСТЬ 1 Служба каталогов Active Directory Х Если в домене контроллера домена, Directory восстанавливается посредством стандартной процедуры репликации данных от партнеров Х Ntbackup Backup and Restore Wizards архивации и восстановления служебной программы их для восстанов ления состояния системы из при этом восстанавливаются Active Directory, FRS том числе и службы сертификации (если они были ранее уста К этому варианту следует когда в домене нет других кон троллеров, с которых данный компьютер мог бы реплицировать В случаях восстановления Active Directory после отказа или замены оборудования, данные на других контроллерах домена заведомо обновлены и устойчивы, Вы выполнять только непринудительное восстановление из последнего архи ва, После непринудительного механизм репликации Active Di rectory автоматически заполняет базу данных данного контроллера обновленной информацией из других контроллеров домена об изменениях, произошедших с мо мента создания архива.

Дополнительные материалы об Active Directory Ч на Web Resources по адресу ссылка Microsoft Platform SDK.

Подробнее о конкретных примерах упомянутых данной главе, а так же о текущих по диагностике и устранению неполадок Ч на Web Web Resources по адресу reskit/webresources, ссылка Microsoft Product Support Services.

Безопасность в распределенных системах Зашита и безопасность системы чрезвычайно как для руководителей, так и администраторов - независимо от масштаба управляемых ими сетей. В это части описаны функции Microsoft Windows 2000, используемые для защиты доступа к сетям и ресурсам, а также для и данных и В части Проверка подлинности Глава 12 Управление доступом Глава 13 Обеспечение безопасности средствами технологии открытого ключа 14 Криптография в сетевых системах Глава 15 Шифрованная файловая система Глава Службы сертификации и инфраструктура открытого ключа в Windows 2000 I Проверка подлинности По для сетевой подлинности в Microsoft Windows 2000 ис пользуется протокол Kerberosv5. Этот недавно появившийся стандарт проверки подлинности применяется для взаимодействия систем, а также позво повысить безопасность сетевой проверки подлинности в масштабах предпри ятия. Основные особенности данного протокола, характерные Win dows 2000, Ч это интеграция входной проверки подлинности с архитектурой разо вого входа в систему (служба Active Directory в качестве базы записей безопасности домена, реализация клиента в каче стве поставщика безопасности в Windows 2000 через интерфейс SSP[ (Security Support Provider Interface).

В этой главе Основы подлинности Протоколы проверки подлинности Основы работы протокола Kerberos Компоненты в Windows 2000 Данные авторизации Интерактивный вход в систему См. также Х Подробнее о том, как сетевые клиенты контроллер домена, - в главе имен в Active Directory.

Х Подробнее об авторизации Ч в главе 12 доступом.

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

ГЛАВА 11 Проверка подлинности подлинности обоих типов производится при пересечении государствен ной границы. В ответ на просьбу пограничника предъявить документы щий свой паспорт. Пограничник проверяет подлинность паспорта (объекта), выясняя выдан ли он органом, пользующимся доверием властей его стра ны (или, по крайней мере, признаются ли в стране въезда выдаваемые таким орга ном Кроме того, сличает лицо въезжающего с фо тографией в паспорте. Убедившись, что и именно въезжающий является его владельцем, разрешает въезд. Если результат хотя бы од ной операции не удовлетворителен, будет отказано во въезде в страну.

Проверка подлинности при границы основана на действии механизма отношений. Власти страны въезда лично Вас не но они дове ряют властям Вашей страны. Властям своей страны Вы также лично незнакомы, но при выдаче паспорта они доверяют Вашему свидетельству о рождении. Орган, свидетельство о рождении в свою очередь доверяет врачу, подписавше му акт о Вашем рождении. Доверительные передаваемые образом через доверенных посредников, называются Транзитив ное доверие между центрами (security authority) является основопо лагающим сетевой безопасности в Windows 2000.

Интерактивный вход в систему Вход в систему с клавиатуры компьютера под управлением Windows нает пересечение границы. Пограничник просит предъявить удостоверение сти, а въезжающий показывает документы, выданные органами власти. В случае пограничник - это служба подсистемы безопасности, выполняю щаяся в процессе диспетчера локальной (Local Security Authority, Winlogon открывает диалоговое окно, где указать учетную и имя создавшего его центра В системах под управлением Windows 2000 права па учетную запись подтверждаются паролем. В системах, ос нащенных специальным оборудованием, данные, необходимые для проверки под линности, разрешается считывать со смарт-карты. Полученные идентификацион ные данные Winlogon упаковывает в структуру данных определенного формата и направляет в LSA для проверки. После того как установит, что указанная учет ная запись и подтвердит полномочия входящего в систему, Winlogon от кроет интерактивный сеанс. В случае доступ в компьютер будет закрыт.

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

Удаленный вход в систему Независимо от того, где подтверждается подлинность, она всегда только одним диспетчером безопасности - компьютера, с которого произво дится вход в систему. Доступность учетных записей домена обусловлена тем, что LSA рабочей станции доверяет безопасности домена. Аналогично ему и другие компьютеры под управлением Windows 2000, принадлежа щие этому домену, однако, чтобы получить доступ к их ресурсам, необходимо вой 490 ЧАСТЬ Безопасность в распределенных системах в систему с каждого В случае не имеет значения, что Ваш пас порт проштампован при входе в систему с последнего используемого компьютера.

Паспорт нужно предъявлять всякий при входе в систему в качестве сетевого клиента под управлением Windows 2000.

При попытке получить доступ к ресурсам удаленного компьютера под управлени ем Windows 2000 по сети Ч с локальною компьютера Ч вводить информацию в диалоговое окно с клавиатуры уже не нужно. текущей рабочей станции уста новит Вашу обратившись к LSA удаленного компьютера и восполь зовавшись в во время первичного интерактивного вхо да в систему.

Участники безопасности Любой объект, способный инициировать действие в системе под управлением Windows 2000 является участником безопасности (security principal). Участниками безопасности могут быть не только пользователи, но и компьютеры, и службы моны в терминологии Участник безопасности согласно предос тавляет системе, в которой собирается работать, свои верительные грамоты, вы данные центром Например, в домен компью теры под Windows 2000 связь с домена в то время, когда никто из пользователей не находится в системе. Для входа в домен необходимо иметь свою учетную запись, реквизиты ко торой он должен предъявлять при входе. Прежде компьютер войдет в домен, LSA контроллера домена проверяет его подлинность таким как и под линность пользователей, В отличие от приложений, запускаемых пользователем и в его контексте безопасности, служба в Windows 2000 запускается служб.

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

но пользователям, чтобы получить доступ к ресурсам домена, службы должны в него войти. В процессе запуска службы контроллер служб входит в систему под учетной записью этой службы и LSA ее Например, при входе компьютера управлением Windows 2000 в домен служба Net Logon (Сетевой вход в систему) текущего компьютера соединяется с контрол лером домена и создает безопасный капал связи. Чтобы успешно пройти проверку подлинности при с домена, Net Logon пред ставить реквизиты, которым компьютера, при этом как и прочие службы, выполняющиеся в контексте локальной системы, использует реквизиты учетной записи компьютера в домене. Служба, работающая в контек сте локальной системы, должна иметь собственную учетную запись в Протоколы проверки подлинности Windows 2000 поддерживает удостове рения подлинности имеющих учетные записи в системе. К ним так же относятся протоколы проверки удаленных соединений и пользова телей, входящих в сеть через Вместе с тем для сетевой проверки ности внутри и между доменами Windows 2000 используется всего два протокола.

Протокол Kerberos v5 Ч применяется по умолчанию для проверки подлинности пользователей, в домен с под Windows 2000.

ГЛАВА 11 подлинности Протокол Использовавшийся по умолчанию в Microsoft Win dows NT версии 4.0, он сохранен в Windows 2000 для обратной с клиентами и серверами под ранних версий Windows NT.

Kerberos применяется всегда, когда есть возможность выпора между двумя указанными протоколами. Во всех случаях, когда требуется совмести мость с предыдущими версиями Windows, протокол NTLM. исполь зуется клиентами под управлением Microsoft Windows 3.11, Windows Microsoft Windows 98 и Windows в доменах Windows 2000 и под управлением Windows 2000 в доменах Windows NT 4.0.

Основы работы протокола Kerberos В протоколе Kerberos реализован механизм взаимной подлинности при создании сетевого между клиентом и сервером. Протокол чен для обеспечения взаимодействия клиента и сервера открытой сети Ч в окру жении, в котором большинство клиентов и серверов не защищены физически и пе редающиеся по сети пакеты можно перехватить и изменить. Другими словами, дан ный протокол разработан для применения в сетевом окруже нии, где злоумышленник может легко выступать как в качестве клиента, так и сер вера, и перехватывать или пакеты, которыми обмениваются объекты сети.

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

Предположим, что Алиса с Бобом, а Боб, прежде чем ваться в ее сообщении убедиться в Алисы. Они договариваются о пароле, который только им двоим. Если послание указывает на то, что его отправитель знает пароль, Боб мо жет уверен в том, что сообщение написала именно Алиса.

Неясным остается вопрос, каким образом Алиса подтвердит знание пароля. Пред положим, что она напишет его в тексте сразу после подписи. Та кой способ оправдан только при условии, что кроме и Алисы не в состоянии прочитать которыми они обмениваются. К сожа лению, системы почты этого не обеспечивают. Нет что какой-нибудь другой пользователь (назовем ее Кэрол) не воспользуется сете вым анализатором и не просматривать трафик сети, пытаясь перехватить пароли. Совершенно что Алиса не сможет просто сказать Бобу установ ленный пароль (например, по телефону). Таким образом, Алисе что она знает пароль, не разглашая его.

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

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

В процессе обмена каждая из сторон подтверждает общего ключа, ЧАСТЬ 2 Безопасность в распределенных системах пользуя его для шифрования то. что другая сторона способна расшиф ровать и становится ее аутентичности.

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

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

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

1. Алиса передаст Бобу сообщение, содержащее ее имя открытым текстом и аутен зашифрованный общим секретным ключом. Согласно договоренно сти, данные в хранятся в структуре, состоящей из двух полей.

В первом поле находится информация о самой Алисе (для простоты Ч ее имя).

Второе поле содержит метку времени на рабочей станции Алисы.

2. Получив сообщение от отправителя, себя Алисой, Боб расшифро вывает общим ключом и оценивает штампа вре мени.

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

Если во находится в пределах допустимого сдвига, то вполне возможно, что аутентификатор прислала Алиса. Тем не менее существует вероят ность, что некто, просматривая сетевой трафик, перехватил попыт ку Алисы установить Бобом и воспроизвел ее со своего компьюте ра. Однако, проследив историю меток времени, заключенных в ГЛАВА 11 Проверка подлинности pax, присланных Алисой в течение последних пяти минут, Боб сможет обнару жить попытки воспроизвести предыдущие запросы и отвергнуть сообщения с мет ками времени более ранними или идентичными метке в последнем торе. Алиса признается автором сообщения только при условии, что метка време ни в аутентификаторе более поздняя, чем в 3. Боб зашифровывает метку времени из сообщения Алисы с помощью обшего ключа и отправляет сообщение обратно.

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

Выбор метки времени определяется его и тем, что он заведомо известен Алисе.

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

Описанная процедура проиллюстрирована на рис.

"Я метка Алиса времени!

Рис. 11-1. Простой протокол взаимной проверки подлинности Распространение ключей Однако остается неясным, как и откуда Алиса и Боб получили секретный ключ.

Люди могут где-нибудь встретиться и согласовать ключ. Но, если - выполняющаяся на рабочей станции, а Боб Ч служба, запу щенная на сетевом компьютере, такой способ подходит. Проблема может усу губляться что клиенту Алиса требуется много служб, для каждой из которых необходим свой ключ, а служба Боб взаимодействует со множеством для которых тоже нужны ключи. Распространение ключей в условиях, когда от каждо го клиента требуется наличие ключа для каждой службы и от каждой службы наличие ключа для каждого клиента, быстро становится трудноразрешимой зада чей. Кроме того, сложно обеспечить такого количества ключей, хранящихся на многочисленных компьютерах.

Название протокола указывает на то, как его средствами решается ма ключей. Согласно греческой мифологии, Kerberos (в русской транскрипции Ч это трехглавый охраняющий царство мертвых. По 494 ЧАСТЬ 2 Безопасность в распределенных системах мифологическому псу, одноименный протокол также может по хвастаться тремя головами - это клиент, сервер и доверенная третья вы полняющая роль посредника между первыми двумя. Такой доверенный посредник называется центром распространения ключей (Key KDC).

KDC - это служба, выполняющаяся на физически защищенном сервере. Она под базу данных, содержащую обо всех учетных записях всех участников безопасности в своей сфере (realm) - эквиваленте домена Windows применительно к протоколу Kerberos. Вместе с прочей информацией об участни ках безопасности хранит ключ, известный только участ нику безопасности и KDC. Этот ключ называется долгосрочным (long-term key) и используется для обмена данными между участником и В боль протокола Kerberos долгосрочный ключ создается на основа нии пользовательского пароля входа в систему.

Желая подключиться к серверу, отправляет запрос в KDC, и тот выдает обо им участникам безопасности уникальный ключ сеанса (session key), который сторо ны используют для взаимной проверки (рис. 11-2). Серверный ключа сеанса шифруется долговременным ключом сервера, а клиентский долговременным ключом клиента.

желает создает подключиться к серверу ключ Шля с обмена с сеанса Клиент использовать ключ ключ Сервер Рис. 11-2. Распространение ключей (в Теоретически может играть роль доверенного посредника, отправляя ключ сеанса каждому из участников безопасности так, как это изобра жено на рис. 11-2. Однако на практике реализовать процедуру чрезвы чайно так как серверу придется хранить ключ сеанса до момента ния запроса от клиента. Кроме того, серверу придется хранить ключи не только для данного, но и для всех остальных которые могут соединение.

Управление ключами в таком случае потребует ресурсов сервера, ог раничивая его масштабируемость. В связи с сетевого трафика запрос клиента иногда достигает сервера раньше, чем сообщение от с ключом В случае серверу отложить клиента до полу чения ответа KDC, а для Ч сохранить состояние соединения, что дополнительных ресурсов. Б Kerberos действует намного эффек Билеты сеансов В ответ на запрос клиента о создании с сервером служба отправ ляет ему обе копии ключа сеанса (рис. 11-3). Ключ клиента шифруется ключом, общим для КОС и клиента. Ключ сервера находится вместе с об торизации клиента в структуре именуемой билетом сеанса (session key) и ключом, общим для и сервера. Билет сеанса и заключенный в нем серверный ключ сеанса находятся в распоряжении клиента до момента его обращения к серверу.

ГЛАВА 11 Проверка подлинности Г, Клиент желает подключиться к ключ сеанса обмена с сервером ключ билет сеанса обмена с клиентом ключ Рис. 11-3, Распространение ключей (на практике) Обратите внимание, что KDC занимается только выдачей ключей, но не контроли рует их доставку клиенту. Возможность перехвата ключа не опаснос ти, так как только владелец ключа клиента сможет расшифровать ентский экземпляр ключа сеанса и только владельцу секретного ключа сервера уда стся прочитать билет сеанса.

Получив ответ от KDC, клиент билет сеанса и свой ключ сеанса и поме щает их в безопасный, невыгружаемый на диск кэш оперативной памяти. Когда доступ к серверу, он отправляет из биле та сеанса, зашифрованного секретным ключом и аутентификатора, рованного ключом сеанса (рис. 11-4). Билет сеанса и являются грамотами, которые клиент серверу.

билет сеанса = обмена с клиентом использовать ключ Клиент Сервер Рис. 11-4. Взаимная проверка подлинности клиента и сервера Получив от клиента эти данные, сервер своим ключом расшифровывает билет сеанса и извлекает него ключ сеанса, которым расшифровывает аутенти фикатор При успешном завершении всех операций получает под тверждение того, что верительные грамоты клиента центром безопасности Ч Если клиенту требуется взаимная проверка сервер шифрует ключом сеанса метку времени, извлеченную из аутентификатора клиента, и ее обратно так же, как Боб возвращал Алисе ную метку времени в примере, описанном ранее (см. рис. 11-1). Главное преимуще билетов сеанса Ч это отсутствие необходимости хранить ключи сеанса на сер вере. Теперь клиент сам отвечает за хранение билета сеанса в безопасном кэше и передачу его серверу. А серверу достаточно, получив от клиента билет сеанса, из влечь из него помощи своего секретного ключа ключ сеанса. По оконча нии сеанса сервер уничтожает ставший ненужным ключ.

Другое преимущество билетов сеанса заключается в том, что клиенту не ся обращаться к каждый раз, когда требуется подключиться к серверу. Биле ты разрешается использовать многократно. В качестве меры против возможной кражи билета применяется ограничение срока его действия, све дения о котором размещает в структуре данных билета. Срок действия та сеанса политикой Kerberos для Обычно билеты тельны восьми часов (средняя продолжительность сеанса работы в ме). При выходе пользователя из системы безопасный кэш очищается, и все ты и ключи сеанса уничтожаются.

496 ЧАСТЬ 2 в распределенных системах Билеты TGT Долгосрочный ключ создается на основе пароля. Например, когда Али са входит в систему, клиент рабочей станции принимает ее пароль и при помощи односторонней преобразует его в криптографический ключ.

извлекает долгосрочный ключ Алисы из базы данных учетных По лучив запрос от клиента Kerberos рабочей станции Алисы, находит в своей базе данных запись Алисы и из поля ее дол госрочный ключ.

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

КОС отвечает на запрос клиента, возвращая билет сеанса для работы с самим KDC.

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

Получив ответ из центра распространения ключей, клиент расшифровывает свой экземпляр ключа сеанса находящимся в кэше долговременным ключом пользова теля. После этого необходимость в долговременном ключе отпадает, и он уничто жается. Впоследствии для с KDC клиент использует ключ сеанса. Как и все ключи сеансов, этот ключ временный, он действует до окончания срока действия билета TGT или до выхода пользователя из системы, поэтому его называют ключом сеанса в системе (logon session С точки зрения клиента Ч это просто еще одна разновидность билета. Преж де чем отправить службе запрос на соединение, клиент проверяет наличие билета сеанса в своем безопасном кэше. Если его там клиент снова проверяет пытаясь найти в нем билет TGT. Если TGT отыскивается, клиент берет из кэша соответствующий ключ сеанса в системе, шифрует им свое и на правляет в сообщение, содержащее данный аутентификатор, и запрос билета для службы. Другими словами, процедура доступа к KDC ничем не отличается от процедуры к любой другой службе на, для нее требуется ключ сеанса, аутентификатор и билет (в данном случае TGT).

TGT сократить время, затрачиваемое на обработку за просов. только один раз выполняет поиск долговременного ключа клиента, после чего предоставляет ему TGT. В последующих соединениях с клиентом расшифровывает своим ключом, из него ключ се анса в и применяет его для расшифровки и проверки пользовательского Проверка подлинности между доменами Работу ключей две четко разделенные служ бы: служба проверки занимающаяся выдачей билетов TGT, и служба ГЛАВА 11 Проверка подлинности (ticket granting service), ответственная за выдачу билетов сеансов. раз деление обязанностей протоколу Kerberos простирать свое влияние за пределы отдельного домена. Клиент вправе билет в службе провер ки подлинности одного домена и им для получения билетов сеан са в службе TGS другого домена.

Чтобы пояснить, как проверяется подлинность между доменами, рассмотрим самый простой вариант Ч сеть, состоящую из двух доменов, например East и Если администраторы доменов работают в одной организации или по каким либо при требуется, чтобы пользователи одного домена имели право подключаться к ресурсам другого, администраторы могут разрешить доменами с общих междоменных ключей. (В Windows 2000 это происхо дит автоматически при установлении доверительных между доменами.) В этом случае служба TGS каждого из доменов будет зарегистрирована в качестве участника в другого домена. Это значит, что служба TGS каж дого из доменов рассматривает аналогичную службу другого домена как обычную службу, для доступа к которой клиенты, чья могут шивать и получать билеты сеансов.

Если пользователь домена East желает получить доступ к серверу в домене клиент Kerberos рабочей запросит билет сеанса у службы TGS своего домена. Служба домена East, обнаружив, что запрашиваемый вер является участником безопасности данного возвратит клиенту би лет (referral ticket), представляющий собой билет зашифро ванный междоменным ключом, общим для доменов East и Клиент ис пользует билет перенаправления в своем запросе, который на этот раз направляет службе TGS в домене сервера West. Служба домена West расшиф ровывает полученный билет своим междоменным ключом и, если расшифровка прошла успешно, высылает клиенту билет сеанса с сервером.

Процедура перенаправления более сложна в сетях, состоящих из трех и более до менов. Теоретически KDC каждого из доменов способен устанавливать прямые свя зи с KDC других в сети, создавая для каждой отдельный междо менный ключ. На практике такие связи, из-за их большого числа и сложности, по чти невозможно контролировать, особенно в условиях больших сетей, В протоколе Kerberos эта проблема - прямые связи в нем не нужны. Клиент мо жет получить билет сеанса с сервером другого домена, пройдя по цепи перенаправ лений через один или несколько промежуточных доменов.

В примера рассмотрим сеть из трех доменов: East, West и Допу стим, что у центров ключей East и West нет общего ключа, однако оба владеют общими ключами с CorpHQ. Цепь перенаправлений запроса пользователя из домена East к в домене West бе рет начало из центра ключей - East, далее проходит через промежуточный домен CorpHQ и в результате попадает в мена сервера (West). В примере, клиент трижды отправляет запрос билета сеанса, каждый раз различным 1. Клиент запрашивает билет сеанса с сервером в домене West у домена домена East возвращает клиенту билет к домена CorpHQ, общим междоменным ключом доменов East и CorpHQ.

498 ЧАСТЬ 2 Безопасность в системах 2, запрашивает билет сеанса с сервером в домене West у домена домена отсылает клиенту билет перенаправления к домена зашифрованный общим междоменным ключом доменов CorpHQ и 3. Клиент запрашивает билет сеанса с сервером в домене у домена домена West клиенту билет сеанса с сервером в West, В состав Kerberos входят три AS (Authentication Service Exchange - AS-обмен) КОС для отправки клиенту ключа сеанса в системе и билета TGS Exchange (Ticket-Granting Service Exchange Ч служит КОС для распространения ключей сеансов и билетов сеансов со службами и CS Exchange (Client/Server Exchange Ч CS-обмен) используется кли ентом для передачи билета сеанса соответствующей службе.

AS Exchange AS-обмен начинается, когда Алиса входит в сеть. вводит имя пользователя и пароль. Клиент Kerberos ее рабочей станции преобразует пароль в ключ шифрова ния и помещает его в кэш (credentials cache).

Клиент направляет запрос Kerberos (сообщение формата Kerberos Authen tication Service Request, службе проверки подлинности В первой части этого сообщения указывается имя пользователя (Алиса) и доступ к которой (служба TGS), как на рис. 11-5. Вторая часть сообщения содержит предварительную информацию для проверки подлин ности, она подтверждает, что Алиса знает пароль. Обычно это метка времени, за долгосрочным ключом хотя протокол допускает ние и другой информации для предварительной проверки.

КОС Алиса запрашивает службу TGS.

AS создает метка Алиса ключ сеанса обмена с TGS ключ Т6Т = Шля обмена с Алисой использовать ключ Рис. 11-5. AS Exchange запрос пользователя (Алису) в своей базе данных, извлекает его долгосрочный ключ, расшифровывает сообщение и проверя ет содержащуюся в нем метку времени. В случае успеха КОС может быть уверен в подлинности клиента, то что зашифровано долгосрочным ключом Алисы.

подтверждение подлинности Алисы, KDC создает реквизиты, которые клиент Kerberos ее рабочей станции может службе Б первую оче редь создает ключ сеанса и шифрует его долгосрочным ключом Алисы. Затем заключает второй ключа сеанса в системе в билет вместо с о самой Алисе (о ее авторизации), шифрует билет TGT соб ГЛАВА 11 Проверка подлинности долгосрочным ключом и, наконец, отправляет все эти документы обрат (сообщение формата Kerberos Authentication Service Reply, Получив ответ, клиент при помощи ключа, полученного из пароля Алисы, извлека ет ключ сеанса в и билет и сохраняет их в удостоверений.

TGS Exchange Для получения доступа к службе (например, к службе по имени Боб) Kerberos рабочей станции Алисы направляет сообщение-запрос (Kerberos Ticket-Granting как на рис. 11-6. Данное сооб содержит имя пользователя, аутентификатор, зашифрованный пользователь ским ключом сеанса в системе, билет TGT, в результате и имя службы, для которой запрашивается билет.

Алиса запрашивает службу Боб, метка времени].

с Алисой использовать ключ Алиса обмена с Бобом использовать ключ ключ обмена с Алисой ключ Рис. 11-6. TGS Exchange Получив центр распространения ключей билет собственным секретным ключом и извлекает из него принадлежащий Алисе ключ сеанса в системе. Затем этим ключом KDC расшифровывает и проверяет При результате проверки извлекает мацию об авторизации Алисы билета и создает общий ключ сеанса для кли ента (Алисы) и службы (Боба). Первый экземпляр этого ключа шифруется клю чом сеанса в системе а второй вместе с информацией об авторизации Али сы в билет, зашифрованный ключом Боба. Далее все документы отправляются обратно клиенту в сообщении-ответе (Kerberos Ticket-Granting Service Reply). Получив ответ (Алиса) рас шифровывает своим ключом сеанса в системе ключ со службой и записыва ет его в кэш удостоверений. Затем, он извлекает билет сеанса со службой и также сохраняет его в удостоверений.

CS Exchange Чтобы получить доступ к службе Боб, клиент Kerberos рабочей станции Алисы на правляет ей (Kerberos Application Request), как на рис. Указанное сообщение содержит ванный ключом сеанса со службой, билет, в результате TGS-обмена и флаг, указывающий, нужна ли клиенту взаимная проверка подлинности. (Прото кол Kerberos взаимную проверку подлинности, тем не является обязательной. Клиенты под управлением Windows 2000 всегда ют взаимной проверки подлинности. Клиенты, работающие с другими ми протокола, могут этого не делать.) 500 ЧАСТЬ 2 Безопасность в распределенных системах метка билет сеанса обмена с Алисой использовать ключ.

Алиса Рис. 11-7. CS Exchange Получив сообщение служба Боб расшифровывает билет, извлекает об авторизации Алисы и ключ сеанса, расшифровывает им аутенти Алисы, после чего проверяет содержащуюся в аутентификаторе метку вре мени. Если прошла успешно, Боб состояние флага взаимной проверки подлинности. Если флаг установлен, Боб шифрует метку времени из Алисы ключом сеанса и возвращает его клиенту в сообщении-от вете Application Reply).

Получив сообщение клиент на рабочей станции Алисы расшифро вывает Боба общим ключом сеанса и сравнивает службой метку времени с оригиналом. В случае совпадения клиент в подлинности службы и продолжает работу с пей. Во время соединения стороны могут шифровать данные приложений существующим ключом сеанса или поменять его и для этих целей другой ключ.

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

Содержание билета Сообщения и билеты Kerberos формируются в соответствии с установленной струк турой данных и форматом. Подробнее о полях билетов и флагах Ч на Web-страни це Web Resources по адресу: ссылка Request for Comments (RFC) и далее Ч ссылка RFC;

Ограничение срока действия билета средствами У билетов Kerberos есть начало и окончание срока Клиент, владеющий билетом сеанса с службой, имеет право предъявить его и получить доступ к службе в любой момент времени между началом и окончанием срока дей ствия билета независимо от того, сколько раз этот билет уже использовался. Что бы снизить риск компрометации билета или соответствующего ключа сеанса, ад министраторы могут устанавливать максимальный срок действия билета. Такой срок является элементом политики Kerberos в домене.

Клиент, запрашивающий у билет сеанса со службой, вправе опреде ленное время начала действия. Если это время в запросе опущено или уже прошло, заносит в поле начала действия билета текущее время.

Независимо от указывает ли клиент время начала действия или нет, в запросе должно быть обозначено время окончания действия билета. вы числяет поля окончания действия билета, прибавляя к значению 11 Проверка подлинности поля максимальный срок действия билета согласно действующей полити ки Kerberos. Затем он сравнивает результат со в и присваивает полю из двух Возобновляемые билеты Ключи шифрования со временем устаревают. Чем чаще используется ключ, тем больший объем данных, им зашифрованных, может быть и тем сильнее искушение взломать его испытывает Большинство ключей, ис пользуемых протоколом Kerberos, являются ключами сеансов. Клиенты ют для связи с сервером один и тот же ключ, пока действует билет сеанса. Когда срок действия билета истекает, клиент получает новый билет со свежим ключом сеанса, но до этого момента ключ не меняется.

Частая смена ключей Ч один из способов защитить их от потенциальных злоумыш ленников. Для этого специальным образом конфигурируется политика Kerberos, в частности устанавливается относительно короткий возможный срок действия билета. Другая стратегия заключается в разрешении обновления клю чей, то есть ключи сеанса могут периодически при этом не надо со здавать новый билет. Если Kerberos допускает возобнов ляемых билетов, устанавливает во всех выдаваемых билетах сеанса флаг RENEWABLE (возобновляемый) и создает в них две даты окончания срока дей ствия: первая срок действия до очередного обновления, а вторая -- общий срок действия Время окончания данного билета содержится в поле endtime. Как и в не билетах, в поле endtime указана сумма значений поля starttime и срока действия билета, установленного политикой Kerberos.

ент Ч владелец возобновляемого билета Ч должен предоставить его для об новления до окончания срока действия, указанного в endtime, предъявив вместе с ним новый Получив запрос на обновление билета сеанса, проверяет второе ограничение срока действия, заданное в поле Значение этого поля вычисляется при создании билета, как сумма поля starttime и общего срока действия билета, установленного политикой Kerberos. Прежде чем обновить KDC проверяет наступил ли срок, определенный в поле ill.

Если нет, билет получает поля endtime и новый ключ сеанса.

Из сказанного выше следует, что администраторы могут настроить политику Ker beros так, чтобы билеты сеансов обновлялись через относительно короткие жутки времени, например ежедневно. При обновлении билетов создастся новый ключ, что делает ных ключей. В то же время администраторы вправе устанавливать достаточно про должительный общий срок действия билетов (месяц, год и В конце периода билет сеанса становится недействительным и в не подлежит возобновлению.

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

Билеты сеансов служат только для проверки новых соединений.

ле установки не значения, действителен билет или нет. с тем, по истечении срока действия клиент Kerberos может прервать сеанс и запросить пароль.

502 ЧАСТЬ 2 Безопасность распределенных системах Центр ключей не клиентов о приближении окон чания срока действия билетов сеансов или TGT. На самом деле он не регистрирует свой обмен с клиентами за кратковременных записей, необходимых для того, чтобы предотвратить атаки с Клиент, предъявивший просроченный билет TGT службе TGS центра распростра нения билетов, в ответ получает сообщение об ошибке. Получив просроченный би лет, сетевые серверы также сообщают об ошибке. Вся ответственность за обновле ние или билетов возлагается на клиента.

Что клиентам известно о билетах Чтобы управлять своим кэшем удостоверений, клиенту необходимо знать часть ин формации, находящейся в билетах сеансов и TGT. Когда KDC в результате AS- или возвращает билет и ключ сеанса, клиентский ключ упаковывается в структуру данных, которая содержит информацию полей flags, и билета. Вся эта структура шифруется ключом и вращается ему в сообщениях-ответах KRB_AS_REP и Делегирование проверки подлинности Многоуровневые клиент-серверные приложения представляют собой особый слу чай протокола В приложениях такого рода клиент иногда подключается к серверу, который, в свою очередь, должен соединиться с другим сервером. Для этого первый сервер должен иметь билет сеанса со вторым сервером.

В идеале этот билет ограничивает доступ промежуточного сервера к вто рого сервера в с полномочиями клиента.

В Kerberos задача решается с механизма проверки линности of По существу, клиент перепоручает провер ку серверу-представителю, сообщая что тот Делегирование двумя способами. Во-первых, клиент сам билет сеанса с целевым сервером и передает его серверу-представителю. Билеты, которые получает клиент, а использует называются (proxy tickets). осложнено тем, что должен знать имя целевого сервера. Избежать этого позволяет второй способ: клиент жет передавать серверу-представителю билет последнему при запросе билета сеанса с целевым сервером. Билеты сеансов, посред ством TGT клиента, пересылаемыми билетами (forwarded Спо собность клиентов получать от KDC или пересылаемые билеты определяется параметрами политики Kerberos в домене.

Прокси-билеты При создании для клиента центр распространения ключей руководствуется политикой Kerberos в домене. Если выдача прокси-билетов разрешена, уста навливает в билете TGT флаг Чтобы получить клиент предъявляет TGT службе TGS и вает билет сеанса с целевым сервером. В запросе устанавливается флаг, свидетель ствующий, что запрашивается а также указывается имя сервера, ко торый будет представлять клиента. Получив такой запрос, создает билет се анса с целевым сервером, устанавливает в нем флаг PROXY и направляет билет ГЛАВА 11 Проверка подлинности клиенту. Клиент в свою очередь пересылает этот билет серверу-представителю, ко может воспользоваться им для получения доступа к целевому серверу.

Пересылаемые билеты Клиент, которому требуется делегировать определенному серверу право получения билетов с другим сервером, должен запросить у ключей TGT. Для этого клиент при передает в KDC имя который будет действовать от лица клиента. Если передача би летов разрешена политикой Kerbcros, KDC создает билет для сервера-пред ставителя, которым тот будет пользоваться от имени клиента, устанавливает в этом TGT флаг FORWARDABLE и направляет его клиенту. Затем клиент этот TGT серверу-представителю.

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

Компоненты Kerberos в Windows В Windows 2000 центр распространения как служба домена.

При этом KDC использует Active Directory в качестве базы данных учетных запи сей и получает дополнительную информацию об участниках безопасности из гло бального каталога.

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

Служба проверки подлинности (Authentication Service) выдает билеты для доступа к службе TGS домена. Прежде чем получить билеты со сетевым клиентам необходимо обзавестись TGT от службы проверки в домене, в котором зарегистрирована учетная запись Служба TGS выдает билеты для доступа к другим службам или к службе TGS до домена. Клиент, которому требуется получить доступ к службе, предъявить и запросить билет сеанса у службы домена, в котором нахо дится учетная запись службы. у которого пет билета TGT для службы удаленного домена, надо его получить, пройдя но цепочке направлений, начинающейся в службе пользователя и заканчивающей в TGS домена, где учетная запись запрашиваемой службы.

KDC, как и Active Directory, выполняется на каждом контроллере домена.

службы запускаются автоматически диспетчером локальной безопасности (LSA) контроллера домена и выполняются в пространстве процесса Ни одну из этих служб нельзя остановить. Доступность этих служб в Windows наличием в домене нескольких равноправных контроллеров, любой из которых спо собен обрабатывать запросы к службам проверки подлинности и службам TGS, на правленные в KDC В системах 2000 существует в соответствии с RFC 15! О имя участника безопасности krbtgt для центра распространения ключей. Учетная 504 ЧАСТЬ 2 Безопасность в распределенных системах запись создается автоматически вместе с новым доменом Windows 2000. Ее невозможно удалить или Учетной записи автоматически при сваивается который, как и пароли учетных записей доверия доменов, пери одически Пароль учетной используется при создании сек ретного ключа для шифрования и расшифровки билетов TGT, создаваемых цент ром распространения ключей. Пароль учетной записи доверия применяет ся при создании ключа Kerberos, для шифрования и расшифровки билетов (referral tickets).

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

База данных учетных записей КОС получает информацию об участниках безопасности из базы данных, которой является Active Directory домена. Каждый участник безопасности в Active Directory объектом учетной Криптографический ключ, применяемый в обмене с пользователем, компьютером или службой, хранится как атрибут объек та записи участника безопасности.

Серверами Active Directory могут быть только контроллеры домена. Каждый кон троллер домена хранит полную изменяемую копию каталога, поэтому создание учетных записей, паролей и членства в группах разрешается проводить на любом контроллере домена. любой из автоматически переда ются во все остальные реплики. Вместе с тем в Windows 2000 не токол репликации Kerberos (Kerberos replication protocol). Вместо него использует ся собственный протокол репликации с несколькими хозяевами, позволяющий реп лицировать хранилище информации Active Directory по безопасному каналу, созда ваемому между партнерами репликации.

Физическое хранение данных учетных записей управляется агентом системы ка талогов (directory system agent, Ч защищенным и интегрированным с LSA процессом на контроллере домена. Клиентам службы каталога не предоставляется прямой доступ к хранилищу данных. которому необходим доступ к инфор мации каталога, для к DSA должен воспользоваться одним из под держиваемых интерфейсов службы Active Directory (Active Directory Service средствами которого может проводить поиск, чтение или за пись объектов каталога и их атрибутов, Запросы на доступ к объекту или атрибуту в каталоге подлежат осуще ствляемой механизмами управления доступом Windows 2000. Подобно файлам и папкам в файловой системе объекты Directory списками доступом ACL), в которых указано, кто и как может получить доступ к объекту. В отличие от ACL файлов и папок списки управления объектов Active Directory или запрещают доступ не толь ко ко всему объекту, но и к отдельным его атрибутам. Таким образом, атрибуты, несущие секретную об учетных удается защитить стро гими разрешениями, чем прочие атрибуты объекта учетной записи.

Наиболее секретной информацией об учетной записи считается, конечно же, па роль. на то, что атрибут пароля объекта запись содержит не ГЛАВА 11 Проверка Предварительная проверка подлинности По умолчанию обязывает все записи предварительную проверку подлинности. Это значительно осложняет попытки подобрать с тем предварительную проверку подлинности разрешается отключать для записей, если это необходимо для совместимости с другими протокола. Чтобы отключить предварительную проверку сти, щелкните кнопкой объект пользователя в оснастке Active Directory Users and Computers (Active Directory - пользователи и компьютеры), в меню выберите Properties (Свойства), в диалоговом окне Properties (Свойства) перейдите на вкладку Account (Учетная запись) и установите флажок Do not require Kerberos (Без предварительной ности Поставщик поддержки безопасности Kerberos Протокол проверки подлинности Kerberos в виде поставщика жки безопасности (security support provider, SSP) Ч подключаемой (DLL), поставляемой с операционной системой. В Windows 2000 так же имеется поставщик поддержки для проверки подлинности по токолу NTLM. По умолчанию при загрузке системы на компьютере под управле нием Windows 2000 LSA загружает оба протокола (Kerberos и В Windows 2000 для проверки подлинности сетевого входа в систему и соединений и сервера можно применять любой из SSP. Выбор SSP зависит от по обмену, но если есть возможность выбо ра, используется Kerberos SSP.

Системные службы и приложения уровня получают доступ к постав щику поддержки через интерфейс (Microsoft Security Support Provider Interface). SSPI является Microsoft Win32. Он ет методы перечисления доступных SSP, выбор одного из них для прохождения проверки подлинности и аутентифицированного соединения. Эти методы представляют собой общие процедуры ящики), которые разра ботчики применяют, не вникая в детали конкретного протокола. Например, прове ряя подлинность во время соединения клиента и сервера, приложение с клиентской стороны направляет данные серверу через интерфейс SSPI с применением метода В случае Kerberos SSP метод фор мирует сообщение-запрос а сервер использует для ответа метод интерфейса SSPI, который формирует сообщение-от вет KRB_AP_REP. После проверки соединения LSA сервера ет информацию из клиентского билета сеанса для создания маркера доступа. На конец, сервер прикрепляет маркер доступа к потоку, данную службу, вызывая метод После того как LSA установит контекст пользователя, вы полняющийся в этом контексте, может еще один экземпляр Kerberos SSP для поддержки подписывания сообщений и шифрования.

Для проверки подлинности в доменах Windows 2000 все службы используют интерфейс SSPI. Таким образом, все службы домена Kerberos. Далее перечислены некоторые службы, осуществляющие под по протоколу Kerberos:

508 ЧАСТЬ 2 Безопасность в системах Х службы спулера печати;

Х удаленный доступ к файлам (Common Internet File System/Server Message Block);

Х запросы в Active Directory по протоколу Х управление файловой системой DFS и перенаправление;

Х межузловая проверка центров безопасности посредством (Internet Protocol Security);

Х запросы резервирования ресурсов для сетевой службы качества Х проверка подлинности в IIS;

Х удаленное управление серверами и рабочими станциями посредством удаленно го вызова процедур (RPC) с подлинности;

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

Кэш удостоверений Windows 2000 храпит билеты и ключи, от в кэше Ч области оперативной памяти, LSA. Доступ к этому кэшу имеют толь ко процессы, выполняющиеся в контексте безопасности LSA, и он никогда не выг ружается па диск. Все хранящиеся в объекты уничтожаются, когда участ ник безопасности выходит системы или система завершает работу.

Кэш удостоверений управляется SSP, выполняющимся в контексте безо пасности Всегда, когда требуется получить или обновить билеты и LSA для этой задачи вызывает Kerberos SSP.

Кроме того, в кэше удостоверений хранится экземпляр ключа локального пользо вателя, преобразованный из его пароля. Если срок действия ис текает во время сеанса в системе, Kerberos SSP применяет свой экземпляр преоб разованного из пароля ключа, чтобы получить новый не прерывая сеанса пользователя в системе. Преобразованный из пароля ключ не хранится на компью тере постоянно, его экземпляр разрушается при очистке кэша удостоверений.

С преобразованными из пароля ключами служб система обращается по-другому.

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

Обнаружение Прежде чем послать первый запрос проверки подлинности в домена пользо вателя, Kerberos найти контролер этого домена. Для этого предназна чен локатор контроллера домена. Подробнее о локаторе Ч в главе 1 Логическая Active Directory.

Локатор способен обнаруживать только доменов с Active Directory. Если ком пьютеры под управлением Windows 2000 участвуют в других сферах Kerberos, в клиентского компьютера должны быть записаны SSP протокола Kerberos находит в реестре сферы Kerberos пользователя и, сервер DNS, узнает его IP-адрес.

ГЛАВА 11 Проверка подлинности IP-транспорт Согласно RFC 1510, клиент, с KDC, должен отправить по IP-адресу распределения ключей в порт 88. В ответ посылает дейтаграмму на IP-адрес отправителя.

UDP (User Datagram Protocol) Ч это транспортный протокол без создания нения, используемый для предваряющего обмена сообщениями, не обходимого для принятия решения о возможности соединения. Этот протокол так же хорошо подходит для приложений, которым разовый обмен типа со общение Ч ответ, как, например, обмен между клиентом и KDC. работает лучше всего, когда дейтаграмма передается, как единое целое, то есть в одном кад ре. Максимально допустимая единица передачи (Maximum Transmission Unit, MTU) для Ethernet-кадров составляет октетов. Это значит, что если в качестве фи зической сети используется Ethernet, сообщения в виде могут содержать до 1500 октетов данных.

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

Сообщения, несущие билеты сеансов компьютерам под управлением Windows 2000, передаются при помощи протокола TCP, способного передавать большие объемы информации, чем Использование TCP-транспорта в Windows 2000 согласу ется с недавно к RFC 1510.

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

Отличия авторизации на основе имени и на основе идентификатора В некоторых операционных системах собственные меха низмы для определения уровня авторизации Зачастую для этого используются частные списки, содержащие пользователей, которым разре шен доступ. Например, многие приложения баз данных поддерживают специаль ные таблицы авторизации для доступом конкретных пользователей к просмотру или полей записей. механизм управления дос тупом можно объединить с проверкой подлинности Kerberos, задав, что бы билет в поле с данными содержал в какой-либо имя участника безопасности, К сожалению, механизмы авторизации так и остаются специ ализированными. базы данных не сможет воспрепятствовать 510 ЧАСТЬ 2 Безопасность в распределенных системах действиям другое приложение и при меняющего его для файла с данными. В Windows 2000 доступ к ресур сам контролируется самой системой. Приложения могут собственные механизмы авторизации, но в любом случае механизм управления до ступом операционной системы Windows 2000 защищает все файлы и ко торые разрешается использовать более чем одному процессу.

Заголовок каждого защищенного объекта дескриптор со списком управления доступом (access list, ACL). ACL поддерживается вла дельцем объекта, который решает, кто из участников безопасности может получать к объекту и каким образом. Операционная система обеспечивает ние указаний всякий раз проверяя права доступа, когда приложение за описатель защищенного объекта. Прежде чем возвратить описатель, опе рационная система проверяет ACL объекта, выясняя, есть ли у участника безопас ности, в чьем контексте исполняется приложение, доступ к запраши объекту. Если участник безопасности не такого права, приложению в доступе отказывается.

Еще важное отличие данного механизма управления доступом заключается в том, что ни операционная система, ни ACL не идентифицируют участников инфор мации по Вместо этого каждому участнику информации назначается (security identifier, SID) - буквенно-цифро вое выражение, структура которого напоминает телефонный номер. Подобно на цифрам телефонного номера, обозначающим код страны, первая часть SID обозначает домен, в котором он был создан, а вторая часть, ука зывающая на учетную запись в этом аналогична местному номеру. Домен ная часть уникальна в пределах предприятия, а значение второй части учет ной записи Ч уникально в домене. В отличие от номеров телефонов никогда применяется нельзя присвоить SID, который уже ког да-то принадлежал другому пользователю.

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

Pages: | 1 | ... | 7 | 8 | 9 | 10 | 11 | ... | 15 |

Книги, научные публикации

Blog

Distributed Systems Guide Microsoft 2000 Server Microsoft Press Распределенные системы Книга 1 2000 Server Москва 2001 Я fl I (I Г К I P УДК 004 ББК 32.973.26-018,2 М59 Microsoft ...