Административные привилегии

Административные разрешения являются специфическими для объектов Active Directory и определяют, какие действия администратор может выполнять с этими объектами. Разрешения, которые обсуждались до сих пор, основаны на списках ACL, приложенных к каждому объекту Active Directory. Пользовательские привилегии отличаются тем, что они применяются к учетным записям пользователя. Пользовательские привилегии пользователь получает за то, кем он является, а не за то, что он имеет разрешения изменять специфический объект Active Directory. Например, есть два способа дать пользователю (или группе) право добавлять рабочие станции к домену. Один способ состоит в том, чтобы дать пользователю (или группе) разрешение Create Computer Objects (Создание компьютерных объектов) на уровне OU или контейнера Computers (Компьютеры). Это позволит пользователю добавить необходимое количество рабочих станций к домену в указанном контейнере.

Другой способ состоит в том, чтобы дать пользователю привилегию добавления компьютеров к домену. Она является частью политики Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Любой пользователь, имеющий эту привилегию, может добавить к домену до десяти рабочих станций. По умолчанию это разрешение предоставляется группе Domain Users (Пользователи домена).

Административные разрешения

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

Чтобы создать новый корневой домен леса, вы должны войти в систему с правами локального администратора, но сетевые сертификаты для этого не нужны. Если вы собираетесь создать новый корневой домен дерева или новый дочерний домен в существующем дереве, необходим сетевой сертификат для установки домена. Чтобы создать новый корневой домен дерева, вы должны предъявить сертификат учетной записи члена группы Enterprise Admins (Администраторы предприятия). Чтобы установить дополнительный контроллер домена в существующий домен, вы должны предъявить сертификаты, которые имеют разрешения присоединять компьютер к домену и создавать объект NTDS Setting (Параметры настройки NTDS) в разделе конфигурации каталога. Глобальная группа Domain Admins (Администраторы домена) имеет такой уровень разрешений.

Административные шаблоны

Одна из наиболее мощных опций, предназначенных для управления рабочими столами пользователей с помощью групповых политик, состоит в использовании административных шаблонов. Административные шаблоны применяются для конфигурирования параметров настройки системного реестра на компьютерах с системами Windows 2000 Server, Windows 2000 Professional, Windows XP Professional или Windows Server 2003. Административные шаблоны могут использоваться для конфигурирования большого количества разнообразных параметров настройки, которых существует более 700. Их так много, что этот раздел, возможно, не сможет охватить их все. В таблице 13-7 приводится краткий обзор только нескольких административных шаблонов, чтобы вы почувствовали силу групповых политик. Административные шаблоны имеются также и в Active Directory Windows 2000, но в Windows Server 2003 добавлено около 150 новых параметров настройки. В таблице 13-7 перечисляются также некоторые новые функции, которые доступны в Active Directory Windows Server 2003 клиентам с Windows XP Professional.

Табл. 13-7. Образец административных шаблонов

Место расположения административного шаблона		Пояснение
Computer Conf iguration\ Administrative Templates\ System\Net Logon		Обеспечивает разнообразные параметры настройки, управляющие местом расположения клиентского компьютера и кэшированием записей DNS контроллера домена.
Computer Configuration\ Administrative Templates\ System\Remote Assistance		Обеспечивает параметры настройки для функции Remote Assistance (Удаленная помощь), имеющейся в системе Windows ХР Professional.
Computer Conf iguration\ Administrative Templates\ Windows Components\ Terminal Services		Обеспечивает параметры настройки, которые могут использоваться для конфигурирования служб терминала Terminal Services на сервере и на клиентах.
User Conf iguration\ Administrative Templates\ Network\Network Connections		Обеспечивает конфигурирование параметров настройки, предназначенных для управления сетевыми связями, и ограничения доступа пользователей к сетевым подключениям.
User Conf iguration\ Admin istrative Templates\Control Panel User Conf iguration\ Administrative Templates\ Windows Components\ Internet Explorer		Обеспечивает конфигурацию частей панели управления и возможности пользователей по изменению параметров настройки через панель управления. Обеспечивает разнообразные параметры настройки, предназначенные для управления конфигурацией приложения Internet Explorer. Требуется Internet Explorer версии 5.01 или более поздней.

<
Дополнительная информация. Полный список всех параметров настройки групповых политик смотрите по адресу http:// www.microsoft.com/windowsxp/prdytechinfo/administration/ policy /winxpgpset.xls.

Одно из усовершенствований Active Directory Windows Server 2003 — это улучшенная справка по административным шаблонам. Теперь Active Directory поставляется с полным набором справочных файлов, детализирующих каждую подборку административных шаблонов. Чтобы получить доступ к расширенной справке по административным шаблонам, щелкните правой кнопкой мыши на папке Administrative Templates в редакторе объектов групповой политики и выберите Help (Справка). Затем выберите подходящую категорию административного шаблона. На рисунке 13-10 показаны детали, касающиеся категории System (Система).

Системные политики в Windows NT обеспечивают функциональные возможности, подобные функциональности административных шаблонов в Active Directory Windows Server 2003. Оба инструмента позволяют делать изменения системного реестра в системе клиентов для модификации конфигурации рабочей станции. Однако административные шаблоны обеспечивают существенные преимущества по сравнению с системными политиками. Одно из самых больших преимуществ состоит в том, что они не оставляют неудаляемых следов в системном реестре, как это делают системные политики. Когда вы делаете изменение, используя системную политику, оно записывается в системный реестр, и для того чтобы изменить эту установку снова, надо делать это вручную или использовать системную политику. Если вы удалите системную политику, изменения, сделанные к системному реестру, не будут удалены.

В Active Directory изменения системного реестра, сделанные административными шаблонами, записываются в специальные подключи в системном реестре. Любые изменения, сделанные в разделе User Configuration, записываются в ключе HKEY_CURRENT_USER и сохраняются в папке \Software\Policies или \Software\Microsoft\Windows\CurrentVersion\Policies. Изменения, сделанные в разделе Computer Configuration, сохраняются под теми же самыми подключами в ключе НКЕY_LOCAL_MACHINE. При начальной загрузке компьютера или при входе пользователей в систему загружаются обычные параметры настройки системного реестра, а затем эти ключи исследуются на наличие дополнительных параметров настройки. Если эти параметры будут найдены, то они загрузятся в системный реестр, записываясь поверх существующих записей, если такие записи имеются. Если административный шаблон удален, или компьютер (пользователь) будет перемещен в другой контейнер, где данный шаблон не применяется, информация в ключах Policies удаляется. Это означает, что административные шаблоны больше не применяются, но обычные параметры настройки системного реестра будут применяться.





Рис. 13-10. В Центре справки и поддержки имеется детальное описание каждой опции административного шаблона

Административные шаблоны хранятся в нескольких текстовых файлах .adm. По умолчанию эти файлы расположены в папке %systemroot %\Inf . В таблице 13-8 перечислены файлы административных шаблонов, которые по умолчанию устанавливаются с системой Windows Server 2003.

Табл. 13-8. Заданные по умолчанию шаблоны, загружаемые в систему Windows Server 2003

Административный шаблон	Параметры настройки конфигурации
System.adm	Системные параметры настройки.
Inetres.adm	Параметры настройки приложения Internet Explorer.
Wmplayer.adm	Параметры настройки приложения Microsoft Windows Media Player.
Conf.adm	Параметры настройки приложения Microsoft NetMeeting.
Wuau.adm	Параметры настройки Windows Update.

Файлы административных шаблонов состоят из записей, определяющих опции, которые доступны через данный шаблон. Каждая запись в файле .adm выглядит так как показано на рисунке 13-11. В таблице 13-9 поясняются записи, относящиеся к шаблону.



Рис. 13-11. Одна из записей в файле System.adm

Административные шаблоны для каждой групповой политики хранятся в папке Sysvol, расположенной на контроллере домена, и реплицируются на все другие контроллеры домена в домене. Шаблоны хранятся в файле Registry.pol, расположенном в папке %systemroot%\ SYSVOL\ sysvol\ domainname\ Policies\ GroupPolicyGUID\ Machine для компьютерной конфигурации и в папке %systemroot%\ SYSVOL\ sysvol\ domainname\ Policies\ GroupPolicyGUID\ User для пользовательской конфигурации.

Табл. 13-9. Компоненты опции шаблона

Компонент шаблона	Объяснение
Policy (Политика) Keyname (Ключ)	Идентифицирует название политики. Идентифицирует ключ системного реестра, который изменяется с помощью этой установки.
Компонент шаблона	Объяснение
Supported (Поддержанный)	Идентифицирует поддерживаемые рабочие станции или версии программного обеспечения, необходимые для этой установки. Включают поддержку Windows XP Professional, Windows 2000 или Windows 2000 с сервисным пакетом, Microsoft Windows Media Player, версия 9.
Explain (Объяснение)	Идентифицирует текст, который объясняет параметры настройки политики. Фактический текст дан ниже в файле .adm.
Part (Часть)	Идентифицирует записи, которые можно сконфигурировать для этой политики.
Valuename (^Значение)	Идентифицирует значение системного реестра, которое будет заполнено информацией из этого параметра настройки.

<


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

Система Windows 2000 содержала первый

Система Windows 2000 содержала первый выпуск Active Directory, и многие из средств администрирования, которые поставлялись с Windows 2000, имели ограничения в некоторых важных аспектах. Средства администрирования Windows Server 2003 обеспечивают усовершенствованные функциональные возможности.

Функциональность Drag and drop. Наиболее популярной новой функцией Active Directory Windows Server 2003 является перетаскивание объектов в пределах инструментов администрирования Active Directory. Теперь вы можете перемещать пользователя из одной OU в другую путем перетаскивания значка учетной записи пользователя. Вы можете добавить существующего пользователя к группе перемещением значка учетной записи пользователя в учетную запись группы.

Одновременное редактирование нескольких элементов. Еще одна новая функция — возможность редактировать несколько объектов одновременно. В Active Directory Windows 2000 вы можете изменять только один объект за раз. С помощью инструмента администрирования Active Directory Users And Computers Windows Server 2003 можно изменять одновременно большое число объектов. Предположим, что все пользователи отдела Marketing (Маркетинг) переезжают в другое офисное здание, и вы должны заменить адрес для всех учетных записей пользователей. Используйте средство поиска, чтобы найти учетные записи пользователей, у которых атрибут Department установлен на значение Marketing. Затем выделите все учетные записи в окне результатов поиска, щелкните на них правой кнопкой мыши и выберите Properties (Свойства). Теперь вы можете изменять общие атрибуты для всех учетных записей одновременно. Ваш домен должен работать на функциональном уровне Windows Server 2003, чтобы позволить одновременное редактирование нескольких элементов.

Сохранение запросов. В больших организациях с тысячами пользователей администраторы всегда находят объекты Active Directory с помощью поиска, а не просмотра. Опция сохранения запросов означает, что вы можете однажды создать запрос на поиск, а затем сохранить его для повторного использования в другое время. Возможно, вы захотите выполнять ежемесячную проверку, чтобы узнать, какие учетные записи пользователя не использовались для входа в домен в последние 30 дней. Щелкните правой кнопкой мыши на контейнере Saved Query (Сохраненные запросы) и выберите New (Новый)><Querу (Запрос), чтобы создать запрос для поиска этой информации, а затем один раз в месяц просто щелкните на запросе, чтобы увидеть самый последний список.

Инструменты командной строки Active Directory Windows Server 2003 включают множество новых средств, предназначенных для управления объектами Active Directory: утилиты Dsadd и Dsmod (для добавления или изменения объектов Active Directory соответственно), Dsrm (для удаления объектов Active Directory), Dsmove (для перемещения объектов из одного контейнера в другой), Dsquery (для поиска списка объектов) и Dsget (для отображения атрибутов объекта). Смотрите Help And Support Center (Центр справки и поддержки) для получения детальной информации о том, как использовать эти инструменты.

Администрирование объектов групповой политики

Как только объект GPO создан, вы можете изменять его конфигурацию. Большинство этих модификаций будет осуществляться на вкладке Group Policy окна Properties (Свойства) контейнерного объекта, с которым связан объект GPO (см. рис. 11-4). В таблице 11-3 объясняются опции конфигурации, доступные в этом окне.

Рис. 11-6. Создание нового GPO-объекта загружает заданные по умолчанию параметры настройки групповой политики

Табл. 11 -3. Конфигурирование параметров настройки GPO

Опция интерфейса		Пояснение
Add (Добавить)		Используется для связи предварительно созданного объекта GPO с контейнерным объектом. Когда вы щелкнете на кнопке Add, появится окно, подобное окну на рисунке 11*5. Вы можете найти любой объект GPO в вашей организации и связать его с этим контейнером.
Edit (Редактирование)		Используется для модификации опций конфигурации объекта GPO, изменяя содержание GPO. Когда вы щелкнете на кнопке Edit, появится соответствующее окно (см. рис. 11-6).
Options (Опции)		Используется для конфигурирования опции No Override (He подменять) и для отключения объекта GPO. Они будут подробно обсуждаться в разделе «Наследование групповой политики и применение» далее в этой главе.
Опция интерфейса		Пояснение
Delete (Удалить)		Используется для удаления объекта GP При выборе этой опции вы можете или по ностью удалить GPO из Active Directory, и. удалить только связи с данным контейне ным объектом.
Properties (Свойства)		Используется для конфигурирования то] применяется ли этот объект GPO к компы терам и пользователям или к обоим. Кро: того, используется для конфигурирован: опций защиты объекта GPO. Эти опции ко фигурирования будут подробно обсуждать в разделе «Фильтрация применения групп вой политики» далее в этой главе.

Аудит использования административных разрешений

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

Включение аудита изменений, сделанных для объектов Active Directory, состоит из двух шагов. Первый шаг состоит во включении аудита на уровне OU Domain Controllers (Контроллеры домена). Это делается с помощью инструмента администрирования Domain Controller Security Policy (Политика безопасности контроллера домена). На консоли Microsoft Management Console (ММС) выберите оснастку File>Add/ Remove (Файл>Добавление/Удаление), щелкните на кнопке Add (Добавить), а затем добавьте Group Policy Object Editor (Редактор объектов групповой политики). В Group Policy Wizard (Мастер групповой политики), щелкните на кнопке Browse (Просмотр), затем трижды щелкните на Domain Controllers.domainname.com (где domainname — имя домена, в котором вы включаете аудит). На рисунке 9-9 показана заданная по умолчанию конфигурация аудита в Active Directory Windows Server 2003.

Рис. 9-9. Конфигурирование аудита в организационных единицах Default Domain Controllers

Если нужно производить аудит изменений для объектов Active Directory, вы должны гарантировать, что включена функция Audit Account Management (Аудит управления учетными записями). В этом случае все модификации, сделанные для объектов Active Directory, могут быть проверены. Вы можете делать аудит успешных изменений к Active Directory, а также неудавшихся попыток изменения Active Directory.

По умолчанию служба Active Directory Windows Server 2003 сконфигурирована для проведения аудита всех успешных действий по управлению учетными записями.

Разрешение аудита на уровне OU контроллера домена является первым шагом в предоставлении аудита. Это дает возможность сконфигурировать аудит для реальных объектов, расположенных в пределах данного домена. Чтобы разрешить аудит объекта Active Directory, обратитесь к окну Properties (Свойства) этого объекта через соответствующий инструмент Active Directory. Затем выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно) и выберите вкладку Auditing (Аудит). На рисунке 9-10 показано окно инструмента Active Directory Users And Computers и заданная по умолчанию установка для аудита OU в Active Directory.



Рис. 9-10. Конфигурирование аудита объектов Active Directory

Чтобы добавить больше записей для аудита, щелкните на кнопке Add (Добавить) и выберите пользователей или группы, действия которых вы хотите контролировать. В большинстве случаев вы должны выбрать группу Everyone, чтобы модификации, сделанные любым пользователем, подвергались аудиту. Затем вы можете выбрать, какие действия вы хотите подвергать аудиту. Вы можете делать аудит всех модификаций, сделанных для любого объекта в контейнере, для определенного типа объектов или для определенных свойств объектов. Вы можете допустить аудит всех успешных модификаций, всех неудавшихся попыток модификации или оба варианта. Если вы включите аудит всех успешных модификаций, вы будете отслеживать все изменения, сделанные к каталогу. Если вы включите аудит неудавшихся попыток модификаций, вы сможете контролировать любые незаконные попытки изменить информацию каталога. Как только аудит включен, все контрольные события записываются в файле регистрации Security, доступном через инструмент Event Viewer (Средство просмотра событий).

Разрешение аудита делается просто. Управлять аудитом гораздо сложнее. Если вы разрешаете аудит всех модификаций каталога на уровне OU контроллера домена, то файл регистрации Security будет расти очень быстро. Почти все события будут законными изменениями, и не будут представлять для вас никакого интереса, кроме как отслеживание событий. Однако среди законных изменений может быть разбросано несколько изменений, о которых вы должны знать. Проблема состоит в том, чтобы среди большого количества обычных событий найти несколько интересных контрольных событий. В некоторых компаниях одному администратору каждый день поручают просмотр зарегистрированных событий. Наилучший способ справиться с этой проблемой состоит в том, чтобы создать некоторый автоматизированный способ анализа файлов регистрации событий. Другой путь состоит в использовании инструмента Microsoft Operations Manager (Менеджер операций) (отдельно продаваемый продукт) для фильтрации событий и вынесения предупреждений только в случае интересных событий.

Дополнительная информация. Если вы хотите больше узнать о продукте Microsoft Operations Manager (MOM), посетите веб-сайт http://www.microsoft.com/mom. MOM обеспечивает большое количество функциональных возможностей, которые выходят далеко за пределы проблемы контроля журналов безопасности.

Аутентификация

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

Аутентификация происходит перед входом клиента в систему. Когда пользователь садится за компьютер с системами Windows 2000 или Microsoft Windows XP Professional и вводит Ctrl+Alt+Del, служба Winlogon локального компьютера переключается на экран входа в систему и загружает файл Graphic Identification and Authentication (GINA) (Графическая идентификация и аутентификация) из библиотеки динамической компоновки (DLL). По умолчанию этот файл — Msgina.dll. Однако сторонние производители могут создавать альтернативные файлы GINA (например, клиент системы Netware использует файл Nwgina.dll). После того как пользователь впечатал имя пользователя, пароль и выбрал домен, GINA передает введенные «верительные грамоты» службе Winlogon. Winlogon передает информацию локальной службе безопасности LSA (Local Security Authority). Служба LSA немедленно применяет к паролю пользователя операцию одностороннего кэширования и удаляет понятный текстовый пароль, который пользователь напечатал. Затем вызывается соответствующий провайдер защиты (SSP — Security Support Provider) через интерфейс провайдеров защиты (SSPI - Security Support Provider Interface). Windows Server 2003 обеспечивает двух основных SSP-провайдеров для сетевой аутентификации — KerbeVos SSP и NT LAN Manager (NTLM) SSP. Если клиенты с системой Windows 2000, или более поздней, входят в сеть системы Windows 2000 или Windows Server 2003, выбирается SSP Kerberos, и информация передается SSP. Затем SSP связывается с контроллером домена для подтверждения подлинности пользователя. Опознавательный процесс с использованием протокола Kerberos будет описан далее в этой главе.

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

Аутентификация на базе протокола Kerberos

На компьютерах с системой Microsoft Windows 2000 Professional или Windows XP Professional, на серверах с Windows 2000 Server или Windows Server 2003 аутентификация по протоколу Kerberos начинается с того, что служба LSA вызывает провайдера защиты Kerberos. Когда пользователь входит в систему, впечатывая имя пользователя и пароль, компьютер клиента применяет одностороннее хэширование к паролю пользователя для создания секретного ключа, который кэшируется в надежной памяти на компьютере. Одностороннее хэширование означает, что пароль не может быть восстановлен исходя из хэш-значения (hash).

Для осуществления процесса входа клиента в систему клиент и сервер выполняют следующие действия.

Провайдер Kerberos SSP на рабочей станции посылает опознавательное сообщение службе KDC (см. рис. 8-1). Это сообщение включает: •   имя пользователя;

область (realm) пользователя (имя домена);

запрос на TGT-билет;

предварительные опознавательные данные, которые включают метку времени.

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

Рис. 8-1. Получение билета Kerberos TGT

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

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

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

Примечание. Протокол Kerberos включает в себя Authentication Service (AS) Exchange (Коммутатор аутентификационной службы), который является подпротоколом, предназначенным для выполнения начальной аутентификации пользователя. Только что описанный процесс использует подпротокол AS Exchange. Начальное сообщение, посланное клиентом к центру KDC, называется сообщением KRB_AS_REQ. Ответ сервера клиенту называется сообщением KRB_AS_REP.             *•

Пользователь был опознан, но он все еще не имеет никакого доступа к сетевым ресурсам. TGT - это билет сеанса, который предоставляет доступ к центру KDC, но чтобы получить доступ к каким-либо другим сетевым ресурсам, пользователь должен получить другой билет сеанса от KDC центра (см. рис. 8-2.) Рабочая станция клиента посылает запрос на билет сеанса к центру KDC. Запрос включает имя пользователя, билет TGT, предоставленный в процессе аутентификации, имя сетевой службы, к которой пользователь хочет получить доступ, и временную метку, которая зашифрована с использованием ключа сеанса, полученного в процессе AS Exchange.





Рис. 8-2. Получение билета сеанса Kerberos для сетевого ресурса

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

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

Рабочая станция клиента кэширует обе части билета сеанса в памяти.

Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса, посланный клиентом, называется сообщением KRB_TGS_REQ; ответ сервера - сообщением KRB_TGS_REP.

Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис. 8-3.)



Рис. 8-3. Доступ к сетевой службе

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

Примечание. Процесс, описанный в шагах 9 и 10, использует под-протокол Client/Server (CS) Exchange. Запрос клиента называется сообщением KRB_AP_REQ.



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

Дополнительная информация. Вы можете посмотреть содержимое кэша клиента, используя инструменты, доступные для загрузки на веб-сайте Microsoft. Инструмент KList.exe предоставляет интерфейс командной строки для просмотра и удаления билетов Kerberos. Инструмент Kerberos Tray (Kerbtray.exe) обеспечивает для просмотра билетов графический интерфейс пользователя (GUI). На рисунке 8-4 показан пример информации, предоставленной инструментом Kerberos Tray. Инструмент Kerberos Tray доступен по адресу http://www.microsoft.com/ windows2000/techinjo/reskit/tools/existing/kerbtray-o.asp , а инструмент KList доступен по адресу http://www.microsoft.co7n/windows2000/techinfo/reskit/tools/ existing /klist-o. asp.



Рис. 8-4. Просмотр билетов Kerberos с помощью инструмента Kerberos Tray

Процесс получения доступа к сетевому ресурсу показывает, что центр KDC вовлечен только в процесс начального входа в систему клиента, когда клиент первый раз пробует обращаться к ресурсу, расположенному на определенном сервере. Когда пользователь впервые входит в систему, ему выдается билет TGT, который предоставляет клиенту доступ к центру KDC в течение срока службы билета. Когда клиент пробует соединиться с сетевым ресурсом, он снова входит в контакт с KDC и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный пользователь.

Аутентификация, пересекающая границы домена

Тот же самый опознавательный процесс применяется и в том случае, когда при подтверждении подлинности пользователя пересекаются границы домена. Например, компания может иметь лес с тремя доменами, как показано на рисунке 8-5.

Рис. 8-5. Аутентификация, пересекающая границы домена

Если пользователь, имеющий учетную записью в домене Fabrikam.com, перейдет в домен NAmerica.Contoso.com и попытается войти в сеть, рабочая станция клиента сможет соединиться с контроллером домена в домене Fabrikam.com. В этом случае компьютер клиента посылает начальный запрос входа в систему на контроллер домена NAmerica.Contoso.com. Контроллер домена определяет, что учетная запись пользователя расположена в домене Fabrikam.com, так что нужно переправить запросы рабочей станции клиента к этому домену. Если все домены были сконфигурированы с прямыми доверительными отношениями (shortcut trusts), то контроллер домена может напрямую направить компьютер клиента к контроллеру домена в домене Fabrikam.com. Однако если прямых доверительных отношений не было создано, то нет и прямого доверительного отношения между доменами NAmerica.Contoso.com и Fabrikam.com. В этом случае контроллер домена NAmerica направит компьютер клиента к контроллеру домена в домене Contoso.com. Направление включает ключ сеанса, предоставляющий доступ к контроллеру домена в домене Contoso.com. Ключ сеанса создается, когда домен NAmerica добавляется к лесу Contoso.com и создаются начальные доверительные отношения между этими двумя доменами. Ключ сеанса гарантирует, что запрос на вход в систему исходит от доверенного домена. Затем компьютер клиента посылает опознавательный запрос к домену Contoso.com. Теперь клиент направляется к контроллеру домена в домене Fabrikam.com. Снова это направление включает ключ сеанса, необходимый для доступа к контроллеру домена. Далее компьютер клиента посылает запрос TGT на свой домашний контроллер домена в Fabrikam.com.

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

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

Автоматическое удаление Active Directory

Удаление Active Directory может происходить в автоматическом режиме, подобно автоматической инсталляции. Для этого используется командная строка. Единственное различие — содержание файла ответов.

Чтобы выполнить автоматическое удаление Active Directory, в командной строке или в диалоговом окне Run, напечатайте dcpromo/ answer:answer file (где answerfile — имя файла ответов, который вы создадите). Файл ответов содержит значения ключей, которые рассматривались выше. Важнейший ключ — IsLastDCInDomain —.может иметь значение Yes (Да) или No (Нет). Если вы устанавливаете значение этого ключа на Yes, то тем самым указываете, что удаляете Active Directory из последнего контроллера домена в домене и сам домен тоже будет удален. Типовой файл ответов, предназначенный для удаления дополнительного контроллера домена, показан ниже:

[Deinstall]

RebootOnSuccess=Yes

lsLastDCInDomain=No

AdministratorPassword=passivord

Passwo rd =password

UserName=Administrator

Автоматизированное восстановление системы

Один из вариантов резервирования и восстановления в Windows Server 2003 - это автоматизированное восстановление системы (Automated System Recovery - ASR). Эта опция упрощает процесс восстановления данных состояния системы. Прежде чем вы будете использовать ASR, создайте ASR-копию, т.е. помощью инструмента Backup сделайте резервную копию данных состояния системы и создайте загрузочный диск ASR. Загрузочный диск содержит файлы, необходимые для загрузки сервера, а также информацию о конфигурации жесткого диска на сервере и резервную копию состояния системы. Если сервер выйдет из строя, эта ASR-копия может использоваться для частичной автоматизации восстановления сервера.

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

Чтобы сделать восстановление без полномочий, выполните следующие действия.

Восстановите отказавший контроллер домена и повторно установите на сервере систему Windows Server 2003. После восстановления сер-

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

Выберите загрузку контроллера домена в режиме восстановления службы каталога Directory Services Restore Mode (Windows Domain Controllers Only) (Только контроллеры домена с системой Windows)). После этого контроллер домена загрузится в безопасном режиме, но не будут загружены компоненты Active Directory.

Выберите операционную систему, которую вы хотите запустить.

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

Испсшьзуйте программку создания резервной копии и восстановления системы, чтобы восстановить данные System State (Состояние системы) на сервере.

После восстановления данных перезагрузите контроллер домена.

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

Примечание. Восстанавливать информацию Active Directory могут только локальные администраторы. Эта учетная запись создается при инсталляции Active Directory на контроллере домена. Пароль для нее конфигурируется в это же время. Пароль может быть переустановлен только через утилиту Ntdsutil.

Автономная дефрагментация базы данных Active Directory

Как говорилось выше, процесс онлайновой дефрагментации не может сократить размер базы данных Active Directory. При нормальных обстоятельствах это не является проблемой, потому что страницы базы данных, которые очищены в процессе онлайновой дефрагментации, просто снова используются по мере добавления новых объектов к Active Directory. Однако, в некоторых случаях, можно использовать автономную дефрагмен-тацию для сокращения полного размера базы данных. Например, если вы удаляете GC-каталог из контроллера домена, нужно выполнить автономную дефрагментацию в базе данных, чтобы очистить место, которое ис-пользовалось в базе данных для хранения информации GC. Потребность в автономной дефрагментации существует в среде, состоящей из нескольких доменов, где GC каталог может стать очень большим.

Чтобы выполнить автономную дефрагментацию, выполните следующие шаги.

Сделайте резервную копию информации Active Directory на контроллер домена (см. гл. 15).

Перезагрузите контроллер домена. Во время загрузки сервера нажмите клавишу F8, чтобы отобразить меню дополнительных параметров Windows. Выберите режим Directory Services Restore (Восстановление службы каталога) (Только для контроллеров домена с системой Windows).

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

Откройте командную строку и напечатайте ntdsutil.

В командной строке утилиты Ntdsutil напечатайте files.

В командной строке утилиты File Maintenance (Обслуживание файлов) напечатайте info. Эта опция отображает текущую информацию о пути и размере базы данных Active Directory и ее журналов.

Напечатайте compact to drive:\directory. Выберите диск и каталог, которые имеют достаточно места для хранения всей базы данных. Если название пути каталога содержит пробелы, путь должен быть заключен в кавычки.

Процесс автономной дефрагментации создает новую базу данных по имени Ntds.dit в указанном вами месте. По мере копирования базы данных в новое место она дефрагментируется.

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

Скопируйте дефрагментированный файл Ntds.dit поверх старого файла Ntds.dit в место расположения базы данных Active Directory.

Перезагрузите контроллер домена.

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

Безопасность протокола NTLM

Второй вариант аутентификации на контроллере домена Windows Server 2003 должен использовать NTLM-аутентификацию. Она поддерживается для совместимости с клиентскими компьютерами, на которых выполняются системы Windows NT 4, Windows 95 и Windows 98. Этот протокол используется в следующих ситуациях.

Когда компьютер, на котором выполняются системы Windows 95, Windows 98 или Windows NT, подтверждает свою подлинность на контроллере домена Windows Server 2003. На компьютерах с системами Windows 95 и Windows 98 должна быть установлена служба Directory Services Client, или эти операционные системы смогут подтверждать подлинность только с использованием протокола LAN Manager.

Когда компьютер, на котором выполняются системы Windows XP Professional или Windows Server 2003, подтверждает подлинность на Windows NT 4 Server.

Когда любой клиент обращается к автономному серверу с системой Windows Server 2003.

Когда клиент, на котором выполняются системы Windows XP Professional или Windows 2000, пробует войти на контроллер домена с Windows Server 2003, но не способен подтвердить подлинность, используя протокол Kerberos. В этом случае NTLM аутентификация может использоваться как альтернативный протокол.

Протокол NTLM значительно менее безопасен, чем Kerberos. С пакетом Windows NT 4 Service Pack 4 компания Microsoft представила новую версию протокола NTLM с именем NTLMv2. Эта новая версия включает дополнительную защиту, такую как создание уникального ключа сеанса каждый раз при установлении нового подключения, а также расширенный процесс обмена ключами для защиты ключей сеанса.

Блокирование разрешения: используйте осторожно

Использование блокирования разрешения может привести к тому, что работать с моделью защиты вашей службы Active Directory будет очень трудно. Есть множество различных сценариев, в которых вы можете предусмотреть блокировку разрешения. Один из них состоит в том, что вы можете использовать Deny (Запретить) для удаления некоторых унаследованных разрешений. Например, вы можете предоставить разрешения Modify на контейнерном уровне, но заменить его на Read-Only (Только для чтения) далее вниз по иерархии. В этом же сценарии вы можете блокировать разрешение Write на любых объектах или свойствах далее вниз по иерархии.

Еще одним сценарием, в котором можно было бы использовать Deny, является создание контейнера, требующего более высокой защиты. Например, имеется контейнер для всех должностных лиц, и нужно сделать так, чтобы обычный пользователь не смог читать свойства учетных записей должностных лиц. Вы можете блокировать разрешение Read для контейнера, используя группу Domain Users (Пользователи домена). В результате пользователям будет запрещено читать объекты каталога, включая администраторов. Из-за осложнений, которые может вызвать использование Deny, вы должны применять эту опцию с осторожностью.

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

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

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

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

Для любой структуры Active Directory существует возможность того, что текущая конфигурация защиты окажется более сложной, чем первоначально разработанная конфигурация. Иногда это кончается тем, что пользователи имеют больше разрешений, чем следует. К счастью, в Windows Server 2003 есть инструмент, который может использоваться для определения фактических разрешений, представленных участнику безопасности для доступа к объектам Active Directory.

Обратитесь к свойствам объекта через соответствующий инструмент администрирования Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Effective Permissions (Фактические разрешения). На рисунке 9-7 показано окно инструмента Active Directory Users And Computers. Чтобы определить фактические разрешения для определенной учетной записи пользователя или группы, щелкните Select (ВыборХ а затем найдите имя группы или пользователя. Выбрав имя, щелкните на ОК. Окно Effective Permissions (Фактические разрешения) отображает все разрешения, которые предоставлены выбранному участнику безопасности для доступа к данному объекту Active Directory.



Примечание. Данный инструмент имеет некоторые ограничения, которые могут влиять на отображаемые фактические разрешения. Инструмент определяет фактические разрешения, основанные на наследовании и явно определенных разрешениях для учетной записи пользователя и его группы. Однако пользователь может также получить некоторые разрешения на основании того, как он входит в систему и соединяется с объектом. Например, в Windows Server 2003 вы можете назначать разрешения для группы Interactive (членом этой группы становится каждый, кто cделал вход на компьютер) или группы Network Login (каждый, кто обращается к информации по сети). Описанный выше инструмент Active Directory не может определять разрешения, предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он может определять разрешения, используя только разрешения человека, выполняющего инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то инструмент не способен точно определить разрешения.



Рис. 9-7. Отображение фактических разрешений для объекта Active Directory

Централизованный каталог

Active Directory является единственной централизованной службой каталога, которая может быть реализована в пределах предприятия. Это упрощает сетевое администрирование, поскольку администраторы не должны соединяться с несколькими каталогами, чтобы выполнять управление учетными записями. Другая выгода от использования централизованного каталога состоит в том, что он может также использоваться другими приложениями, такими как Exchange Server 2000. Это упрощает полное сетевое администрирование, так как используется единая служба каталога для всех приложений.

Что следует отслеживать

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

Рис. 14-6. Окно Event Properties (Свойства событий) для записи в журнал событий

Репликация Active Directory. Функционирование репликации существенно для обеспечения сохранности данных в пределах домена.

Службы Active Directory. Эти индикаторы функционирования отслеживаются с помощью счетчиков NTDS в инструменте администрирования Performance.

Хранилище базы данных Active Directory. Дисковые тома, которые содержат файл базы данных Active Directory Ntds.dit и файлы журналов .log, должны иметь достаточно свободного пространства, чтобы допускать нормальный рост и функционирование.

Функционирование службы DNS и «здоровье» сервера. Поскольку Active Directory полагается на DNS при поиске ресурсов в сети, то сервер DNS и сама служба должны работать в нормальных пределах, чтобы Active Directory удовлетворяла заданному уровню качества обслуживания.

Служба репликации файлов (File Replication Service - FRS). Служба FRS должна работать в пределах нормы, чтобы гарантировать, что общий системный том (Sysvol) реплицируется по всему домену.

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

«Здоровье» леса. Эта область должна отслеживаться для того, чтобы проверить доверительные отношения и доступность сайта.

Хозяева операций. Отслеживайте каждого хозяина операций FSMO, чтобы гарантировать «здоровье» сервера. Кроме того, проводите мониторинг для обеспечения доступности GC-каталога, позволяющего пользователям входить в систему и поддерживать членство универсальных групп.

Делегирование административных задач

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

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

Назначение полного управления одной OU. Довольно типична ситуация, когда компания имеет несколько офисов с локальным администратором в каждом офисе, который должен управлять всеми объектами локального офиса. Этот вариант может также использоваться компаниями, которые слили домены ресурсов Windows NT в OU одного домена Active Directory. Прежним администраторам доменов ресурсов можно дать полное управление всеми объектами, расположенными в определенной OU. Использование этой опции означает, что можно практически полностью децентрализовать администрирование вашей организации, имея единственный домен.

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

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

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

Можно использовать эти опции и любую их комбинацию в Active Directory Windows Server 2003. Один из способов конфигурирования делегированных разрешений состоит в прямом обращении к списку ACL для объекта и конфигурировании разрешений. Это может быть достаточно сложным из-за большого числа доступных опций и реальной возможности сделать ошибку.

Чтобы сделать эту задачу более легкой, Active Directory Windows Server 2003 включает Delegation Of Control Wizard (Мастер делегирования управления).

Чтобы использовать Delegation Of Control Wizard, выполните следующие действия.

Откройте инструмент Active Directory Users And Computers и найдите родительский объект, которому нужно делегировать управление. В большинстве случаев делегировать управление можно на уровне OU, домена или контейнера, например, на уровне контейнеров Computers (Компьютеры) или Users (Пользователи). Щелкните правой кнопкой мыши на родительском объекте и выберите Delegate Control (Делегировать управление). Щелкните на кнопке Next (Далее).



На странице Users Or Groups (Пользователи или группы) выберите пользователей или группы, которым вы хотите делегировать управление. Щелкните на кнопке Add (Добавить), чтобы просмотреть Active Directory для поиска соответствующих пользователей или групп.

Затем выберите задачи, которые вы хотите делегировать. Окно (рис. 9-11) дает вам возможность выбрать задачи из списка обычных или создать собственную задачу для делегирования.



Рис. 9-11. Использование Delegation Of Control Wizard (Мастер делегирования управления) для выбора обычной задачи или создания собственной задачи для делегирования

Если вы выберите создание собственной задачи, можете задать тип объектов, которым вы хотите делегировать административные разрешения (рис. 9-12).



Рис. 9-12. Выбор типа объектов, которым будут делегированы разрешения

Можно выбрать уровни разрешений, которые вы хотите применить к объекту: полный контроль над объектом или доступ к определенным свойствам (рис. 9-13).



Рис. 9-13. Выбор специфических разрешений для делегирования

Delegation Of Control Wizard значительно облегчает делегирование управления по сравнению с конфигурированием разрешений через ACL-списки. Однако эффект от применения обоих методов одинаков, т.е. ACL-списки объектов изменяются для обеспечения соответствующего уровня доступа.

Делегирование администрирования объектов GPO

Как говорилось в главе 9, одним из основных преимуществ Active Directory является функция делегирования многих административных задач в пределах организации. Управление групповыми политиками не является исключением - вы можете делегировать управление этим важным административным инструментом.

Имеются три опции, позволяющие делегировать администрирование групповыми политиками. С помощью первой опции можно делегировать разрешение создавать, удалять и изменять объекты GPO. По умолчанию это право имеют только члены групп Domain Admins (Администраторы домена) и Group Policy Creator Owners (Владельцы-создатели групповой политики). Группа Group Policy Creator Owners имеет дополнительное ограничение, состоящее в том, что члены этой группы имеют разрешение изменять параметры настройки только той групповой политики, которую они создавали сами. Если вы создаете в своей организации специальную группу администраторов, которые будут управлять групповой политикой, вы можете добавить этих администраторов к одной из групп. Вы можете предоставить право создавать и удалять групповые политики любой другой группе, но предоставить разрешения создавать или удалять объекты GPO сложнее, чем большинство сценариев делегирования разрешений. Вы должны дать пользователю разрешение создавать в Active Directory объекты GPO и разрешение записывать данные в папку %systemroot%\Sysvol\domainname\ Policies, в которой хранятся объекты GPT. Вы можете дать пользователям или группам разрешение изменять определенные объекты GPO, предоставляя им разрешения Read (Чтение) и Write (Запись) для объектов GPO.

Вторая опция позволяет делегирбвать права управления связями групповой политики. Эта опция не разрешает изменять какой-либо объект GPO, но позволяет добавлять или удалять связи объектов GPO с контейнерным объектом. Самый простой способ состоит в использовании Delegation Of Control Wizard (Мастер делегирования управления). В инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory) щелкните правой кнопкой мыши на объекте, для управления которым вы хотите назначить другого пользователя или группу, а затем щелкните Delegate Control (Делегировать управление), чтобы запустить мастер. При запуске мастера на уровне OU одной из стандартных задач делегирования является разрешение на управление связями групповой политики (см. рис. 11-16).

Третий способ делегирования состоит в предоставлении пользователям права генерировать информацию Resultant Set of Policy (RSoP) (Ре-

зультирующий набор политик). Используйте Delegation Of Control Wizard для предоставления права генерировать инструмент RSoP в режиме регистрации или планирования (см. рис. 11-16). Вы можете назначать эти разрешения, редактируя список ACL на контейнерном объекте, предоставляя пользователю разрешение Write к атрибуту gPLink. Это фактически дает пользователю разрешение конфигурировать блокирование групповых политик на контейнерном уровне.

Рис. 11-16. Делегирование разрешений на управление связями групповой политики

Делегирование аутентификации

Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может быть распределена между несколькими серверами. Например, клиент для получения информации соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы пользователь получил доступ только к санкционированной информации, для обращения к крайнему серверу базы данных должны использоваться «верительные грамоты» пользователя (вместо «верительных грамот» сервера внешнего интерфейса). В системе Windows 2000 протокол Kerberos обеспечивает это двумя способами: путем использования прокси-билетов (proxy tickets) и ретранслированных билетов (forwarded tickets). Если прокси-билеты разрешены, то клиент пошлет запрос на билет сеанса к центру KDC, требуя доступ к крайнему серверу. Служба KDC предоставит билет сеанса и установит на билете флажок PROXIABLE. Затем клиент представит билет сеанса серверу внешнего интерфейса, который использует его для доступа к информации, расположенной на крайнем сервере. Главная проблема с про-кси-билетами состоит в том, что клиент должен знать отличительные характеристики крайнего сервера. Другой вариант состоит в использовании ретранслированных билетов. Если эти билеты разрешены, то кли-

ент посылает запрос AS Exchange к центру KDC, требуя билет TGT, позволяющий серверу внешнего интерфейса обратиться к крайним серверам. Служба KDC создает билет TGT и посылает его клиенту для пересылки серверу внешнего интерфейса, который использует билет TGT для получения билета сеанса, позволяющего обратиться к крайнему серверу от имени клиента.

Имеется два существенных недостатка, связанных с реализацией делегирования аутентификации в системе Windows 2000. Первый недостаток состоит в том, что делегирование аутентификации может использоваться только в том случае, если клиент аутентифицирован через протокол Kerberos. Клиенты с системами Windows NT, Microsoft Windows 95 и Windows 98 не могут использовать делегирование аутентификации. В Windows Server 2003 клиент может использовать любой опознавательный протокол. Второй недостаток системы Windows 2000 касается защиты делегирования. В Windows 2000 после получения сервером внешнего интерфейса ретранслированного билета от центра KDC он может использовать его для доступа к любой сетевой службе от имени клиента. Windows Server 2003 имеет опцию, ограничивающую делегирование, т.е. учетную запись можно сконфигурировать так, что это делегирование будет применяться только для определенных сетевых служб (основываясь на основных именах служб). Ограниченное делегирование доступно в случае, если функциональный уровень домена установлен на функциональный уровень Windows Server 2003.

Для успешного делегирования аутентификации нужна гарантия, что и учетная запись пользователя, и учетная запись компьютера (или службы) сконфигурированы так, чтобы поддерживать делегирование аутентификации. Для этого обратитесь к окну Properties (Свойства) пользователя через инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), выберите вкладку Account (Учетная запись), а затем просмотрите список Account Options (Опции учетной записи). Удостоверьтесь, что oпция Account Is Sensitive And Cannot Be Delegated (Учетная запись точна и не может быть делегирована) не выбрана. (По умолчанию опция не выбрана.) Чтобы сконфигурировать учетную запись службы для делегирования, нужно определить, является ли учетная запись, используемая службой для входа в систему, нормальной учетной записью пользователя, или она является учетной записью LocalSystem. Если служба выполняется под нормальной учетной записью пользователя, обратитесь к вкладке Account пользователя и удостоверьтесь, что опция Account Is Sensitive And Cannot Be Delegated не выбрана. (По умолчанию она не выбрана.) Если служба выполняется под учетной записью LocalSystem, то делегирование было сконфигурировано в окне Properties компьютерной учетной записи (см. рис. 8-6). Чтобы реализовать уровень аутентификации Windows 2000, выберите опцию Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру при делегиро-

вании к любой службе (Только протокол Kerberos)). Чтобы реализовать усовершенствованный уровень аутентификации Windows Server 2003, выберите опцию Trust This Computer For Delegation To Specified Services Only (Доверять этому компьютеру только при делегировании к указанной службе). Затем укажите, должен ли клиент подтверждать подлинность только с использованием протокола Kerberos, или он может использовать любой другой протокол, а затем выбрать службы (основываясь на основных именах служб, зарегистрированных в Active Directory), которым компьютер может представлять делегированные «верительные грамоты».



Рис. 8-6. Конфигурирование ограниченного делегирования для учетной записи компьютера

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

Одно из ограничений базы данных Windows NT 4 SAM состояло в том, что административные права были доступны только в виде «все или ничего». Чтобы дать пользователю любую степень административных прав требовалось, чтобы вы сделали пользователя членом группы Domain Admins. Этот уровень административных прав давал пользователю, по существу, безграничную власть в пределах домена, включая право удалять других пользователей из группы Domain Admins. Такой метод делегирования административных функций не был безопасным. С другой стороны, Active Directory предоставляет администраторам возможность делегировать административные права. Используя мастер Delegation Of Control Wizard (Делегирование управления) или устанавливая определенные разрешения на объекты Active Directory, администраторы могут предлагать тонко настроенные административные права. Например, вы можете назначить определенной учетной записи пользователя административное право сбрасывать пароли в домене, но не создавать, удалять или как-либо изменять пользовательский объект.

Делегированные зоны

Поскольку система DNS использует иерархическое пространство имен, должен существовать механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером, который является полномочным для домена первого уровня сот, и запрашивает сервер в домене Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).

Запись делегирования представляет собой указатель на домен низшего уровня, который идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что DNSl.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS3 являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS1 считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера имен дочернего домена.

Деревья доменов

Домены, которые создаются в инфраструктуре Active Directory после создания корневого домена, могут использовать существующее пространство имен Active Directory совместно или иметь отдельное пространство имен. Чтобы выделить отдельное пространство имен для нового домена, нужно создать новое дерево домена. Независимо от того, используется ли единственное пространство имен или несколько, дополнительные домены в том же самом лесу функционируют совершенно одинаково. Создание дополнительных деревьев доменов связано исключительно с организационными проблемами и проблемами именования, оно никак не затрагивает функциональные возможности. Дерево доменов содержит, по крайней мере, один домен. Даже организация с единственным доменом имеет дерево доменов. Использование нескольких деревьев вместо дочерних доменов влияет на конфигурацию DNS, об этом вы узнаете в гл. 3.

Дерево доменов образуется в том случае, когда организация создает домен вслед за созданием корневого домена леса (forest root domain), но не хочет использовать существующее пространство имен. В случае Contoso, если существующее дерево доменов использует пространство имен Contoso.com, может быть создан новый домен, который использует совершенно другое пространство имен, например, Fabrikam.com. Если в дальнейшем потребуется создание доменов, чтобы удовлетворить потребностям единицы Fabrikam, они могут создаваться как дочерние от дерева доменов Fabrikam. На рисунке 2-7 показана схема организации Contoso с несколькими доменными деревьями.

Рис. 2-7. Корпорация Contoso с несколькими доменными деревьями

Деревья доменов и доверительные отношения

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

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

любом случае все домены совместно используют транзитивные доверительные отношения с другими доменами, GC и конфигурационный контейнер. Главная сложность в использовании нескольких деревьев состоит в разработке пространства имен DNS и конфигурации серверов DNS. Но с появлением условных ретрансляторов (conditional forwarders) и сокращенных зон (stub zones) эта процедура в Windows Server 2003 упростилась.

Если вы развертываете несколько доменов, и пользователи часто обращаются к ресурсам, расположенным в других доменах или входят на них, вы, возможно, захотите добавить прямые доверительные отношения (shortcut trusts) к проекту своего домена. Прямые доверительные отношения используются для улучшения производительности при доступе к ресурсам или при входе в систему с разных доменов. По умолчанию дове- • рительные отношения между доменами в Active Directory являются или родительско-дочерними, или доверительными отношениями корня дерева. Каждая родительско-дочерняя пара совместно использует двухсторонние доверительные отношения, так же как и корни каждого дерева. Поскольку доверительные отношения транзитивны, это означает, что все домены в лесу доверяют друг другу. Однако когда пользователь входит в домен, не являющийся его домашним доменом, возможно, что процессу входа в систему придется пересекать весь путь доверительных отношений. Например, корпорация имеет структуру домена, показанную на рисунке 5-4. Если пользователь с учетной записью в домене Asia.Fab-rikam.com входит в домен Canada.NAmerica.Contoso.com Contoso.com, то начальный запрос входа в систему пойдет на контроллер домена в канадском домене. Запрос на вход в систему должен ссылаться на доверительные отношения с доменом NAmerica, затем с доменом Contoso, далее с доменом Fabrikam и, наконец, с доменом Asia. Прямые доверительные отношения могут сокращать путь доверительных отношений. Например, если прямые доверительные отношения сконфигурированы между доменами Canada и Asia, запрос на вход в систему может быть отправлен контроллеру домена в домене Asia напрямую.

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

Рис. 5-4. Прямые доверительные отношения могут использоваться для оптимизации доступа к ресурсам разных доменов

Дезактивация объектов схемы

В Windows Server 2003 сетевые администраторы имеют возможность «дезактивировать», или выключить, классы, схемы и атрибуты. В результате вы можете переопределять атрибуты и классы вместо необходимости создавать новый атрибут или класс в случае ошибки в определении какого-либо постоянного свойства. Предположим, что администратор решает расширить схему, чтобы включить в нее атрибут «Размер обу-

ви» объекта класса «Пользователь», и неосторожно устанавливает определение атрибута на integer (целое число). Получив отказ, администратор решает, что это должно быть строковое (string) значение, чтобы включать и размер, и ширину. Путем дезактивации атрибутов схемы первоначальный атрибут можно выключить и создать новый атрибут с тем же именем «Размер обуви» и с соответствующим определением. Без этой возможности администратор должен был бы создать новый атрибут с уникальным названием и целиком отказаться от атрибута «Размер обуви». В качестве подстраховки, чтобы предотвратить случайную дезактивацию, изменения, произведенные дезактивацией объектов схемы, являются обратимыми.

Расширение схемы не является сложной операцией, но перед ее осуществлением необходимо провести предварительное планирование, ведь все изменения схемы являются необратимыми. Объекты не могут быть удалены из схемы. Если вы сделаете ошибку при расширении схемы, вы можете отключить (дезактивировать) объект. В Windows Server 2003 дезактивированные объекты схемы могут снова использоваться при необходимости, а новые объекты схемы могут создаваться с тем же самым именем, которое имел дезактивированный объект.

Есть несколько моментов, которые надо иметь в виду при дезактивации класса схемы и объектов атрибутов. Сначала вы можете дезактивировать только классы и атрибуты, которые вы специально создавали, т.е. объекты Category 2. Вы не можете дезактивировать объекты Category 1 или базовую схему. Нельзя отключить атрибут, являющийся членом класса, который не дезактивирован. Это ограничение предотвращает ошибки в создании новых экземпляров недезактивированного класса, если становится нужен дезактивированный атрибут.

Чтобы дезактивировать объект атрибута или класса Category 2, установите булевое значение атрибута isDefunct объекта схемы на true (истина). Это можно выполнить, используя инструмент ADSI Edit (Редактирование ADSI) или оснастку Active Directory Schema (Схема Active Directory). На рисунке 2-3 показано, какие флажки параметров установки надо очистить для дезактивации атрибута EmployeeStartDate, созданного в примере, представленном ранее.

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

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

Рис. 2-3. Использование оснастки Active Directory Schema (Схема Active Directory) для дезактивации атрибута схемы

Динамическая система DNS

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

DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server 2003 автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска контроллеров домена. DNS-серверы Windows Server 2003 будут

также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов (DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me или Microsoft Windows NT.

Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем, кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server 2003 существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users (Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить это, изменяя список управления доступом ACL (ACL - Access Control List) для DNS-зоны.

Динамическая система DNS уменьшает объем работы, который должен делать администратор DNS. Далее вы узнаете, что Active Directory Windows Server 2003 требует присутствия SRV-записи каждого контроллера домена в зонной информации, поэтому поддержка динамических обновлений является важным свойством DNS-системы Windows Server 2003.

Для входа в систему не нужен доступ к глобальному каталогу

При входе в домен, находящийся в основном режиме Windows 2000 (native-mode), необходимо вступить в контакт с сервером глобального каталога (GC - Global Catalog) для обработки универсального группового членства пользователя. Эта групповая информация требуется для того, чтобы создать лексему доступа пользователя. Для избежания ситуаций, в которых пользовательские входы в систему отклоняются из-за выключенной связи с GC, обычная практика при проектировании Active Directory состоит в размещении глобальных каталогов в тех местах, которые соединены с основной сетью менее надежными сетевыми связями. Теперь контроллеры домена Windows Server 2003 можно сконфигурировать так, чтобы информация универсального группового членства кэшировалась, и пользовательские входы в систему могли быть обработаны без контакта с GC. В результате не требуется, чтобы каждое удаленное место расположения компании имело GC-каталог. Кроме того, при отсутствии GC-каталога на каждом удаленном сайте трафик репликации по сетевым соединениям, связывающим эти сайты, уменьшается.

DNS

Как говорилось в предыдущих главах, Active Directory требуется служба DNS в качестве указателя ресурсов. Клиентские компьютеры полагаются на DNS при поиске контроллеров домена, чтобы они могли аутен-тифицировать себя и пользователей, которые входят в сеть, а также делать запросы к каталогу для поиска опубликованных ресурсов. Кроме того, служба DNS должна поддерживать записи службы указателя ресурсов (SRV) и динамические модификации. Если служба DNS не была установлена предварительно, то мастер инсталляции Active Directory установит и сконфигурирует DNS одновременно с Active Directory.

Если DNS уже установлена в сети, проверьте ее конфигурацию, чтобы она могла поддерживать Active Directory. Для этой проверки можно использовать команду Dcdiag (доступна как часть набора инструментальных средств, созданного при установке файла \Support\Tools\ Support.msi с компакт-диска Windows Server 2003). Наберите команду:

dcdiag/test:dcpromo/dnsdomain:domainname/newforest

Теперь вы сможете удостовериться, что DNS-сервер является официальным для домена domainname и может принимать динамические обновления для новых контроллеров домена. Для получения дополнительной информации об использовании инструмента dcdiag напечатайте dcdiag/? в командной строке.

Если служба DNS в сети отсутствует, вас попросят установить службу сервера DNS в процессе инсталляции Active Directory. Если контроллер домена, который вы устанавливаете, будет также сервером DNS, то проведите тщательное планирование пространства имен DNS, которое вы будете использовать (см. гл. 5 для получения дополнительной информации о проектировании пространства имен DNS).

Если вы будете устанавливать службу сервера DNS одновременно с Active Directory, сконфигурируйте установки сервера DNS на компьютере, чтобы указать себя перед установкой Active Directory. Откройте окно Internet Protocol (TCP/IP) Properties (Свойства протокола интер-

нета) и установите адрес сервера Preferred DNS Server (Привилегированный сервер DNS) на IP-адрес локального компьютера (см. рис. 6-1).

Рис. 6-1. Конфигурирование параметров настройки сервера DNS

DNS-домены, зоны и серверы

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

Active Directory не сможет функционировать

Active Directory не сможет функционировать без надежной конфигурации DNS. Контроллеры домена не смогут находить друг друга для репликации доменной информации, клиенты с системами Windows 2000 и Windows XP Professional будут очень медленно искать контроллеры домена для входа в систему. Без надежной DNS любые другие службы, которым требуется Active Directory, не смогут работать. Например, Exchange Server 2000 хранит всю свою конфигурационную информацию в Active Directory, поэтому если серверы, на которых выполняется Exchange Server 2000, не смогут найти контроллер домена при запуске, они не смогут запустить большинство служб Exchange Server 2000.

Совет. Клиенты, на которых выполняются системы Windows 95, Windows 98, Windows Me и Windows NT не полагаются на DNS в поиске контроллеров домена с Windows Server 2003. Они используют для поиска имена NetBIOS, а службу имен интернета для Windows (WINS - Windows Internet Naming Service) - для разрешения имен NetBIOS к IP-адресам. По умолчанию Windows Server 2003 поддерживает низкоуровневых клиентов, регистрируя необходимые имена NetBIOS с помощью WINS.

Документирование текущей среды

Первый шаг в планировании модернизациии Active Directory состоит в документировании существующего каталога и платформы сетевых служб. Вы будете удивлены, обнаружив, как многого вы не знали о серверах, службах и приложениях, выполняющихся на ваших контроллерах домена. Используйте эту ревизию как возможность почистить «паутину» и, возможно, удалить избыточные или неиспользуемые элементы. Вы сделаете вашу сеть более эффективной и легкой в сопровождении и уменьшите объем работы, который предстоит проделать в процессе модернизации службы каталога.

Как только текущая среда будет задокументирована, примите решение о том, как и когда модернизировать Active Directory.

Ниже приводятся те элементы, описание которых вы включите в свой план.

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

все домены вашей организации (домены ресурсов и учетных записей);

все доверительные отношения между доменами (включая тип и направление доверительных отношений);

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

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

все системные политики и политики безопасности, которые внедрены в вашей организации.

Текущие сетевые службы Windows NT 4. Задокументируйте все сетевые службы, использующиеся на вашем предприятии, включая сервер, на котором они выполняются. Убедитесь, что ваш план перехода отвечает за выполнение этих служб. Вы должны задокументировать следующие службы:

серверы DNS;

серверы протокола динамической конфигурации хоста (DHCP), a также параметры настройки области действия (scope);

серверы службы имен интернета для Windows (WINS);

серверы службы удаленного доступа (RAS) (см. примечание ниже);

файловые серверы и сервера печати.

Предостережение. RAS-серверы системы Windows NT 4 используют NULL- сеансы для определения разрешений модема и других параметров его настройки, типа номеров телефона повторного вызова (call-back) для удаленных пользователей. По умолчанию Active Directory не принимает запросы к атрибутам объектов при использовании NULL-сеансов. Без надлежащего планирования взаимодействие служб удаленного доступа в смешанной среде может вызвать отказ в сетевом удаленном доступе для законных пользователей, связывающихся с системой через модем. Чтобы избегать RAS-конфликтов в процессе модернизации, нужно как можно раньше обновить RAS-серверы Windows NT 4. Если в процессе модернизации вы будете поддерживать смешанную среду, нужно понизить заданную по умолчанию защиту Active Directory, выбирая опцию Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с операционными системами, предшествующими Windows 2000 Server) при выполнении мастера инсталляции Active Directory.

Аппаратные средства сервера с Windows NT 4 Server и конфигурации программного обеспечения. Это особенно важно для обновления, при котором вы планируете продолжать использование имеющихся аппаратных средств сервера в модернизированной среде домена. Должна быть уверенность в том, что любой сервер, который снова будет использоваться в том же качестве, удовлетворяет требованиям, предъявляемым к аппаратным средствам Windows Server 2003. Важно также задокументировать программную конфигурацию каждого сервера для гарантии того, что все приложения и службы будут учтены в новой среде. Для контроллеров домена и серверов-членов домена, этот список должен включать следующее:

o количество процессоров и их скорость;

o       оперативная память;

o       системы хранения информации;

o       NOS, выполняющаяся на каждом сервере. (Вы можете обнаружить, что у вас имеется совокупность разных NOS, которые имеют различные пути обновления.);

o       операционная система, выполняющаяся на рабочих станциях. (Это определит то, как вы реализуете системные политики и сценарии входа в систему.);

o       все приложения, связанные с бизнесом, выполняющиеся на контроллере домена с системой Windows NT 4. (Вы должны задокументировать, совместимы ли они с Windows Server 2003 и следует ли их проверять на новой платформе.)

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

Домены

Домен является основным строительным блоком в модели службы Active Directory. Устанавливая Active Directory на своем компьютере, работающем под управлением Windows Server 2003, вы создаете домен. Домен служит в качестве административной границы, он определяет и грани-

цу политик безопасности. Каждый домен имеет, по крайней мере, один контроллер домена (оптимально иметь два или более).

Домены Active Directory организованы в иерархическом порядке. Первый домен на предприятии становится корневым доменом леса, обычно он называется корневым доменом или доменом леса. Корневой домен является отправной точкой для пространства имен Active Directory. Например, первый домен в организации Contoso — Contoso.com. Первый домен может быть назначенным (dedicated) или неназначенным (non-dedicated) корневым доменом. Назначенный корневой домен, называемый пустым корнем, является пустым доменом-заменителем, предназначенным для запуска Active Directory. Этот домен не будет содержать никаких реальных учетных записей пользователя (группы) и использоваться для назначения доступа к ресурсам. Единственные учетные записи, которые содержатся в назначенном корневом домене — это учетные записи пользователей и групп, заданных по умолчанию, таких как учетная запись Administrator (Администратор) и глобальная группа Domain Admins (Администраторы домена). Неназначенный корневой домен - это домен, в котором создаются учетные записи фактических пользователей и групп. Причины выбора назначенного или неназначен-ного корневого домена леса обсуждаются в гл. 5.

Остальные домены на предприятии существуют или как равные по положению (peers) по отношению к корневому домену, или как дочерние домены. Равные по положению домены находятся на том же иерархическом уровне, что и корневой домен. На рисунке 2-5 показана модель доменов, равных по положению.

Рис. 2-5. Домены Active Directory, организованные как равные по положению

Общепринято, что домены, устанавливаемые вслед за корневым доменом, становятся дочерними доменами. Дочерние домены используют одно и то же пространство имен Active Directory совместно с родительским доменом. Например, если первый домен в организации Contoso назван Contoso.com, то дочерний домен в этой структуре может называться NAmerica.Contoso.com и использоваться для управления всеми участниками безопасности организации Contoso, находящимися в Северной Америке. Если организация достаточно большая или сложная, то могут потребоваться дополнительные дочерние домены, например, Sales.NAmerica.Contoso.com. На рисунке 2-6 показана родительско-до-черняя иерархия домена для организации Contoso.

Рис. 2-6. Родительско-дочерняя модель домена для корпорации Contoso

Домены и проект Active Directory

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

Граница репликации. Границы домена являются границами репликации для раздела домена каталога и для информации домена, хранящейся в папке Sysvol на всех контроллерах домена. В то время как другие разделы каталога (раздел схемы, конфигурации и GC) реплицируются по всему лесу, раздел каталога домена реплицируется только в пределах одного домена.

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

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

Домены Windows Server 2003 и Active Directory

Самая последняя, улучшенная и усовершенствованная, версия Active Directory, представленной в Windows 2000, является компонентом всех членов семейства Windows Server 2003 за исключением Web Edition, которая не нуждается в компоненте Active Directory и не реализует его. Служба Active Directory семейства Windows Server 2003 предлагает сетевым администраторам масштабируемость, возможности доступа и функциональность, необходимые для управления инфраструктурой службы каталога вычислительной среды современных предприятий. Наши представления о том, что должна выполнять служба каталога, значительно расширились со времени компьютеров с MS-DOS, связанных сетью под управлением LAN Manager, и Active Directory является идеальным инструментом, удовлетворяющим этим представлениям. Далее в этой главе объясняется, каким образом Active Directory выполняет свою роль в центре среды Windows Server 2003, и какие новые функции появились в этом выпуске.

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

Система Windows Server 2003 обеспечивает инструментальные средства, которые могут использоваться для управления шаблонами защиты. Одно из этих средств - оснастка Security Configuration And Analysis (Конфи-

гурация защиты и анализ), которая используется для создания или изменения существующих шаблонов защиты. Затем шаблон загружается в оснастку Security Configuration And Analysis и используется для анализа определенных компьютеров. Например, можно загрузить шаблон сильной защиты, а затем проанализировать, имеются ли различия между шаблоном и текущей компьютерной конфигурацией. На рисунке 13-9 показан пример результатов такого анализа.

Вы можете использовать этот инструмент и для применения шаблона защиты к компьютеру. Щелкните правой кнопкой мыши на Security Configuration And Analysis и выберите Configure Computer Now (Сконфигурировать компьютер сейчас). Все параметры настройки защиты на компьютере будут изменены в соответствии с шаблоном защиты.

Рис. 13-9. Анализ конфигурации защиты компьютера с помощью оснастки Security Configuration And Analysis

Оснастка Security Configuration And Analysis не предназначена для использования с групповыми политиками. Этот инструмент использует те же самые предопределенные шаблоны защиты, что и редактор объектов групповых политик, но он предлагает альтернативные средства для развертывания шаблонов. Он предназначен прежде всего для использования с автономными компьютерами.

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

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

Дополнительные серверы имен

Дополнительный сервер имен (Secondary Name Server) имеет копию зонных файлов, которая предназначена только для чтения. Единственный способ обновления зонной информации дополнительного сервера имен состоит в зонной передаче с основного сервера имен. В ранних версиях DNS каждая зонная передача была полной зонной передачей, т.е. все содержимое зонного файла DNS передавалось с основного сервера имен на дополнительный. Документ Request for Comment 1995 (Запрос на комментарии) представил более эффективный механизм зонной передачи, называемый добавочной зонной передачей (incremental zone transfers), в котором на дополнительный сервер копируются только изменения, сделанные в зонных файлах с момента последней передачи. Другое усовершенствование представлено в документе Request for Comment 1996. Это механизм уведомлений, который позволяет основному серверу предупреждать дополнительные серверы имен о том, что были сделаны изменения к зонным файлам. Без опции уведомления дополнительный сервер имен будет контактировать с основным сервером только через интервалы времени, определенные в записях SOA для каждой зоны.

Примечание. DNS-сервер Windows Server 2003 поддерживает как добавочную зонную передачу, так и уведомления. Он также поддерживает интегрированные (integrated) зоны Active Directory, в которых регулярная зонная передача заменена репликацией Active Directory.

Дополнительные требования защиты

Чтобы разрешить перемещение ресурсов Windows NT 4 в Windows Server 2003, выполните действия, связанных с защитой.

Удостоверьтесь, что группа Domain Admins (Администраторы домена) целевого домена является членом локальной группы администраторов на домене ресурсов с системой Windows NT 4. Это обеспечит необходимые административные права на каждом сервере-члене домена и на каждой рабочей станции в домене ресурсов, чтобы вы могли перемещать ресурсы домена.

Создайте второе доверительное отношение от целевого домена к домену ресурсов. В разделе «Создание чистого леса» этой главы рассказывалось, как это сделать. Устанавливая второе доверительное отношение, вы создаете два односторонних доверительных отношения между доменом ресурсов и целевым доменом. Используйте оснастку Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) для проверки того, что это доверительное отношение было установлено.

Дополнительный контроллер домена, инсталлированный с резервных средств хранения информации

Эта новая функция является усовершенствованием к процессу инсталляции Active Directory. В системе Windows 2000 при установке дополнительного контроллера домена могло потребоваться очень много времени (от нескольких часов до нескольких дней) на завершение начальной репликации разделов каталога, особенно для больших разделов каталога или для контроллеров домена, соединенных медленными линиями связи. Процесс инсталляции Active Directory для Windows Server 2003 теперь поддерживает создание разделов каталога из недавней резервной копии данных System State (Состояние системы) с другого контроллера домена Windows Server 2003. Так как к данным каталога обращаются с местного диска, а не через репликацию по сети, этот процесс сильно ускоряется.

Доверительные отношения

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

транзитивные доверительные отношения;

односторонние доверительные отношения;

доверительные отношения леса;

доверительные отношения области.

Доверительные отношения леса

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

Доверительные отношения леса не являются транзитивными по отношению к другим лесам. Например, если Forest 1 имеет доверительные отношения леса с Forest2, и Forest2 имеет доверительные отношения леса с Forest3, то Forestl  не имеет автоматических доверительных отношений леса с Forest3.

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

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

На рисунке 2-11 показаны доверительные отношения леса компании Contoso.

Рис. 2-11. Доверительные отношения леса компании Contoso соединяют домены Contoso.com и NWTraders.com, находящиеся в разных лесах

Доверительные отношения области

Последний тип доверительных отношений — это доверительные отношения области (Realm Trusts). Они устанавливаются между доменом или лесом Windows Server 2003 и не Windows-реализацией области Kerberos v5. Защита Kerberos основана на открытом стандарте, имеются другие сие-

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

Единая регистрация

В определенном месте леса (forest - логический компонент реализации Active Directory) Windows Server 2003 пользователи могут войти в сеть с помощью идентификации основных пользовательских имен (UPN -User Principal Name), например, mike@contoso.com. После успешной идентификации им будет предоставлен доступ ко всем сетевым ресурсам, для которых им было дано разрешение, без необходимости регистрироваться снова на различных серверах или доменах. Имя UPN является обязательным атрибутом объекта учетной записи пользователя в Active Directory, и оно устанавливается по умолчанию в Active Directory, когда создается новая учетная запись пользователя.

Фактические разрешения

Как описано в этой главе к настоящему моменту, пользователь может получить разрешения к объекту в Active Directory несколькими способами.

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

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

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

Все разрешения суммируются, т.е. пользователю предоставляется самый высокий уровень разрешений от любой из этих конфигураций. Например, если пользователю явно дано разрешение Read (Чтения) к определенному объекту, при этом он принадлежит к группе с разрешением Modify (Изменять) и группе с разрешением Full Control (Полное управление) на контейнерном уровне, то этот пользователь будет иметь разрешение Full Control. Когда пользователь обращается к объекту, подсистема защиты исследует все записи АСЕ, которые прикреплены к объекту. Они оцениваются, и устанавливается самый высокий уровень разрешения. В дополнение к записям АСЕ, которые предоставляют разрешения, Active Directory поддерживает также блокирование разрешений. Блокирование разрешений может применяться на двух уровнях.

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

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

Блокирование разрешения (Deny) всегда отменяет разрешение (Allow). Например, если пользователь является членом группы, которая имеет разрешение Modify для объекта Active Directory, и если разрешение Modify к этому объекту явно блокировано для данного пользователя, то он не сможет изменять объект. Это происходит потому, что записи АСЕ, которые блокируют разрешения, оцениваются перед оценкой записей АСЕ, которые позволяют разрешения. Если одна из записей АСЕ блокирует разрешение участнику безопасности, то другие записи АСЕ для данного объекта не оцениваются.

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

Фильтрация применения групповой политики

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

Directory. По умолчанию при создании групповой политики она применяется ко всем пользователям и компьютерам в контейнере. Рассмотрите вкладку Security (Безопасность) для недавно созданной групповой политики. Как показано на рисунке 11-10, вкладка Security для всех объектов GPO сконфигурирована так, что группа Authenticated Users (Удостоверенные пользователи) имеет разрешения Read (Чтение) и Apply Group Policy (Применение групповой политики). Поэтому все удостоверенные пользователи, включая и компьютеры, и пользователей, будут затронуты этой политикой.

Можно изменить воздействие групповой политики на компьютер или пользователя, модифицируя установку разрешения Apply Group Policy для учетных записей. Для этого сначала удалите группу Authenticated Users с вкладки Security или очистите флажок Apply Group Policy. Затем добавьте соответствующие учетные записи к списку управления доступом (ACL) и предоставьте им разрешения Read и Apply Group Policy. Можете изменить разрешения, добавляя какого-либо участника безопасности, но наилучшая практика состоит в том, чтобы всегда использовать группы Active Directory вместо учетных записей индивидуальных пользователей или компьютеров.

Рис. 11-10. Конфигурирование вкладки Security(Безопасность) в окне Properties (Свойства) объекта GPO для изменения области применения объекта GPO

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

Опция, предназначенная для применения групповых политик к выбранной группе, полезна во множестве различных сценариев. Например, вы планируете установить специфический пакет программ для группы пользователей, учетные записи которых рассеяны в различных OU по всему домену. Чтобы инсталлировать приложение, используя групповые политики, свяжите объект GPO с контейнерным объектом, который содержит учетные записи пользователей, а затем измените защиту GPO-объекта так, чтобы групповая политика применялась только к указанной группе. Другим примером является ситуация, когда имеется объект GPO, который назначен определенной OU, но вы не хотите, чтобы этот объект применялся ко всем пользователям этой OU. В этом случае вы можете, во-первых, создать группу, содержащую учетные записи пользователей, которым требуется данная групповая политика, и сконфигурировать разрешение Apply Group Policy только для этой группы. Во-вторых, вы можете создать группу, которая содержит все учетные записи пользователей, которым не требуется данная групповая политика, и использовать установку Deny (Запретить) на разрешении Apply Group Policy (Применить групповую политику) для гарантии того, что групповая политика не будет применяться к этим пользователям.

Совет. Если вы удаляете разрешение Apply Group Policy для группы, вы должны также удалить Read Access (Доступ для чтения). Если этого не сделать, то групповая политика будет читаться каждый раз при запуске компьютера и входе в систему членов группы, даже если она не применяется, и это окажет вредное воздействие на процессы запуска системы.

Совет. Active Directory Windows Server 2003 обеспечивает опцию фильтрации применения групповых политик, основанную на фильтрах Windows Management Instrumentation (Аппаратура управления Windows) (WMI). Фильтры WMI, написанные на языке WMI-запросов, могут использоваться для более точного определения групповых политик, применяемых к компьютеру. Например, можно использовать эту опцию для указания того, что пакет программ должен устанавливаться только на компьютере, имеющем более 200 Мб доступного дискового пространства, или на компьютере, имеющем более 64 Мб оперативной памяти. Подробности смотрите в Центре справки и поддержки (Help And Support Center) и в комплекте WMI Software Development Kit на веб-сайте Microsoft по адресу http: // msdn.microsoft.com/ library/default.asp?url=/library/en-us/wmidsk/wmi/ wmi_start_page.asp.

Физическая структура службы Active Directory

Физическое проявление службы Active Directory состоит в наличии отдельного файла данных, расположенного на каждом контроллере домена в домене. Физическая реализация службы Active Directory описывается местоположением контроллеров домена, на которых расположена служба. При реализации службы Active Directory можно добавлять столько контроллеров доменов, сколько необходимо для поддержания служб каталога в данной организации. Имеется пять определенных ролей, которые может играть каждый из контроллеров домена. Они известны как роли хозяина операций (operations master roles). Еще одна роль, которую может выполнять любой отдельный контроллер домена в домене, связана с глобальным каталогом (GC — Global Catalog). В этом разделе мы рассмотрим хранилище данных службы Active Directory и контроллеры домена, на которых оно расположено.

Функциональные уровни

Active Directory Windows Server 2003 вводит функциональные уровни домена и леса, которые обеспечивают обратную совместимость для доменов, содержащих низкоуровневые контроллеры домена. Имейте в

виду, что вы должны будете поднять функциональный уровень домена или леса, чтобы реализовать многие другие изменения в Active Directory для Windows Server 2003. Многие из новых функций требуют сетевой среды, в которой все контроллеры домена имеют операционную систему Windows Server 2003.

Примечание. Низкоуровневым контроллером домена является любой контроллер домена в домене Windows Server 2003, который имеет любую более раннюю версию NOS, например, Windows NT 4 или Windows 2000.

Функциональный уровень домена и леса, заданный по умолчанию, — «Windows 2000» (для домена — «Windows 2000 mixed»). Это означает, что при установке Active Directory конфигурируется так, чтобы использовались только те новые функции, которые могут поддерживаться комбинацией контроллеров домена с Windows Server 2003 и Windows Server 2000. Чтобы воспользоваться преимуществами новых функций службы Active Directory, уровень функциональных возможностей должен быть поднят к уровню контроллеров домена Windows Server 2003 как можно скорее, т.е. в домене не должно остаться ни одного контроллера домена, на котором выполняются системы Windows 2000 или Windows NT 4.

Примечание. Функциональные уровни Active Directory в Windows Server 2003 тесно связаны с настройками mixed-mode (смешанный режим) и native-mode (основной режим) домена в Windows 2000. С выпуском операционной системы Windows Server 2003 появилась возможность иметь на предприятии другую платформу службы каталога Microsoft Active Directory, поэтому настройки домена вобрали в себя новые дополнительные свойства Active Directory. Концепции функциональных возможностей домена и режима домена по существу одинаковы. Для получения дополнительной информации об уровнях функциональных возможностей см. табл. 2-1 и 2-2.

В Windows Server 2003 каждому лесу и каждому домену в пределах леса может быть назначен определенный функциональный уровень. Функциональные уровни используются для того, чтобы разрешать функции, которые реализованы на комбинациях операционных систем. Когда для домена устанавливается функциональный уровень, то он применяется только к данному домену. Если не определено иначе, домены создаются на функциональном уровне mixed (смешанный) системы Windows 2000; леса создаются на функциональном уровне Windows 2000.

В таблице 2-1 показаны функциональные уровни доменов и операционные системы, поддерживаемые на контроллерах домена.

Табл. 2-1. Функциональные уровни домена

Функциональный уровень домена		Операционные системы, поддерживаемые на контроллерах данного домена
Windows 2000 mixed (смешанный) (значение ро умолчанию)		Windows NT 4, Windows 2000, Windows Server 2003.
Windows 2000 native (основной)		Windows 2000, Windows Server 2003.
Windows Server 2003 interim (промежуточный) Windows Server 2003		Windows NT 4, Windows Server 2003. Windows Server 2003.

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

Табл. 2-2. Функциональные уровни леса

Функциональные уровни леса		Операционные системы, поддерживаемые на контроллерах данного домена в лесу
Windows 2000 (значение по умолчанию)		Windows NT 4, Windows 2000, Windows Server 2003.
Windows Server 2003 interim (промежуточный) Windows Server 2003		Windows NT 4, Windows Server 2003. Windows Server 2003.

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

Итак, глобальный каталог (GC) используется для того, чтобы облегчить пользовательский вход в систему, допуская использование основ-

ных имен пользователя (например, usernarae@contoso.com). Каталог GC понимает основные имена пользователя (UPN - User Principal Names), потому что он содержит информацию о каждом пользователе в каждом домене леса. Контроллеры домена, не имеющие каталога GC, не обладают этими данными, они не способны подтвердить подлинность пользовательского входа в систему, если он задается в таком формате.

Функционирование ядра операционной системы

Счетчики (см. табл. 14-4) отслеживают индикаторы, характеризующие работу ядра операционной системы, они прямо воздействуют на производительность Active Directory.

Табл. 14-4. Основные индикаторы операционной системы

Объект		Счетчик		Интервал		Порог		Значимость превышения порогового значения
Memory (Память)		Page Faults/ sec (Ошибки страницы/ секунды)		Каждые 5 минут		700/с		Высокая степень ошибок страницы указывает на недостаточную физическую память.
Physical Disk (Диск)		Current DiskQueue «length (Текущая длина очереди к Диску)		Каждую минуту		Удвоенное среднее значение в течение трех интервалов		Отслеживает объемы файлов Ntds.dit и .log. Указывает, что имеется отставание    дисковых запросов   ввода/ вывода. Рассмотрите    возможность увеличения диска и производительности контроллера.
Processor (Процессор)		% DPC Time (Instance=_Total) (% времени DPC)		Каждые 15 минут		10		Указывает отложенную   работу, из-за   занятости контроллера домена. Превышение порогового значения указывает на возможную перегрузку процессора.
System (Система)		Processor Queue Length (Длина очереди к процессо-РУ)		Каждую минуту		Шесть средних значений в течение пяти интервалов		Процессор недостаточно быстр, чтобы обрабатывать запросы по мере их поступления. Если топология репликации правильна, и данное состояние не вызвано отказами другого контроллера домена, рассмотрите возможность обновления процессора.
Memory (Память)		Available MBytes (Доступные мегабайты)		Каждые 15 минут		4 Мб		Указывает, что система исчерпала доступную память. Вероятен надвигающийся отказ в работе службы.
Processor (Процессор)		% Processor Time (Instance=_Total) (% времени процесора)		Каждую минуту		85 % от следнего значения в течение  трех интервалов		Указывает на перегрузку центрального процессора. Определите, вызвана ли перегрузка процессора службой Active Directory, исследуя объект Process, счетчик % Processor Time, Isass instance.
System (Система)		Context Switches/sec (Переключение контекста/ секунда)		Каждые 15 минут		70000		Указывает на чрезмерное количество переходов. Возможно, что работает слишком много приложений шщ служб, или их нагрузка на систему слишком высока. Рассмотрите возможность разгрузки системы от части этих требований.
System (Система)		System Up Time (Время работы системы)		Каждые 15 минут				Важный счетчик, показывающий надежность контроллера домена.

Предостережение. Приведенные выше значения основаны на пороговых значениях, которые были рекомендованы компанией Microsoft на момент печати этой книги, и должны рассматриваться как предварительные значения. Информация содержится в руководстве Directory Services Guide комплекта Microsoft Windows Server 2003 Resource Kit. Свежую информацию о выпуске комплекта ресурсов смотрите по адресу http:// www.microsoft.com/windowsserver2003/techinfo/reskit/reso urcekit.mspx.

также требуют некоторого дополнительного планирования

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

Наличие GC-сервера в сети является критическим для обслуживания входа в систему клиентов в домене, работающем на функциональном уровне Windows 2000 native (или на более высоком) или при использовании основных имен пользователя (UPN). Наличие GC-сервера критично, если вы развернули Microsoft Exchange Server 2000. В этом случае вам придется сконфигурировать дополнительные GC-серверы в этом месте, пока не воссоздадите отказавший контроллер домена. Например, если выйдет из строя единственный GC-сервер, расположенный в сайте, где у вас работает Exchange Server 2000, то вам придется сконфигурировать один из других контроллеров домена, расположенных в том же сайте, как GC-сервер, и восстановить как можно быстрее отсутствующие функциональные возможности.

Генерация топологии репликации

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

Концепции Active Directory

Операционная система Microsoft Windows Server 2003 содержит самую последнюю реализацию службы каталога, разработанную компанией Microsoft - Active Directory. Впервые появившись в Microsoft Windows 2000, служба каталога Active Directory, выпущенная с Windows Server 2003, была усовершенствована, а ее качество улучшено.

Примечание. В этой книге использование термина «Windows Server 2003» относится к тем членам семейства продуктов Microsoft Windows Server 2003, которые поддерживают службу каталога Active Directory: Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition.

Если вы читаете книгу в своем местном книжном магазине, задаваясь вопросом о новых функциях Active Directory в Windows Server 2003, то эта глава познакомит вас с ними. Здесь дается также краткий обзор ключевых функций Active Directory и объясняется, зачем нужно реализо-вывать эти функции в среде предприятия, управляемого Windows Server 2003. Если вы решили реализовать службу Active Directory или уже поддерживаете инфраструктуру Active Directory, остальная часть этой книги даст вам ответы на многие ваши вопросы об этом продукте. Она предоставит информацию, необходимую для планирования, реализации и сопровождения инфраструктуры вашей службы Active Directory. Давайте начнем.

Компоненты службы каталога Active Directory

Служба каталога Active Directory Microsoft Windows Server 2003 существует на двух уровнях: физическом и логическом. В терминах физической структуры Active Directory представляет собой файл, расположенный на жестком диске сервера и на жестком диске каждого контроллера домена, который содержит эту службу. Логическая структура Active Directory представляет собой контейнеры, которые используются для хранения объектов службы каталога (разделов каталога, доменов и лесов) на предприятии. Разделы каталога, домены и леса в виде байтов информации хранятся в физических компонентах службы каталога. В этой главе вы узнаете о физическом проявлении службы каталога Active Directory. Затем вы познакомитесь с логической структурой реализации службы Active Directory. Хорошее понимание физической структуры службы каталога важно, но знание логической структуры является непременным условием успешной реализации и управления инфраструктурой вашей службы. Именно с логической структурой службы каталога вы будете ежедневно взаимодействовать.

---

---