Перемещение учетных записей компьютеров
Учетные записи компьютеров, которые постоянно находятся в домене ресурсов Windows NT 4, включают серверы-члены домена с Windows NT 4 Server, а также компьютеры с Windows NT Workstation 4, Windows 2000 Professional и Windows XP Professional. При модернизации учетных записей будут клонированы все учетные записи компьютеров из исходного домена в OU целевого домена.
Примечание. Вы не сможете переместить учетную запись контроллера домена, потому что нельзя изменить домен, к которому принадлежит контроллер домена с Windows NT 4 без повторной установки операционной системы. Контроллеры домена должны быть «переведены» в домен Windows Server 2003. Это «перевод» выполняется путем обновления операционной системы до Windows Server 2003 и последующим назначением компьютера на роль контроллера домена в целевом домене. После обновления операционной системы можно не устанавливать Active Directory, а оставить модернизированный сервер членом домена в целевом домене. ,
Чтобы переместить учетные записи компьютеров с помощью инструмента ADMT, выполните следующие действия.
Откройте Computer Migration Wizard (Мастер модернизации компьютеров).
Выберите исходный и целевой домены.
В исходном домене выберите учетные записи компьютеров, которые нужно перенести.
Выберите в целевом домене организационные единицы OU, в которые нужно перенести учетные записи компьютеров.
Выберите любые компьютерные объекты, для которых нужно переместить защиту учетных записей. При этом обновятся списки разграничительного контроля доступа (DACL) для ресурсов, расположенных на перенесенных компьютерах, новыми идентификаторами SID целевых доменов для учетных записей перемещенных групп и пользователей. Доступны следующие объекты:
• файлы и папки;
• локальные группы;
• принтеры;
• системный реестр;
• совместно используемые ресурсы;
• пользовательские профили;
• пользовательские права.
Совет. Если вы решите не переводить защиту для перечисленных выше объектов в процессе выполнения Computer Migration Wizard, это можно сделать позже, используя Security Translation Wizard (Мастер перевода защиты) в инструменте ADMT. В состав мастера перевода защиты входит такое же окно Translate Objects (Перевести объекты), как и в мастере модернизации компьютеров. Вначале мастер перевода защиты спрашивает о том, хотите ли вы перевести защиту для перемещенных объектов. Если мастер перевода защиты выполняется после модернизации учетных записей компьютеров, выберите опцию Previously Migrated Objects (Ранее перемещенные объекты).
Установите перезапуск перемещенного компьютера. Чтобы переместить компьютерную учетную запись с одного домена на другой, инструмент ADMT посылает агента, чтобы сделать изменение на самом компьютере. Процесс модернизации компьютерной учетной записи завершается после перезапуска перемещенного компьютера. Инструмент ADMT позволяет задать интервал времени между окончанием работы мастера и перезапуском компьютера.
Выполните Computer Migration Wizard (Мастер модернизации компьютеров). После окончания его работы щелкните на View Dispatch Log (Просмотр журнала отправки), чтобы проверить урпешность работы агента отправки (dispatch agent). Этот компонент обновляет членство компьютера в домене, а затем перезапускает компьютер. Журнал регистрации отправки агента полезен для поиска неисправностей при неудавшейся модернизации учетной записи компьютера.
Перемещение учетных записей пользователя
Перемещение учетных записей пользователей не делается за один раз. Было бы неплохо тщательно спланировать порядок этого перемещения и согласование во времени. Поскольку в процессе перехода будет сохраняться доступ к ресурсам, связанным с Windows NT 4, этот процесс можно растянуть на дни, недели или месяцы. При перемещении учетных записей пользователя следует иметь в виду следующее.
Сколько новых пользователей сможет поддерживать одновременно ваша ГГ-группа?
Какой набор пользователей должен перемещаться вместе?
Какой набор пользователей не сможет за определенное время приспособиться к неудобствам реструктуризации домена?
Этими соображениями нужно руководствоваться при определении порядка и согласования во времени процесса модернизации учетных записей пользователей. На первом шаге выбираются пользователи, которые будут перемещаться одновременно, и время выполнения модернизации.
Фактическое перемещение учетных записей пользователя процедурно очень похоже на перемещение учетных записей глобальных групп.
Чтобы переместить учетные записи пользователя с Windows NT 4 на Windows Server 2003 и в Active Directory с помощью User Account Migration Wizard инструмента ADMT, выполните следующие действия.
Выберите исходные и целевые домены.
Выберите учетные записи пользователей в Windows NT 4, которые вы хотите переместить.
Выберите OU-адресата в целевом домене.
Подтвердите, что вы на самом деле хотите переместить пароли учетных записей пользователей. Используя ADMT, вы можете выбрать одно из следующих действий.
Создание новых, сложных паролей. Создается текстовый документ (формат значений, отделенных запятой, [.csv]), который устанавливает соответствие между пользователями и новыми паролями, затем решается задача связывания паролей с мигрированными пользователями.
Установление пароля, совпадающего с именем пользователя. Пароль устанавливается на значение username (имя пользователя). Поскольку эта опция и описанная выше создают риск для безопасности, то для перемещенного пользователя в целевом домене устанавливается атрибут User Must Change Password At Next Logon (Пользователь должен изменить пароль при следующем входе в систему).
Перемещение учетных записей служб
После перемещения учетных записей компьютера на целевой домен можно завершать вторую стадию процесса перемещения учетных записей служб. В начале процесса модернизации домена ресурсов вы идентифицировали учетные записи служб, которые использовались для оперирования службами серверов-членов домена. Теперь вы будете переносить учетные записи служб домена ресурсов с Windows NT 4 на целевой домен Windows Server 2003. Эта процедура гарантирует, что все службы, не выполняющиеся под LSA, будут запускать требуемые службы после того, как сервер-член домена переместится в целевой домен.
Чтобы переместить учетные записи служб, используя ADMT, выполните следующие действия.
Откройте User Account Migration Wizard (Мастер модернизации учетных записей пользователя).
Выберите исходные и целевые домены.
Выберите учетные записи служб, которые нужно переместить.
Совет. Если вы не помните имена учетных записей ранее идентифицированных учетных записей служб, можно просмотреть журнал агентов отправки (Dctlog.txt), который расположен в папке %userprofile %\Temp. Если вы вошли в систему Windows
Server 2003 как Migratorl, вы найдете этот файл в папке C:\Documents and Settings\Migratorl\Temp.
Выберите организационную единицу OU в целевом домене, в которую нужно перенести учетные записи служб.
Генерация сложного пароля будет использоваться для модернизации учетных записей служб. Независимо от того, какую опцию модернизации пароля вы выберете в окне Password Options (Опции пароля), инструмент ADMT будет всегда использовать опцию сложного пароля. ADMT распознает, что учетная запись пользователя, которую вы перемещаете, является учетной записью службы, и предоставит ей право входить в систему в качестве службы.
Примечание. Если учетные записи служб, которые вы переносите, имеют локальные права, унаследованные от членства в локальной группе, например, право «log on as a service» (входить в качестве службы), имеющееся у членов локальной группы администраторов. Вы должны установить эти права с помощью Security Translation Wizard (Мастер перевода защиты). В окне Translate Objects (Перевод объектов) мастера перевода защиты выберите объекты Local Groups (Локальные группы) и User Rights (Права пользователя) для перемещаемого сервера-члена домена, содержащего локальную группу, через которую эти права были унаследованы. Это тот компьютер, на котором будет происходить перевод защиты.
Переназначение папки
Active Directory Windows Server 2003 обеспечивает переназначение папки как способ получения выгоды от использования роуминговых профилей при уменьшении пропускной способности сети. Если включена функция переназначения папки, то папки, которые обычно являются частью местного пользовательского профиля, перемещаются из местного профиля и сохраняются на сетевом ресурсе. Например, одна из типичных папок, которая конфигурируется для переназначения папки, — это папка My Documents. Во многих компаниях эта папка является логической папкой, использующейся для переадресования, так как она представляет собой заданное по умолчанию место для хранения пользовательских файлов. Когда эта папка конфигурируется для переназначения, вы сохраняете ее на сетевом ресурсе, где централизованно поддерживается ее резервное копирование и одновременно обслуживается среда конечного пользователя. Переназначение папки полностью прозрачно для конечного пользователя, единственный способ узнать, что папка была переадресована, - посмотреть свойства папки My Documents.
Другая причина переназначения папки состоит в том, что вы можете использовать эту опцию для развертывания стандартной среды рабочего стола вместо использования принудительных пользовательских профилей. Например, можно переадресовать папки Start Menu или Desktop на сетевой ресурс, затем сконфигурировать группу пользователей, использующих одну и ту же папку. Давая всем пользователям разрешения Read (Чтение) к этим папкам, но не давая разрешения Write (Писать), вы можете сконфигурировать стандартный рабочий стол для группы пользователей.
Можно переназначить четыре различные папки в Active Directory Windows Server 2003: Application Data, Desktop, My Documents и Start Menu Переназначение папки конфигурируется в редакторе объектов групповых политик выбором User Configuration (Конфигурация пользователя), далее - Windows Settings (Параметры настройки Windows), затем - Folder Redirection (Перенаправление папаки). Папки перечислены таким образом, что можно сконфигурировать каждую папку отдельно.
Чтобы сконфигурировать папку My Documents для переназначения, найдите объект My Documents в папке Folder Redirection (Переназначение папки), щелкните на нем правой кнопкой мыши, а затем выберите Properties (Свойства). Первая вкладка листа Properties объекта - это вкладка Target (Цель) (см. рис. 13-3).
На этой вкладке имеется три конфигурационные опции. По умолчанию опция Setting (Параметры установки) установлена как Not Configured (He конфигурирована), т.е. папка не переадресована на сетевой ресурс. Две другие опции, предназначенные для конфигурирования, следующие.
Basic - Redirect Everyone's Folder To The Same Location (Основная -переадресовать все папки в одно и то же место). Используется в том случае, если вы хотите создать одно место, куда будут переадресованы все папки. Например, папки всех пользователей, на которых действует эта политика, будут расположены на сетевом ресурсе \ \servernam е \sharenam е.
Advanced - Specify Locations For Various User Groups (Расширенная -указать местоположение для различных групп пользователей). Используется для конфигурирования альтернативных местоположений для переадресованной папки в зависимости от того, какой группе Active Directory принадлежит пользователь. Если опция выбрана, можно назначать альтернативное целевое место расположения папки для каждой группы.
Рис. 13-3. Конфигурирование целевого места расположения папки при ее переназначении
Совет. Нельзя использовать опцию Advanced для назначения альтернативных мест расположения папки для индивидуальных учетных записей пользователя. Помните, что эта групповая политика применяется только к учетным записям пользователя, которые находятся в контейнере, в котором вы конфигурируете групповую политику. Если вы конфигурируете опцию Advanced, чтобы переадресовать групповую папку в определенное место, установка применится только к тем учетным записям пользователей данной группы, которые расположены в данном контейнере. Если группа содержит пользователей из других контейнеров, переназначение папки к ним применяться не будет.
Как только выбраны параметры настройки для переадресования папок, можно сконфигурировать целевое место расположения папки. Имеется несколько опций, предназначенных для выбора места хранения папки.
Redirect To The User's Home Directory (Переадресовать в основной каталог пользователя). Используется для переадресации папки My Documents в основной (домашний) каталог пользователя, который определен в свойствах учетной записи пользователя. Используйте эту опцию, только если вы уже создали основной каталог. Если основной каталог не создан, конфигурирование этой опции его не создаст. Опция доступна только для папки My Documents.
Create a Folder For Each User Under The Root Path (Создать папку для каждого пользователя в корневом каталоге). Используется для указания корневого каталога, в котором будут храниться папки. Когда вы выбираете эту опцию, папка будет создана в корневом каталоге каждого пользователя. Имя папки будет основано на переменной входа в систему %username %.
Redirect To The Following Location (Переадресовать по следующему адресу). Используется для указания корневого каталога и места расположения папки для каждого пользователя. Вы можете использовать UNC-путь или путь к локальному диску. Используйте переменную %username % для создания индивидуальных папок. Эта опция используется также для переадресации нескольких пользователей к одной и той же папке. Например, если нужно сконфигурировать стандартное Start Menu для группы пользователей, можно указать для всех один и тот же файл.
Redirect To The Local Userprofile Location (Переадресовать в место расположения локального профиля пользователя). Эта установке является заданной по умолчанию конфигурацией, если никакие политики не включены. После установки опции папки не будут переадресовываться на сетевой ресурс.
Вы можете также сконфигурировать другие параметры настройки для переадресованных папок. Чтобы сделать это, щелкните на вкладке Settings в окне Properties объекта (см. рис. 13-4).
Рис. 13-4. Конфигурирование параметров настройки переназначения папки
Вкладка Settings ( Параметры настройки) имеет несколько опций конфигурации.
Grant The User Exclusive Rights To foldername (Предоставить пользователю исключительные права на имя папки). Предоставляет пользователю и системной учетной записи полный контроль над папкой. Учетная запись Administrator (Администратор) не будет иметь никакого доступа к этой папке. Если вы очистите флажок, то разрешения на доступ к папке будут сконфигурированы на основе унаследованных разрешений.
Move The Contents Of foldername To The New Location (Переместить содержимое папки имя папки в новое место). Перемещает текущее содержимое переадресованной папки в целевое место расположения. Если опция не выбрана, содержимое текущей папки не будет скопировано в целевое место расположения.
Policy Removal (Удаление политики). Используется для выбора действий в случае удаления политики. Если вы примете заданную по умолчанию опцию Leave The Folder In The New Location When Policy Is Removed (Оставить папку в новом месте, когда политика удалена), то содержимое переадресованной папки не будет перемещено в локальный пользовательский профиль, если политика удалена. Выбор опции Redirect The Folder Back To The Local Userprof ile Location When Policy Is Removed (Переадресовать папку назад к месту расположения локального профиля пользователя, когда политика удалена) переместит содержимое папки, когда политика будет удалена.
My Pictures Preferences (Предпочтения, касающиеся папаки My Pictures). Эта установка используется для конфигурирования того, будет ли папка My Pictures включена в переназначение папки My Documents.
Когда вы используете переназначение, чтобы переадресовать папку My Documents, содержимое папки не копируется на сервер и обратно, как это делается в случае с роуминговыми пользовательскими профилями. Содержимое папки расположено на сервере, как и любые другие данные сетевого ресурса. Следовательно, часть содержимого папки пересекает сеть только тогда, когда пользователь открывает файл в папке. Это справедливо и для папки Desktop (Рабочий стол). Если на рабочем столе имеется большой файл, то этот файл хранится на сетевом ресурсе и копируется на компьютер клиента, когда пользователь открывает файл. Тот факт, что данные пересекают сеть только по требованию, может значительно улучшать выполнение входа в систему, особенно если у вас имеется большое количество пользователей, одновременно загружающих свои роуминговые профили.
Одно из преимуществ использования пользовательских профилей для сохранения папок типа папки My Documents состоит в том, что после начального входа в систему на рабочей станции копия пользовательского профиля всегда сохраняется в местном масштабе, т.е. если сервер профиля недоступен или рабочая станция отключена от сети, то профиль, укомплектованный папкой My Documents, будет доступен на рабочей станции. Когда рабочая станция повторно связывается с сетью, изменения, сделанные к пользовательскому профилю, копируются на сервер.
Вы можете достичь этого, комбинируя переназначение папки с автономными файлами. Автономные файлы доступны на рабочих станциях с системами Windows 2000, или более поздними, и могут использоваться для поддержки синхронизированной копии общей папки между локальной рабочей станцией и сетевым ресурсом. По умолчанию переадресованные папки сконфигурированы для автономного использования с клиентами, имеющими систему Windows XP Professional. Если имеются клиенты с системой Windows 2000, можно щелкнуть правой кнопкой мыши на папке My Documents, расположенной на рабочем столе, и выбрать Make Available Offline (Сделать доступным в автономном режиме). Включение автономных файлов означает, что переадресованная папка будет скопирована клиентам, делая папку доступной даже в том случае, если сетевое место, в которое была переадресована папка, недоступно.
Планирование делегирования администрирования
Active Directory Windows Server 2003 предоставляет средства, предназначенные для делегирования административных разрешений в вашем домене. Однако вместе с положительными сторонами делегирования разрешений вы получаете риск назначения неправильных разрешений. Пользователям можно предоставить слишком большое количество разрешений, позволяющее им делать в Active Directory то, что им делать не положено. Пользователям можно предоставить слишком малое количество разрешений, не позволяющее делать то, что они должны делать. Создание структуры делегирования, которая обеспечит пользователей точными разрешениями, в которых они нуждаются, требует серьезного планирования. Ниже приведены некоторые советы, помогающие это сделать.
Тщательно документируйте административные требования для всех потенциальных администраторов. В большинстве компаний вы обнаружите, что имеются различные группы, которые нуждаются в некоторых административных разрешениях в домене. Если компания использовала Windows NT, многие из этих пользователей могли быть членами группы Domain Admins. Документируя административные задачи, которые эти пользователи должны выполнять, вы обнаружите, что на самом деле они нуждаются в гораздо более низком уровне доступа. Часто единственный способ документирования уровня административных разрешений, в которых нуждается каждая группа, состоит в документировании всей административной работы, которую они делают каждый день. Документируя действия, которые администраторы должны выполнять, вы смбжете разработать точные разрешения, которые для этого следует иметь.
Перед тем как сделать какие-либо изменения в производственной среде, проверьте все модификации защиты в испытательной среде. Создание неправильной конфигурации защиты может иметь серьезные последствия для вашей сети. Используйте испытательную лабораторию для гарантии того, что модификации разрешений отвечают необходимым требованиям, но не дают разрешений, которые не являются необходимыми.
Используйте Effective Permissions (Фактические разрешения) в окне Advanced Security Settings (Дополнительные параметры настройки защиты) для мониторинга и проверки разрешений, которые имеют пользователи. Окно Effective Permissions является отличным новым инструментом службы Active Directory Windows Server 2003, который может использоваться для определения точных разрешений пользователя или группы. Используйте этот инструмент в испытательной среде для гарантии того, что ваша конфигурация точна, а затем используйте его в производственной среде, чтобы удостовериться, что ваша реализация соответствует плану.
Документируйте все разрешения, которые вы назначаете. Из всех задач, возложенных на сетевых администраторов, документирование изменений, сделанных в сети, относится к самым неприятным, потому что это очень утомительно и кажется не особо важным. В результате документация часто оказывается неполной или устаревшей. Единственный путь эффективного управления конфигурацией защиты вашей сети состоит в том, чтобы документировать начальную конфигурацию, а затем взять обязательство обновлять документацию всякий раз, когда один из первоначальных параметров настройки изменен.
Планирование модернизации
Чтобы гарантировать успешный переход к Windows Server 2003 и Active Directory, затратьте достаточно усилий на его планирование, будь то оперативное обновление контроллеров домена или полная реструктуризация доменной модели. Конечным результатом будет полное описание всех задач, которые нужно выполнить в процессе модернизации. После проверки этот план будет служить сценарием, по которому вы выполните многочисленные и разнообразные задачи модернизации своего домена.
Планирование распределения программ через групповые политики
Использование групповых политик для управления программным обеспечением может уменьшить усилия, необходимые для распределения и обслуживания программного обеспечения на компьютерах клиента. Однако извлечение выгоды от применения этого инструмента усложняется
для большой компании с несколькими различными программными конфигурациями пользовательских рабочих столов. Развертывание групповых политик для наиболее эффективного управления программным обеспечением требует осторожного планирования. Этот раздел посвящен тому, что вы должны учитывать при выполнении этого планирования.
Один из факторов, который вы должны учитывать при развертывании приложений, - необходимость публикации приложения пользователям или компьютерам. Если большинство компьютеров являются общедоступными и каждый пользователь требует специфического пакета программ, то вы должны назначить политику на компьютеры. При назначении политики программное обеспечение полностью установится на рабочую станцию при ее следующей перезагрузке и будет доступно всем пользователям. Назначение пакета программ на компьютеры обеспечивает больше опций для управления пропускной способностью сети. Используя эту опцию, можно сконфигурировать групповую политику в течение дня, а затем попросить пользователей (или использовать удаленный инструмент), чтобы они перезагрузили рабочие станции в конце обычного рабочего времени.
Если какой-либо пакет программ требуется только нескольким пользователям, то более эффективным является назначение или публикация приложения для учетных записей пользователей. В некоторых случаях пакет программ должен быть распределен пользователям, принадлежащим нескольким OU. Наилучшим способом для этого является назначение групповой политики на высшем уровне иерархии Active Directory с последующей фильтрацией применения объекта GPO с помощью групп защиты.
Другое важное решение, которое надо принять при планировании распределения программ состоит в том, сколько объектов GPO следует использовать. Одна из крайностей состоит в том, что можно использовать один объект GPO для распределения всего программного обеспечения в пределах определенного контейнера, это улучшит выполнение входа в систему клиента, но может создать сложные конфигурации GPO-объектов. Другая крайность состоит в использовании множества GPO-объектов, каждый из которых распределяет единственное приложение. Это может оказать влияние на процесс входа в систему клиентов, потому что компьютер должен читать множество объектов GPO. Компании используют разнообразные подходы для решения этой проблемы. Типичный подход состоит в том, чтобы создать один объект GPO для установки стандартного набора приложений, в которых каждый нуждается, и которые редко изменяются. Дополнительные объекты GPO создаются для приложений, которые часто обновляются (типа антивирусного программного обеспечения), и для приложений, которые используются маленькими группами пользователей.
Возможно, что вам придется планировать распределение программного обеспечения по сети с низкой пропускной способностью. Во многих компаниях имеются удаленные офисы или удаленные пользователи, которые подключаются к Active Directory, используя медленные сетевые подключения. По умолчанию компонент групповой политики, предназначенный для распределения программного обеспечения, не применяется, если клиент соединяется через сетевое подключение со скоростью передачи меньше 500 Кб/с. Если рабочие станции вашей сети обычно подключены к локальной сети (LAN) и только иногда соединяются через медленное сетевое подключение, это заданное по умолчанию значение приемлемо. Однако если ваши сетевые клиенты соединяются через медленное сетевое подключение, их нужно подготовить, выполнив дополнительное конфигурирование.
Одна из опций оставляет заданное по умолчанию распределение программного обеспечения таким, как оно есть, инициируя полную инсталляцию программного обеспечения, когда пользователь соединяется с LAN. Используйте эту опцию, если клиенты изредка соединяются с вашей LAN. Если клиенты никогда не соединяются с LAN, для распределения программного обеспечения используйте средства вне Active Directory. Например, используя сменные носители информации или через безопасный веб-сайт, если у клиентов есть быстрое подключение к интернету.
У большинства крупных компаний есть способы автоматизировать процесс, предназначенный для компоновки рабочих станций. Компании используют технологии клонирования диска или службу удаленной инсталляции (RIS — Remote Installation Services) для быстрой компоновки стандартного рабочего стола пользователей. Можно использовать эту технологию в комбинации с групповыми политиками, чтобы оптимизировать распределение программного обеспечения. Например, если вы используете инструмент клонирования диска для компоновки рабочих станций клиентов, скомпонуйте компьютер клиента, а затем используйте групповую политику для установки стандартного набора приложений на рабочей станции. Когда это изображение будет развернуто на рабочих станциях, ими можно управлять с помощью групповых политик. Если вы используете RIS для инсталляции программ на клиентских компьютерах, включите управляемое приложение в RIS-изображение для каждого отдела.
Наиболее важный шаг в подготовке к использованию групповой политики для развертывания программного обеспечения состоит в тщательном тестировании каждого программного распределения перед его развертыванием. Большинство компаний поддерживают лабораторию для тестирования распределений, которая содержит рабочие станции, представляющие аналоги тех рабочих станций, которые имеются в производственной среде. Вы можете создать испытательную OU в Active Directory и переместить сюда учетные записи этих компьютеров и некоторые тестируемые учетные записи пользователей. Используйте эту испытательную среду для проверки каждого программного распределения.
Почему следует проводить мониторинг Active Directory?
Традиционная причина проведения мониторинга Active Directory состоит в том, что он идентифицирует потенциальные проблемы прежде, чем они проявятся и закончатся длительными периодами простоя службы. Мониторинг дает возможность поддерживать соглашение об уровне сервиса (service-level agreement - SLA) с вашим клиентом (пользователем сети). В любом случае вы должны следить за «здоровьем» Active Directory, чтобы разрешать возникающие проблемы как можно скорее, до того, как произойдет прерывание работы службы.
Примечание. Соглашение SLA - это контракт между провайдером услуг (вы) и сообществом пользователей, который определяет обязанности каждой из сторон и представляет обязательства, обеспечивающие определенную степень качества и количества уровню функционирования службы. В контексте Active Directory соглашение SLA между отделом информационных технологий (IT ) и сообществом пользователей может содержать такие параметры, как максимально приемлемый уровень времени простоя системы, время входа в систему и время получения ответа на справочный запрос. В обмен на обязательства провайдера услуг обеспечивать определенные стандарты производительности и функциональности системы, сообщество пользователей обязуется придерживаться определенных объемов использования системы, например, иметь не более 10000 пользователей в лесу Active Directory.
Еще одна причина для проведения мониторинга Active Directory состоит в том, что нужно отслеживать изменения инфраструктуры. Увеличился ли размер базы данных вашей Active Directory с прошлого года? Все ли ваши серверы глобального каталога (GC) работают в интерактивном режиме? Сколько времени требуется для того, чтобы изменения, сделанные на контроллере домена во Франции, были реплицированы на контроллер домена в Австралии? Возможно, эта информация не поможет вам предотвратить возникновение сегодняшней ошибки, но она обеспечит вас ценными данными, с которыми вы сможете строить планы на будущее.
Поддержка класса inetOrgPerson
Active Directory Windows Server 2003 теперь поддерживает класс inetOrgPerson в том виде, в каком он определен в документе RFC 2798, который доступен на сайте http://www.faqs.org/rfcs/rfc2798.html. Это дополнение к основной схеме дает возможность администратору Active Directory перемешать объекты inetOrgPerson из других LDAP-катало-гов, а также создавать объекты inetOrgPerson в среде Active Directory Windows Server 2003.
Подъем функционального уровня
После того как вы модернизировали все контроллеры домена до Windows Server 2003, нужно поднять функциональные уровни домена и леса, чтобы ощутить преимущества от обновления сетевой операционной системы. Информацию о функциональных уровнях смотрите в разделе «Представление о функциональных уровнях» далее в этой главе.
Чтобы поднять функциональный уровень домена, выполните следующие шаги на контроллере домена в модернизированном домене.
Откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory).
В дереве консоли щелкните правой кнопкой мыши на домене, функциональность которого вы хотите поднять, а затем щелкните на Raise Domain Functional Level (Поднять функциональный уровень домена).
В пункте Select An Available Domain Functional Level (Выберите доступный функциональный уровень домена) выберите один из вариантов:
чтобы поднять функциональный уровень домена до уровня Windows 2000 native (естественный), щелкните на Windows 2000 Native, а затем щелкните на Raise (Поднять);
чтобы поднять функциональный уровень домена до уровня Windows Server 2003, выберите Windows Server 2003, а затем щелкните на Raise.
После того как вы подняли функциональный уровень домена (по крайней мере, до естественного (native) уровня Windows 2000), вы можете поднять функциональный уровень леса до Windows Server 2003. Это обеспечит функционирование службы Active Directory по всему лесу. Чтобы поднять функциональный уровень леса, выполните следующие действия.
Откройте инструмент Active Directory Domains And Trusts.
В дереве консоли щелкните правой кнопкой мыши на узле Active Directory Domains And Trusts, а затем щелкните на Raise Forest Functional Level (Поднять функциональный уровень домена).
В пункте Select An Available Domain Functional Level (Выберите доступный функциональный уровень домена) выберите 2003 Windows Server, затем щелкните на Raise (Поднять).
Предостережение. Процедура поднятия функционального уровня домена или леса является необратимой. Для восстановления более низкого уровня вы должны будете деинсталлировать Active Directory (при этом после деинсталляции службы на последнем контроллере домена домен будет удален), а затем повторно установить службу каталога.
Чтобы выполнить реструктуризацию домена, целевой домен с Windows Server 2003 должен работать на функциональном уровне native Windows 2000 или Windows Server 2003. Заданный по умолчанию функциональный уровень домен для новой реализации Windows Server 2003 — mixed Windows 2000. Если ваш целевой домен будет включать контроллеры домена с Windows 2000 Server и Windows Server 2003, то вы должны поднять функциональный уровень до уровня native Windows 2000. Если ваш новый домен будет включать только контроллеры домена Windows Server 2003, вы должны выбрать функциональный уровень Windows Server 2003. Имейте в виду, что подъем функционального уровня домена является необратимым процессом, вы не можете понизить его до предыдущего состояния.
Подготовка домена
Подготовка домена очень похожа на подготовку леса. Для этого нужно найти и подготовить держателя роли хозяина инфраструктуры вместо хозяина схемы.
Чтобы подготовить каждый домен для обновления первого контроллера домена с Windows 2000 Server до Windows Server 2003, выполните следующие действия.
Найдите сервер, который является хозяином инфраструктуры. Для этого откройте инструмент администрирования Active Directory Users And Computers, щелкните правой кнопкой мыши на узле домена, а затем щелкните на Operations Masters (Хозяева операций). На вкладке Infrastructure (Инфраструктура) окна Operations Masters узнайте имя текущего хозяина инфраструктуры.
На сервере, функционирующем как хозяин инфраструктуры, вставьте компакт-диск Windows Server 2003 в дисковод CD-ROM.
Откройте командную строку, перейдите на дисковод CD-ROM и откройте папку \I386.
Напечатайте adprep/domainprep. Вы должны быть членом групп Domain Admins (Администраторы домена) или Enterprise Admins (Администраторы предприятия) в Active Directory, или вам должны быть делегированы соответствующие полномочия.
Для проверки выполнения команды откройте Event Viewer (Средство просмотра событий) и поищите ошибки или неожиданные события в системном журнале. Если инструмент adprep/domainprep выполнился без ошибок, значит, вы успешно подготовили домен к обновлению с Windows 2000 Server до Windows Server 2003.
Повторим еще раз, что вы должны подождать до тех пор, пока изменения, сделанные на хозяине инфраструктуры, не будут реплицированы на другие контроллеры домена леса перед обновлением любого из контроллеров домена. Если вы начнете модернизировать один из контроллеров домена прежде, чем изменения будут реплицированы, сообщение об ошибках уведомит вас, что необходимо подождать.
Теперь, когда домен и лес подготовлены для обновления до Active Directory Windows Server 2003, вы можете начинать.
Подготовка к отказам
Первые шаги в восстановлении системы после отказа выполняются намного раньше, чем случится сам отказ. Если вы не подготовились к потенциальному бедствию надлежащим образом, то проблема поломки аппаратного компонента на контроллере домена может превратиться в реальную катастрофу, вместо того чтобы просто вызвать небольшое неудобство.
Подготовка к бедствию включает просмотр всех элементов, составляющих нормальную сетевую инфраструктуру, а также некоторые спе-
цифичные для Active Directory вещи. Перечисленные ниже процедуры являются критически важными.
Разработайте последовательное создание резервной копии и восстановите управление контроллеров домена. Первый шаг в любом плане восстановления состоит в установке соответствующих аппаратных средств и программного обеспечения для поддержки создания резервных копий контроллеров домена. Затем вы должны создать и протестировать план резервирования и восстановления.
Проверьте свой план резервирования до и после развертывания Active Directory. После развертывания Active Directory ваши пользователи будут требовать, чтобы она была доступна все время. Нужно неоднократно протестировать свой план восстановления. Наилучшим образом управляемая сетевая среда имеет последовательную процедуру тестирования восстановления, в которой каждую неделю тестируется какой-либо компонент этой процедуры. Если бедствие действительно произойдет, вы будете вынуждены восстановить Active Directory настолько быстро, насколько это возможно. Это не должен быть тот случай, когда вы используете процедуру восстановления Active Directory в первый раз.
Разверните контроллеры домена Active Directory с аппаратной избыточностью. Большинство серверов можно заказывать с некоторым уровнем аппаратной избыточности при небольшой дополнительной стоимости. Например, сервер с двойным источником питания, избыточными сетевыми картами и избыточной аппаратной системой жесткого диска должен быть стандартным оборудованием для контроллеров домена. Если эта избыточность предохранит вас хотя бы от одной трудовой ночи по восстановлению контроллера домена, то это будет лучшая инвестиция, которую вы когда-либо делали. Во многих больших компаниях аппаратная избыточность поднята на такой уровень, когда все контроллеры домена связаны с различными цепями питания и подключены к различным коммутаторам Ethernet или сетевым сегментами
Во всех сетях, кроме самых маленьких, вы должны развернуть, по крайней мере, два контроллера домена. Active Directory использует циркулярную (circular) регистрацию для своих журналов регистрации событий, и этот заданный по умолчанию порядок не может быть изменен. Циркулярная регистрация означает, что с единственным контроллером домена вы можете потерять данные Active Directory в случае аварии на контроллере домена, и будете восстанавливать его из резервной копии. Даже в маленькой компании важно иметь несколько контроллеров домена. Если вы хотите, чтобы все пользователи большую часть времени использовали один контроллер домена, вы можете изменить записи DNS, регулируя приоритет каждого контроллера домена. Тогда второй контроллер домена может выполнять другие функции и использоваться только для создания резервной копии на случай аварии на первом контроллере домена.
Хранение данных в Active Directory
Как говорилось в гл. 2, база данных Active Directory хранится в файле по имени Ntds.dit, который по умолчанию расположен в папке %systemroot %\NTDS. Эта папка содержит также следующие файлы.
Edb.chk - файл контрольных точек, который указывает, какие транзакции из журналов регистрации были записаны в базу данных Active Directory.
Edb.log - журнал регистрации текущих транзакций. Имеет фиксированную длину - 10 Мб.
Edbxxxxx.log. После того как Active Directory проработала некоторое время, могут появиться один или более журналов, у которых часть имени файла, обозначенная как ххххх, представляется собой увеличивающийся шестнадцатеричный порядковый номер. Эти журналы являются предшествующими журналами; всякий раз, когда текущий журнал заполнен, он переименовывается в следующий предшествующий журнал, и создается новый журнал Edb.log. Старые журналы автоматически удаляются по мере того, как изменения, представленные в журналах, переносятся в базу данных Active Directory. Каждый из этих журналов также занимает 10 Мб.
Edbtemp.log - временный журнал, который используется тогда, когда заполнен текущий журнал (Edb.log). Новый журнал создается под именем Edbtemp.log, в нем хранятся все транзакции, а затем журнал Edb.log переименовывается в следующий предшествующий журнал. Далее журнал Edbtemp.log переименовывается в журнал Edb.log.
Resl.log и Res2.log — резервные журналы, которые используются только в ситуации, когда на жестком диске заканчивается свободное пространство. Если текущий журнал заполнен, а сервер не может создать новый журнал, потому что на жестком диске нет свободного пространства, сервер подавит любые транзакции Active Directory, находящиеся в настоящее время в памяти, использует место для резервных журналов, а затем завершит работу Active Directory. Размер каждого из этих журналов также 10 Мб.
Совет. Если вы работали с какой-либо из недавних версий Microsoft Exchange Server, то это обсуждение компонентов и процессов базы данных Active Directory будет звучать для вас очень знакомым. База данных Active Directory - это та же самая база данных, которая развертывается с Exchange Server 4 или более поздними версиями.
Каждая модификация к базе данных Active Directory называется транзакцией. Транзакция может состоять из нескольких шагов. Например, когда пользователь перемещается из одной организационной единицы (OU) в другую, в OU-адресате должен быть создан новый объект, а в OU-источнике удален старый объект. Чтобы транзакция была закончена, оба шага должны быть выполнены, если один из шагов потерпит неудачу, вся транзакция должна получить откат, чтобы никакой шаг не был засчитан. Когда все шаги в транзакции выполнены, транзакция считается законченной. Используя модель транзакций, система Windows Server 2003 гарантирует, что база данных всегда остается в согласованном состоянии.
Всякий раз, когда в базе данных Active Directory делается какое-либо изменение (например, изменяется номер телефона пользователя), оно сначала записывается в журнал транзакций. Поскольку журнал транзакций является текстовым файлом, в котором изменения записываются последовательно, то запись в журнал транзакций происходит намного быстрее, чем запись в базу данных. Поэтому использование журналов транзакций улучшает работу контроллера домена.
Как только транзакция была записана в журнал транзакций, контроллер домена загружает страницу базы данных, содержащую пользовательский объект, в память (если она еще не находится в памяти). Все изменения к базе данных Active Directory делаются в памяти контроллера домена. Контроллер домена использует максимально доступный объем памяти, и хранит в памяти максимально большую часть базы данных Active Directory. Контроллер домена удаляет страницы базы данных из памяти только тогда, когда свободная память становится ограниченной, или когда контроллер домена выключается. Изменения, сделанные к страницам базы данных, переписываются в базу данных только тогда, когда сервер мало используется или при его выключении.
Журналы транзакций не только улучшают работу контроллера домена, обеспечивая место для быстрой записи изменений, но и обеспечивают возможность восстановления данных в случае отказа сервера. Например, если было сделано изменение, относящееся к Active Directory, то оно записывается в журнал транзакций, а затем на страницу базы данных, находящуюся в памяти сервера. Если в этот момент сервер неожиданно выключается, то изменения не будут переданы из памяти сервера в базу данных. Когда контроллер домена будет перезапущен, он найдет в журнале все транзакции, которые еще не были переданы в базу данных. Затем эти изменения применятся к базе данных при запуске служб контроллера домена. В процессе этого восстановления используется файл контрольной точки. Файл контрольной точки является указателем на то, какие транзакции из имеющихся в журнале транзакций, были переписаны в базу данных. В процессе восстановления контроллер домена читает файл контрольной точки, определяя, какие транзакции были переданы базе данных, а затем он добавляет в базу данных изменения, которые еще не были переданы.
Планирование. Использование журналов транзакций улучшает работу контроллеров домена и увеличивает возможность восстановления данных в случае неожиданного выключения сервера.
Эти преимущества максимальны, если журнал транзакций и база данных расположены на отдельных жестких дисках.
Служба Active Directory Windows Server 2003 сконфигурирована для циркулярной (circular) регистрации, и эта конфигурация не может быть изменена. При циркулярной регистрации сохраняются только те предшествующие журналы, содержащие транзакции, которые не были переписаны в базу данных. По мере передачи информации из предшествующего журнала в базу данных журнал удаляется. Циркулярная регистрация предотвращает потерю данных в случае сбоя на жестком диске вашего контроллера домена, когда вы будете восстанавливать базу данных из резервной копии. Предположим, что вы выполняете резервное копирование Active Directory каждую ночь, но жесткий диск вашего контроллера домена сломался в 17:00, после того как вы сделали несколько сотен изменений к базе данных в течение дня. По мере выполнения изменений предшествующие журналы транзакций удалялись, поскольку информация из них передавалась в базу данных Active Directory. Когда вы восстановите базу данных к состоянию, соответствующее резервной копии предыдущей ночи, все изменения, которые вы сделали в течение дня, будут потеряны.
Единственный способ предотвратить эту потерю данных состоит в развертывании, по крайней мере, двух контроллеров домена, которые реплицируют информацию друг другу в течение дня. Если произойдет сбой на одном из ваших контроллеров домена, то вы сможете восстановить на нем базу данных из резервной копии, а все вы изменения, сделанные в течение дня, будут скопированы на восстановленный сервер.
Подготовка леса
Чтобы подготовить лес Active Directory для обновления, используйте инструмент администрирования Adprep.exe, чтобы сделать необходимые изменения к схеме Active Directory. Помните, что этот процесс нужно выполнить прежде, чем будет начато обновление до Windows Server 2003.
Чтобы подготовить лес к обновлению первого контроллера домена с Windows 2000 Server до Windows Server 2003, выполните следующие действия.
Найдите сервер, который является хозяином схемы. Для этого откройте оснастку Active Directory Schema Microsoft Management Console (Консоль управления схемой), щелкните правой кнопкой мыши на узле Active Directory Schema (Схема Active Directory), а затем щелкните на Operations Master (Хозяин операций). В диалоговом окне Change Schema Master (Изменение хозяина схемы) найдите имя текущего хозяина схемы.
Сделайте резервную копию хозяина схемы. Возможно, вам потребуется восстановить этот образ, если подготовка леса не будет успешной.
Отсоедините хозяина схемы от сети. Не восстанавливайте подключение до шага 8 в этой процедуре.
Вставьте компакт-диск Windows Server 2003 в дисковод CD-ROM.
Откройте командную строку, перейдите на дисковод CD-ROM и откройте папку \I386.
Напечатайте adprep/forestprep. Вы должны быть членом групп Enterprise Admins (Администраторы предприятия) и Schema Admins (Администраторы схемы) в Active Directory, или вам должны быть делегированы соответствующие полномочия.
Чтобы проверить выполнение команды, откройте Event Viewer (Средство просмотра событий) и проверьте системный журнал на предмет ошибок или неожиданных событий. Если вы найдете сообщения об ошибках, связанные с процессом подготовки леса, займитесь этими ошибками, прежде чем выполнять следующий шаг. Если вы не можете расследовать ошибки, используйте инструмент диагностики Active Directory (напечатав dcdiag в диалоговом окне Run), чтобы проверить функциональность контроллера домена. Если вы не можете разобраться с этими ошибками, восстановите хозяина схемы из резервной копии, исследуйте скорректированные действия и добейтесь, чтобы подготовка леса была закончена успешно.
Если инструмент adprep/forestprep выполнился без ошибок, повторно подключите хозяина схемы к сети.
На этом завершится подготовка леса к обновлению домена с Windows 2000 Server до Windows Server 2003. Следующий шаг состоит в подготовке домена.
Совет. Перед началом подготовки домена подождите, пока изменения, сделанные в хозяине схемы, будут реплицированы хозяину инфраструктуры. Помните, что если серверы находятся в различных сайтах, вы должны ждать дольше, чтобы завершить репликацию. Если вы попробуете выполнить процесс подготов-
ки домена, прежде чем изменения будет реплицированы, сообщение об ошибках уведомит вам, что необходимо еще подождать.
Подготовка перехода к Active Directory
Подготовка перехода от Windows NT 4 к Windows Server 2003 и к Active Directory происходит в три этапа.
Планирование перехода.
Испытание плана перехода.
Проведение экспериментального перехода.
Кроме того, вы должны запланировать время на обслуживание и поддержку, которые следуют за развертыванием. Однако этот этап не является обязательным для проекта перехода службы каталога и в этом разделе не обсуждается.
Дополнительная информация. Для получения дополнительной информации об обновлении службы каталога Windows NT 4 до Windows Server 2003 смотрите статью «Upgrading Windows NT 4.0 Domains to Windows Server 2003 (Обновление доменов Windows NT 4.0 до Windows Server 2003) по адресу http:// www.microsoft.com/technet/prodtechnol/windowsserver2003/ evaluate/cpp/reskit/ad. Имеется также статья «Domain Migration Cookbook (Кухня обновления доменов)» по адресу http://www.microsoft.co7n/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr. Хотя эти статьи написаны для Windows Server 2000, они дают критический анализ техники перехода от Windows NT 4 и включают процедуры и наилучшие методы реализации обновления и реструктуризации. Эти процедуры и методы уместны и в среде Windows Server 2003.
Поиск контроллера домена службы Active Directory
Контроллеры домена, на которых выполняется Windows Server 2003, регистрируют некоторые (или все) записи, описанные выше. Эти записи играют важную роль, когда клиент, на котором выполняется система Windows 2000 или Windows XP Professional, пытается войти в домен. Далее описаны действия, которые выполняются при входе клиента в домен.
Во время входа пользователя компьютер клиента выполняет удаленный вызов процедуры (RPC) запроса местной сетевой службе входа в систему, которая инициирует сеанс входа в систему. Являясь частью RPC-запроса, клиент посылает такую информацию, как имя компьютера, имя домена и имя сайта, службе Net Logon (Вход в сеть).
Служба входа в сеть использует службу указателя доменов (domain locator), чтобы вызвать API-функцию DsGetDcName (), передающую одно из значений параметра флага, перечисленных в таблице 3-3.
Табл. 3-3. Значения параметра флага DsGetDcName
| Значения флага DsGetDcName | Требуемая запись DNS | ||
| DS_PDC_REQUIRED | _ldap._tcp.pdc._msdcs.domainname | ||
| DS_GC_SERVER_REQUIRED | _ldap._tcp.sitename._sites.gc. _msdcs.Forestrootdomainname | ||
| DS_KDC_REQUIRED | _kdc._tcp.sitename._sites.dc ._msdcs.domainname | ||
| DS_ONLY_LDAP_NEEDED | _ldap._tcp.sitename._sites._ msdcs.domainname |
Примечание. Почти всегда функция DsGetDcName включает параметр sitename. Для всех запросов, кроме запроса DS_PDC_REQUIRED, клиент делает начальный запрос, используя параметр сайта. Если DNS-сервер не отвечает на запрос, клиент пошлет тот же самый запрос без параметра сайта. Например, если запрос DS_KDC_REQUIRED не выполнен, клиент пошлет запрос на запись _kdc._tcp.dc._msdcs.forestrootdomain. Это может случиться, если клиент находится на сайте, который не распознан серверами DNS. Клиент может также передать параметр DomainGUID вместо имени домена с помощью функции DsGetDcName (). В этом случае клиент запрашивает запись _ldap._tcp.domainGUID.domains._msdcs.forestname. Это случится только в том случае, если домен был переименован.
DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены. После отсылки каждого пакета клиент ждет в течение 0,1 с, если никакого ответа не получено, он посылает пакет следующему контроллеру домена. Клиент продолжает этот процесс до тех пор, пока не получит допустимый ответ или не перепробует все контроллеры домена.
Когда контроллер домена ответит клиенту, клиент проверяет ответ, чтобы удостовериться, что он содержит запрошенную информацию. Если информация имеется, клиент начинает процесс входа в систему с контроллера домена.
Клиент кэширует информацию контроллера домена, чтобы в следующий раз, когда ему потребуется обратиться к Active Directory, не нужно было снова проходить процесс обнаружения.
Политика блокировки учетных записей
Опции конфигурации политики блокировки учетных записей содержат параметры настройки для порога и продолжительности блокировки пароля, а также для повторной устаовки пароля. В таблице 13-4 описаны все установки.
Табл. 13-4. Политики блокировки учетных записей
| Параметры настройки конфигурации | Объяснение | Значение по умолчанию | |||
| Account Lockout Duration (Продолжительности блокировки учетной записи) | Определяет количество минут, в течение которых заблокированная учетная запись остается заблокированной. После указанного числа минут учетная запись будет автоматически разблокирована. Разблокировать учетную запись должен администратор, установив это значение на 0. Любое значение, отличное от нуля должно быть равно или больше, чем значение, установленное в опции Reset Account Lockout Counter After. Возможные значения: от 0 до 99999 | Никакого значения. Установите значение на 30 минут, если порог блокировки учетной записи установлен на 1, или больше. | |||
| Account Lockout Threshold (Порог блокировки учетной записи) | Определяет количество неудавшихся попыток входа в систему, которое позволяется сделать, прежде чем учетная запись пользователя будет заблокирована. Значение 0 означает, что учетная запись никогда не будет заблокирована. Возможные значения: от 0 до 999 | 0 недопустимых попыток входа в систему. | |||
| Reset Account Lockout Counter After (Сброс счетчика блокировки учетной записи) | Определяет число минут, которые должны пройти после неудавшейся попытки входа в систему, прежде чем счетчик неудачных входов в систему будет сброшен на 0. Любое значение, отличное от нуля, должно быть равно или меньше, чем значение, заданное для Account Lockout Duration. Возможные значения: от 1 до 99999 | Никакого значения. Установите значение на 30 минут, если порог блокировки учетной записи установлен на 1 или больше. |
Политика управления изменениями леса
Первая задача для владельцев леса состоит в определении политики управления изменениями леса. Это политика определяет то, какие изменения могут быть сделаны к конфигурации уровня леса и при каких обстоятельствах. Существует два типа изменений леса: изменения схемы и изменения раздела конфигурации каталога (например, добавление или удаление доменов и разделов приложений каталога, изменение конфигурации сайта).
Политика управления изменениями леса также определяет процедуры тестирования, одобрения и реализации любых изменений леса. Это важно для изменений схемы, поскольку их нелегко восстановить, поэтому любое изменение схемы должно быть совместимо со всеми другими изменениями. Политика управления изменениями леса должна определить процедуру тестирования изменений схемы, и владельцы леса должны поддерживать испытательную лабораторию для тестирования этих изменений. Политика управления изменениями леса должна требовать полного испытания всех изменений уровня леса и гарантировать, что тестирование закончится быстро. Если каждый запрос на изменение будет занимать много времени на обработку, то уровень расстройства пользователей будет постоянно возрастать.
Политика управления изменениями леса должна быть сформирована прежде, чем вы начнете развертывать Active Directory. В компаниях с разнообразными и обособленными деловыми подразделениями пояснение этой политики может быть трудным делом и занять много времени, но и после развертывания Active Directory делать это совсем не легче. Если деловые подразделения не смогут договориться о политике управления изменениями леса перед развертыванием, вы должны принять решение о развертывании нескольких лесов.
Политики Kerberos
Опции конфигурации политик Kerberos содержат параметры настройки билета Kerberos Ticket-Granting Ticket (TGT), сроков службы билета сеанса и параметров настройки временной метки. В таблице 13-5 описаны все установки.
Табл. 13-5. Политики Kerberos
| Параметры настройки конфигурации | Объяснение | Значение по умолчанию | |||
| Enforce User Logon Restrictions (Предписать выполнение ограничений на вход пользователей в систему) | Требует, чтобы центр распределения ключей (Key Distribu tion Center - KDC) подтверждал каждый запрос на билет сеанса по отношению к политике User Rights (Права пользователя) целевого компьютера | Включено. | |||
| Maximum Lifetime For Service Ticket (Максимальный срок пригодности билета службы) | Определяет максимальное время в минутах, в течение которого билет службы пригоден для обращения к ресурсу. Возможные значения: 10, вплоть до значений, меньших или равных значению в минутах параметра Maximum Lifetime For User Ticket, но не превышающих 99999. Значение 0 приведет к тому, что время пригодности билета станет бесконечным, значение Maximum Lifetime For User Ticket будет установлено^на 1, a значение Maximum Lifetime For User Ticket Renewal будет установлено на 23 | 600 минут (10 часов). | |||
| Maximum Lifetime For User Ticket (Максимальный срок службы пользовательского билета) | Определяет максимальное время в часах, в течение которого может использоваться билет TGT. Когда это время истекает, рабочая станция должна получить новый билет TGT. Возможные значения: от 0 до 99999. Значение 0 указывает, что срок службы билета не будет истекать, а опция Maximum Lifetime For User Ticket Renewal будет установлена на значение Not Defined | 10 часов. | |||
| Maximum Lifetime For User Ticket Renewal (Максимальный срок, в течение которого пользовательский билет может быть возобновлен) | Определяет время в днях, в течение которого билет TGT пользователя может быть возобновлен вместо получения нового билета. Значение 0 указывает, что возобновление билета заблокировано | 7 дней. | |||
| Maximum Tolerance For Computer Clock Synchronization (Максимальный допуск в синхронизации компьютерных часов) | Определяет различие между временем на компьютере клиента и временем на часах сервера в минутах, которое допускает протокол Kerberos. Обратите внимание, что эта установка переустанавливается на заданное по умолчанию значение при каждом перезапуске компьютера | 5 минут. | |||
Политики учетных записей должны быть установлены на уровне Domain Security Policy (Политики безопасности домена) на контроллере домена. Эти параметры настройки затрагивают всех пользователей и все компьютеры в домене. Хотя эти политики могут быть сконфигурированы на уровне OU, они не будут влиять на тех, кто входит в систему домена. Если вы устанавливаете политику для OU, она затронет только местную базу данных безопасности для компьютеров, входящих в эту OU. Когда эти политики сконфигурированы на уровне OU, они применяются только тогда, когда пользователи входят в систему в местном масштабе. Когда пользователи входят в домен, политики домена всегда подменяют локальную политику.
Политики ограничения программного обеспечения
В Active Directory Windows Server 2003 имеется один специальный тип конфигурации защиты, которого не было в Active Directory Windows 2000 -это политики ограничения программного обеспечения. Одно из самых больших беспокойств связано с пользователями, запускающими неизвестное или%е пользующееся доверием программное обеспечение. Во многих случаях пользователи запускают потенциально опасное программное обеспечение непреднамеренно. Например, миллионы пользователей запускали вирусы или устанавливали приложения типа «троянский конь», не имея ни малейших намерений выполнять опасное программное обеспечение. Политика ограничения программного обеспечения предназначена для предотвращения таких случаев.
Политика ограничения программного обеспечения защищает ваших пользователей от выполнения опасных программ, определяя, какие приложения можно выполнять, а какие -нет. Эта политика позволяет выполняться любому программному обеспечению, за исключением того, которое вы специально заблокируете. Или можно определить политику, не позволяющую выполнять никакое программное обеспечение за исключением того, которое вы явно позволите выполнять. Хотя вторая опция более безопасна, усилия, необходимые для перечисления всех приложений, которым позволяется выполняться в среде Сложного предприятия, слишком серьезны. Большинство компаний выберут первую опцию, разрешающую выполнение всего программного обеспечения и блокирующую только избранное программное обеспечение. Однако если вы развертываете среду с высоким уровнем безопасности, примените более безопасную опцию.
При создании политики ограничения программного обеспечения можно сконфигурировать пять типов правил, характеризующих приложения, на которые воздействует данная политика.
Hash rules (хэш-правила). Хэш-правило — это криптографический идентификатор, который уникально идентифицирует определенный файл приложения независимо от имени файла или его местоположения. Если в папке Security Levels (Уровни безопасности) был выбран объект Unrestricted (He ограничен), и нужно ограничить выполнение определенного приложения, создайте хэш-правило, используя политику ограничения программного обеспечения. Когда пользователь попытается выполнить это приложение, рабочая станция проверит его хэш-значение и предотвратит выполнение. Если политика блокирует выполнение всех приложений, используйте хэш-правило для допуска определенных приложений.
Certificate rules (Правила сертификата). Можно создавать правила сертификата так, что критерием выбора приложений будет сертификат издателя программного обеспечения. Например, если у вас есть собственное приложение, которое вы сами разработали, назначьте сертификат этому приложению, а затем сконфигурируйте правило ограничения программного обеспечения, состоящее в доверии соответствующему сертификату.
Path rules (Правило путей). Можно создавать правила, основанные на пути, характеризующем место, где расположено выполняемое приложение. Если вы выберете папку, то это правило будет распространяться на приложения, расположенные в этой папке. Можно использовать переменные среды (типа %systemroot %), чтобы определить путь и подстановочные знаки (типа *.vbs).
Registry path rules (Правило пути системного реестра). Можно создавать правила, основанные на месте расположения системного реестра, которые использует данное приложение. Каждое приложение имеет заданное по умолчанию место расположения в пределах системного реестра, где оно хранит специфическую для приложения информацию, позволяющую создавать правила, блокирующие или разрешающие выполнение приложений, основанные на этих ключах системного реестра. В меню не имеется никакой опции, специфичной для системного реестра, предназначенной для создания правил пути системного реестра, но опция New Path Rule (Новое правило пути) позволяет создавать этот уникальный набор правил. При создании новой политики ограничения программного обеспечения формируются четыре заданных по умолчанию правила пути системного реестра. Эти правила конфигурируют неограниченную программную групповую политику для приложений, расположенных в системной корневой папке и в заданной по умолчанию папке программных файлов.
Internet zone rules (Правило зон интернета). Заключительный тип правил основан на интерне-зоне, из которой было загружено программное обеспечение. Например, нужно сконфигурировать правило, позволяющее выполнение всех приложений, загруженных из зоны Trusted Sites (Доверенные сайты), или правило, предотвращающее выполнение любого программного обеспечения, загруженного из зоны Restricted Sites (Ограниченные сайты).
Если вы сконфигурируете свое ограничение так, что все приложения должны выполняться, за исключением указанных приложений, то эти правила определят те приложения, которые не будут выполняться. Если вы создаете более ограничительное правило, блокирующее все приложения, то оно определяет те приложения, которым позволено выполняться.
Политики ограничения программного обеспечения могут быть определены для компьютеров в разделе Computer Configuration\Windows Settings\Security Settings, для пользователей - в разделе User Configuration\Windows Settings\Security Settings. По умолчанию в Active Directory не ус танавливается политики ограничения программного обеспечения. Чтобы создать политику, щелкните правой кнопкой мыши на папке Software Restrictions Policies (Политики ограничений программного обеспечения) и выберите New Software Restrictions Policy (Новая политика). В результате будет создана заданная по умолчанию политика (см. рис. 13-7).
Рис. 13-7. Создание новой политики ограничения программного обеспечения
Папка Security Levels (Уровни безопасности) используется для определения заданного по умолчанию уровня защиты. Внутри папки имеются два объекта: Disallowed (Запрещенный) и Unrestricted (Неограниченный). Если нужно сконфигурировать защиту так, чтобы выполнялись все приложения за исключением специально указанных, щелкните правой кнопкой мыши на объекте Unrestricted и выберите Set As Default (Установить по умолчанию). Если вы хотите задать более ограничительную установку, щелкните правой кнопкой мыши на Disallowed и установите его заданным по умолчанию.
Папка Additional Rules (Дополнительные правила) используется для конфигурирования правил ограничений программного обеспечения. Чтобы сконфигурировать правило, щелкните правой кнопкой мыши на папке Additional Rules и выберите тип правила, которое вы хотите создать. Например, для нового хэш-правила выберите New Hash Rule. Чтобы создать новое хэш-правило, щелкните на кнопке Browse (Обзор) и найдите файл, который вы хотите идентифицировать хэш-значением. При выборе файла хэш-значение файла будет создано автоматически. За-
тем можно сконфигурировать, будет ли это приложение разрешено для выполнения или заблокировано (см. рис. 13-8).
Рис. 13-8. Конфигурирование хэш-правила
Объект Enforcement (Принуждение) используется для определенного указания приложения, на которое оказывается воздействие. Можно сконфигурировать правила, которые будут применяться или ко всем приложениям, или ко всем приложениям, кроме DLL. Правила могут применяться или ко всем пользователям, или ко всем пользователям, кроме местных администраторов.
Объект Designated File Types (Отмеченные типы файлов) определяет все расширения файлов, которые рассматриваются как расширения исполняемых файлов и поэтому подчиняются этой политике. Вы можете добавлять или удалять файловые расширения из этого списка.
Объект Trusted Publishers (Доверенные издатели) используется для определения того, кто может выбирать, является ли издатель доверенным или нет. Вы можете указать всех пользователей, только локальных администраторов или только администраторов предприятия. Вы можете также сконфигурировать, должна ли рабочая станция проверять факт возможной отмены действия сертификата перед выполнением приложения.
Порядковые номера обновлений
Когда объект базы данных модифицируется, то изменению присваивается порядковый номер обновления. Порядковые номера обновления (USN — update sequence number) являются спецификой баз данных сервера. Например, если изменению номера телефона одного из пользователей был назначен номер USN 5555, то следующее изменение базы данных, независимо от изменяемого объекта, будет иметь номер USN 5556. Один номер USN назначается для каждого совершенного изменения. Если в одной модификации
изменено несколько атрибутов (например, адрес, номер телефона и местоположение офиса), то этой модификации назначается только один USN.
Существует три способа использования USN при выполнении модификаций. Во-первых, локальное значение USN сохраняется вместе с атрибутом, который был модифицирован. Локальное значение идентифицирует USN измененного атрибута. Во-вторых, USN используется для атрибута uSNChanged объекта. Этот атрибут хранится с каждым объектом и идентифицирует самый высокий USN для атрибутов данного объекта. Рассмотрим пример. Предположим, что был изменен номер телефона пользователя, и этому изменению был назначен USN, равный 5556. И локальный USN, и атрибут uSNChanged будут установлены на 5556. Если следующая модификация, сделанная в каталоге на том же сервере, состоит в изменении адреса того же самого пользователя, то местный USN на атрибуте адреса и атрибут uSNChanged для пользовательского объекта будут изменены на 5557. Однако местный USN для атрибута номера телефона останется равным 5556, потому что это USN для последней модификации этого конкретного атрибута.
Локальный USN и атрибут uSNChanged относятся как к исходным, так и к реплицируемым обновлениям. В последнем способе USN используется как USN исходной модификации атрибута. Это значение устанавливается только для исходных модификаций, оно копируется на все другие контроллеры домена как часть репликации атрибутов. Когда на сервере изменяется номер телефона пользователя, то USN этого изменения назначается равным исходному значению USN. Когда измененный номер телефона копируется на другой контроллер домена, исходный USN посылается вместе с модификацией, и это значение не изменяется на контроллере домена адресата. Локальный USN и атрибут uSNChanged будут изменены на контроллере домена адресата, но исходный USN не изменится до тех пор, пока сам атрибут не будет снова модифицирован. Исходный USN используется для демпфирования распространения, которое рассматривается далее в этой главе.
Право собственности на объекты Active Directory
Каждый объект в Active Directory должен иметь владельца. По умолчанию пользователь, создавший объект, является его владельцем. Владелец объекта имеет право изменить разрешения на доступ к объекту, что означает, что даже если владелец не имеет полного управления объектом, он всегда может изменить разрешения на доступ к объекту. В большинстве случаев владельцем объекта является определенная учетная запись пользователя, а не учетная запись группы. Единственное исключение - это когда объект создан членом группы Domain Admins. В этом случае владельцем объекта назначается группа Domain Admins. Если владелец объекта является членом локальной группы Administrators, a не членом группы Domain Admins, то владельцем объекта назначается группа Administrators.
Чтобы определить владельца объекта Active Directory, обратитесь к свойствам объекта, используя соответствующий инструмент Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Owner (Владелец). На рисунке 9-8 показано окно инструмента Active Directory Users And Computers.
Рис. 9-8. Просмотр владельца объекта Active Directory
Если вы имеете разрешение Modify Owner (Модификация владельца) для объекта, вы можете использовать это окно для изменения владельца объекта. Вы можете назначить владельцем свою собственную учетную запись, учетную запись другого пользователя или группу. Эта последняя возможность уникальна для Active Directory Windows Server 2003. В Active Directory системы Microsoft Windows 2000 вы сами можете стать владельцем или назначать владельцем другого участника безопасности.
Предопределенные шаблоны защиты
Чтобы облегчить применение защиты, компания Microsoft создала разнообразные предопределенные шаблоны защиты. Эти шаблоны сконфигурированы в соответствии с категориями защиты, такими как default (заданная по умолчанию), secure (безопасная) и high security (сильная защита). Шаблоны хранятся в папке %systemroot %\security\templates. Когда вы устанавливаете на компьютере системы Windows Server 2003 или Windows XP Professional, к компьютеру применяется шаблон Setup Security.inf. Этот шаблон различен для рабочих станций и серверов, он также зависит от того, была ли ваша операционная система установлена как обновление или как чистая инсталляция. Вы можете повторно применять шаблон защиты в любое время после начальной инсталляции. Например, если изменяются параметры настройки защиты на компьютере и нужно вернуть заданные по умолчанию параметры, можно повторно применить этот шаблон. Он создается в процессе установки для каждого компьютера и должен применяться только локально. Он содержит много параметров настройки, которые не конфигурируются в составе какого-либо другого шаблона. Следовательно, не нужно ис-
пользовать групповые политики для развертывания заданного по умолчанию шаблона. Их можно использовать для развертывания дополнительных шаблонов защиты, которые могут изменять некоторые параметры настройки, сконфигурированные в заданном по умолчанию шаблоне.
Если вы устанавливаете на компьютере системы Windows Server 2003 или Windows XP Professional как обновление предыдущей операционной системы, заданные по умолчанию шаблоны на компьютере не применяются. Это гарантирует, что после обновления будут поддерживаться любые предыдущие конфигурации защиты.
Если заданные по умолчанию параметры настройки защиты не отвечают вашим потребностям, примените другие конфигурации защиты, используя шаблоны. Они предназначены для использования на тех компьютерах, где уже выполняются заданные по умолчанию шаблоны защиты. Компания Microsoft включила следующие шаблоны в систему Windows Server 2003.
Compatwsinf. Этот шаблон может применяться к рабочим станциям или серверам. Windows Server 2003 сконфигурирован так, чтобы быть более безопасным, чем предыдущие версии Windows. Это означает, что некоторые приложения, работающие в предыдущих операционных системах, не будут выполняться в системах Windows Server 2003 или Windows XP Professional. Особенно справедливо это для несер-тифицированных приложений, которым требуется доступ пользователя к системному реестру. Один из способов выполнить такие приложения состоит в том, чтобы сделать пользователя членом группы Power Users (Полномочные пользователи), которая имеет более высокий уровень разрешений, чем обычный пользователь. Другой вариант состоит в том, чтобы ослабить параметры настройки защиты на выбранных файлах и ключах системного реестра так, чтобы группа Users (Пользователи) имела больше разрешений. Шаблон Compatws.inf может использоваться для применения второго варианта. Применение этого шаблона изменяет заданный по умолчанию файл и разрешения системного реестра так, чтобы члены группы Users могли выполнять большинство приложений.
Securewsinf и Securedcinf. Эти шаблоны обеспечивают усиленную защиту для политики учетных записей, аудита и разрешения на доступ к системному реестру. Они ограничивают использование NTLM-аутентификации, включая подписи на серверах пакетов блока серверных сообщений (Server Message Block - SMB). Шаблон Securews.inf применим для любой рабочей станции или сервера, а шаблон Securedcinf - только для контроллеров домена.
Hisecwsinf и Hisecdc.inf. Эти шаблоны последовательно увеличивают защиту, которая создается другими шаблонами. Защита усиливается в областях, затрагивающих сетевые протоколы связи. Они должны использоваться только в сетях, включающих компьютеры с системами Windows Server 2003, Windows 2000 или Windows XP, и должны быть протестированы и применены на всех компьютерах, чтобы убедиться, что все они работают на одном и том же уровне защиты. Шаблон Hisecws.inf применяется для любой рабочей станции или сервере, а шаблон Hisecdc.inf - только для контроллеров домена.
DC security.inf. Этот шаблон применяется автоматически всякий раз, когда сервер-член домена с системой Windows Server 2003 назначается контроллером домена. Он дает возможность администратору повторно применить начальную защиту контроллера домена, если возникает такая потребность.
Notssid.inf. Этот шаблон удаляет идентификатор безопасности SID группы безопасности Terminal Users (Пользователи терминала) из всех «тисков управления разграничительным доступом DACL на сервере. Используется для повышения безопасности терминальных серверов, потому что все пользователи терминального сервера будут иметь разрешения, полученные через членство индивидуальных пользователей и групп, а не через общую группу безопасности Terminal Users. Этот шаблон включен только в Windows Server 2003, который сконфигурирован как терминальный сервер в режиме приложений.
Rootsec.inf. Этот шаблон переустанавливает заданные по умолчанию разрешения системной корневой папки и распространяет унаследованные разрешения на все подпапки и файлы, расположенные в корневой папке. Применение этого шаблона не изменяет явные разрешения, назначенные на файлы.
После того как вы решили, какой шаблон защиты использовать, ими можно управлять через редактор объектов групповых политик. Если нужно установить один из настроенных шаблонов, щелкните правой кнопкой мыши на папке Security Settings и выберите Import Policy (Импорт политики). По умолчанию диалоговое окно откроет папку %systemroot %\Security\Templates, где расположены предопределенные шаблоны защиты. Когда вы выберете один из шаблонов, он загрузится в редактор объектов групповых политик. Затем можно применить эту групповую политику к выбранному контейнерному объекту. Вы можете изменить импортированный шаблон защиты так, чтобы он точно удовлетворял вашим требованиям. После этого экспортируйте шаблон, чтобы он был доступен для импортирования в другую групповую политику.
Предотвращение перезагрузки контроллера домена
Перегрузка контроллера домена по сценарию обновления домена происходит, когда у вас есть клиентские компьютеры с системами Windows 2000 Professional и/или Windows XP Professional в домене, основанном на системе Windows NT 4, и вы модернизируете PDC до Windows Server 2003. Такая ситуация может привести к перегрузке единственного контроллера домена, имеющего Windows Server 2003. Это происходит потому, что компьютеры с системами Windows 2000 Professional и Windows XP Professional, присоединяющиеся к домену Active Directory, для выполнения любых действий, требующих контакта с контроллером домена, будут взаимодействовать только с контроллерами домена, на которых установлена система Windows 2000 Server или Windows Server 2003. Если у вас есть обновленные клиентские компьютеры или новые, на которых выполняются вышеупомянутые операционные системы, вы должны предпринять некоторые шаги для устранения риска, связанного с появлением единственной точки возможного отказа (модернизированный PDC).
Предотвратить перезагрузку контроллера домена можно, если быстро добавить в сеть контроллеры домена с Windows Server 2003. Если не предполагается немедленного обновления всех BDC с системой Windows NT 4 Server или добавления новых контроллеров домена с Windows
Server 2003, можно изменить системный реестр на модернизированном PDC таким образом, чтобы контроллер домена Windows Server 2003 эмулировал поведение контроллера домена с системой Windows NT 4 для всех клиентов, на которых выполняются Windows 2000 Professional и Windows ХР Professional. Чтобы включить режим эмуляции Windows NT 4, выполните следующие действия на PDC с модернизированной системой Windows NT 4.
После того как компьютер был модернизирован от Windows NT 4 до Windows Server 2003, до начала установки Active Directory откройте редактор системного реестра (напечатайте regedit в диалоговом окне Run).
Создайте значение NT4EMULATOR в ключе системного реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentContro lSet\Services\ Netlogon\Parameters.
Выберите Edit (Правка), затем New (Новый), а затем DWORD Value (Значение DWORD). Замените имя New Value #1 именем NT 4Emulator и нажмите Enter.
В меню Edit щелкните на Modify(Изменить). В диалоговом окне Edit DWORD Value (Правка значения DWORD) напечатайте 1 в текстовом поле Value Data (Данные), а затем щелкните на ОК.
Сохраните изменения и закройте редактор системного реестра.
Запустите мастер инсталляции Active Directory, напечатав dcpromo в диалоговом окне Run.
Повторите этот процесс на каждом из недавно установленных контроллеров домена с Windows Server 2003 или на каждом контроллере домена с модернизированной системой Windows NT 4, пока не будет введено достаточное количество контроллеров домена с Windows Server 2003, чтобы возможность перегрузки была устранена.
Имейте в виду, что это временное решение временной проблемы. После того как все запланированные контроллеры домена с Windows NT 4 будут модернизированы до Windows Server 2003, вы должны или установить значение NT 4Emulator на 0x0, или удалить ключ системного реестра для каждого из модифицированных компьютеров.
Практический опыт. Нейтрализация эмуляции NT 4
Для некоторых компьютеров нужно будет изменить системный реестр так, чтобы они игнорировали установку NT 4EMULATOR. Это компьютеры с Windows Server 2003 или Windows 2000, которые будут назначены контроллерами домена, и компьютеры с Windows 2000 Professional или Windows XP Professional, которые будут использоваться для управления доменом Active Directory. Имеется способ дать им возможность входить в контакт с контроллерами домена Windows Server 2003 как обычно.
Чтобы нейтрализовать установку NT 4EMULATOR, выполните следующие действия.
Запустите редактор системного реестра (напечатайте regedit в диалоговом окне Run).
Создайте значение NeutralizeNT4Emulator в ключе HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters.
Выберите Edit (Правка), затем New (Новый), а затем DWORD Value (Значение DWORD). Замените имя New Value #1 именем NeutralizeNT4Emulator и нажмите Enter.
В меню Edit (Правка) щелкните на Modify (Изменить). В диалоговом окне Edit DWORD Value (Правка значения DWORD) напечатайте 1 в текстовом поле Value Data (Данные), а затем щелкните на ОК.
После того как все BDC с Windows NT 4 будут установлены или модернизированы до Windows Server 2003, обновление можно считать почти законченным. Заключительный шаг состоит в поднятии функционального уровня домена и леса с уровня mixed Windows 2000 (значение по умолчанию) к уровню Windows Server 2003.
Представление о функциональных уровнях
Функциональные уровни используются в Windows Server 2003, чтобы задействовать соответствующий набор функций Active Directory для тех контроллеров домена, которые могут их поддерживать. Уровень функциональности, который вы выберете для вашего предприятия, диктуется версией операционной системы Windows, выполняющейся на контроллерах домена. Функциональные уровни могут быть установлены и для домена, и для леса. Когда уровень леса установлен на функциональный уровень Windows Server 2003, все функции Active Directory доступны.
Концепция функциональных уровней подобна параметрам настройки смешанного и естественного режима, которые были представлены в Windows Server 2000. Эти понятия были расширены в Windows Server 2003, чтобы вместить дополнительные функции Active Directory. Функциональные уровни используются для того, чтобы обеспечить обратную совместимость с контроллерами доменов низкого уровня.
Имеются четыре функциональных уровня домена: Windows 2000 mixed (смешанный) (значение по умолчанию), Windows 2000 native (естественный), Windows Server 2003 interim (временный) и Windows Server 2003. Когда вы модернизируете все контроллеры домена низкого уровня, имеющиеся в домене, до Windows Server 2003, вы должны поднять функциональный уровень этого домена до уровня Windows Server 2003. Подъем функционального уровня домена от смешанного Windows 2000 к естественному Windows 2000 или к Windows Server 2003 задействует такие функции, как SID-History, Universal Groups (Универсальные группы) и вложенные группы.
Имеются три функциональных уровня леса: Windows 2000, Windows Server 2003 interim и Windows Server 2003. Чтобы задействовать все функции Active Directory после того, как все домены леса будут работать на функциональном уровне native Windows 2000 или выше, нужно поднять функциональный уровень леса до уровня Windows Server 2003.
Предостережение. Не поднимайте функциональный уровень леса до уровня Windows Server 2003, если у вас есть контроллеры домена, на которых выполняется система Windows NT 4 Server или Windows 2000 Server. Как только функциональный уровень леса будет поднят до уровня Windows Server 2003, его нельзя вернуть назад на уровень mixed или native Windows 2000, и вы не сможете поддерживать контроллеры домена низкого уровня вашего леса.
Предварительные условия установки Active Directory
Любой сервер, на котором выполняется Windows Server 2003 и который удовлетворяет условиям, описанным в следующем разделе, может содержать Active Directory и стать контроллером домена. Каждый новый контроллер домена фактически является автономным сервером, пока не завершится процесс инсталляции Active Directory. В ходе этого процесса решаются две важные задачи: создается или заполняется база данных каталога и запускается Active Directory, чтобы сервер отвечал на попытки входа в систему домена и на запросы облегченного протокола службы каталога LDAP.
В главе 2 говорилось, что база данных каталога хранится на жестком диске контроллера домена в файле Ntds.dit. В процессе инсталляции Windows Server 2003 файл Ntds.dit сохраняется в папке %systemroot
%\system32 на локальном диске. В процессе инсталляции Active Directory-файл Ntds.dit копируется в место, идентифицированное во время инсталляции, или в заданную по умолчанию папку %systemroot %\NTDS, если не определено другое место. При наличии файла Ntds.dit, скопированного на жесткий диск в процессе инсталляции Windows Server 2003, Active Directory может быть установлена в любое время без необходимости обращаться к инсталляционной среде.
Примечание. В то время как служба Active Directory может быть установлена без доступа к инсталляционной среде, установка сервера доменной системы имен (DNS) и связанных с ним инструментальных средств управления требует инсталляционных файлов. Не забудьте, что в процессе инсталляции компакт-диск Windows Server 2003 должен находиться под руками.
Далее приводятся условия, необходимые для того, чтобы Active Directory могла работать в Windows Server 2003.
Прекращение эксплуатации домена учетных записей
Заключительный шаг в модернизации домена учетных записей к Windows Server 2003 состоит в прекращении эксплуатации исходного домена, которое производится после проверки того, что учетные записи нужных пользователей и групп перемещены к Windows Server 2003, а сетевые службы работают в чистом лесу. Чтобы прекратить эксплуатацию домена учетных записей, контроллеры домена просто выключают. Спустя некоторое время (в течение которого монитор отслеживает любые перерывы в доступе к сети или ресурсам) контроллеры домена или модернизируются до Windows Server 2003, или на них заново устанавливается операционная система Windows Server 2003, а они назначаются контроллерами домена или остаются в роли серверов-членов домена.
Наилучшая практика. Рекомендуется не прекращать эксплуатацию домена учетных записей с системой Windows NT 4 до перемещения домена ресурсов, поскольку совместно используемые локальные группы и локальные группы в доменах ресурсов не смогут разрешать имена своих членов из домена учетных записей. Вместо этого групповое членство для локальной группы будет отображаться как «account unknown (учетная запись неизвестна)». Хотя это не влияет на доступ пользователей к ресурсам, важно не удалять входы «account unknown», потому что это нарушит доступ к ресурсам, сохраненным с помощью идентификатора SID-History. После того как все домены ресурсов будут реструктуризированы, можно прекратить эксплуатацию исходных доменов с Windows NT 4.
Теперь, когда учетные записи глобальных групп и пользователей перемещены, процесс модернизации домена учетных записей завершен. Ваши пользователи входят в домен Windows Server 2003 и легко обращаются к их общедоступным сетевым ресурсам с домена ресурсов Windows NT 4. Благодаря идентификатору SID-History и вашему опыту конечные пользователи не почувствуют, что среда, в которой они работают, является смешанной, и будут работать как обычно. Чтобы завершить проект реструктуризации домена в соответствии с вашим графиком работ, теперь можно перемещать домены ресурсов в Windows Server 2003.
Прекращение эксплуатации исходных доменов
Теперь, когда все домены учетных записей и домены ресурсов были перемещены в Windows Server 2003 и в Active Directory, можно прекратить эксплуатацию исходных доменов Windows NT 4. Ведь единственные компьютеры, оставшиеся в исходных доменах - это контроллеры домена. Если ваш план перехода требует перемещения этих контроллеров домена в целевой домен Windows Server 2003, можно переместить их. Существует довольно сложный процесс перевода контроллеров домена в автономный режим, их обновления, назначения на роль контролера, отмена этой роли, повторного назначения, чтобы сделать их контроллерами домена в новом домене. Будет лучше, если вы убедитесь, что все необходимые данные перемещены с этих серверов, а затем выполните новую инсталляцию операционной системы Windows Server 2003. Заключительная задача состоит в том, чтобы удалить все доверительные отношения, которые были созданы для выполнения модернизации. Используя инструмент Active Directory Domains And Trusts, выберите каждое доверительное отношение с более не существующим доменом системы Windows NT 4 и щелкните на кнопке Remove (Удалить).
Прежде чем начать
Перед началом обновления выполните несколько действий на PDC контроллере с системой Windows NT 4, который должен быть модернизирован.
Очистите базу данных SAM. Помните, что при обновлении домена все в ней будет обновлено до Active Directory. Велика вероятность того, что очистка уменьшит количество учетных записей, которые будут перемещаться в Active Directory, уменьшив тем самым потребное дисковое пространство на контроллерах домена Windows Server 2003. Имейте в виду, что существующая база данных учетных записей пользователей при обновлении до Active Directory может увеличиться в 10 раз. При очищении SAM с помощью инструмента администрирования Windows NT 4 User Manager For Domains (Менеджер пользователей для доменов) или с помощью команды Net User (Пользователь сети) происходит следующее:
удаление дублированных учетных записей пользователей;
объединение дублированных групп учетных записей;
удаление неиспользуемых учетных записей пользователей, групп и компьютеров;
удаление учетных записей локальных групп для ресурсов, которые больше не существуют;
установка комплекта Service Pack 5 для Windows NT 4 или более позднего. Вы можете загрузить все поддерживаемые комплекты обновлений для Windows NT 4 с веб-сайта Microsoft по адресу http://www.microsoft.com/ntserver/nts/downloads/default.asp.
Применение групповых политик к пользователям и компьютерам
Можно сконфигурировать групповую политику так, чтобы она применялась только к компьютерам или только к пользователям, а не к тем и другим. Чтобы сделать это, обратитесь к окну Properties (Свойства) объекта GPO (см. рис. 11-11), в котором можно отключить или компьютерные параметры настройки конфигурации, или пользовательские.
Рис. 11-11. Отключение компьютерных параметров настройки конфигурации для объекта GPO
Совет. Использования большинства опций, обсуждаемых в этом разделе и изменяющих заданное по умолчанию применение групповых политик, следует избегать, так как это может привести к сложной конфигурации групповых политик, с которой трудно работать. Опция, позволяющая применять групповые политики только к пользователям или только к компьютерам, используется чаще. В большинстве случаев групповые политики конфигурируются либо для тех, либо для других, но не для обоих одновременно.
Проблемы восстановления с полномочиями
Есть несколько существенных проблем восстановления с полномочиями. Наиболее важная проблема имеет отношение к групповому членству. В некоторых случаях восстановление с полномочиями может приводить к неправильному групповому членству на контроллерах домена, которые не были восстановлены с полномочиями. Неправильное членство возникает, когда объект, восстановленный с полномочиями (например, OU), содержит учетные записи групп и пользователей. При восстановлении с полномочиями объект OU и объекты пользователей и групп реплицируются на все другие контроллеры домена. Неправильное членство получается, когда восстановленная информация о группе реплицируется на контроллер домена-адресата, прежде чем реплицируется пользовательская информация. Когда контроллер домена-адресата получает группу, он замечает, что одна или более учетных записей пользователей, перечисленных в группе, не имеет правильной учетной записи пользователя, и он удаляет пользователей из группы. Когда затем на контроллер домена-адресата реплицируется учетная запись пользователя, она не добавляется назад к группе. Если пользовательская информация реплицируется перед информацией группы, то члены группы будут назначены правильно. К сожалению, нет никакого способа управлять очередностью реплицирования объектов.
Единственный способ исправить эту потенциальную ошибку состоит в том, чтобы создать временную учетную запись и добавить ее к каждой группе, на которую воздействует восстановление с полномочиями. Вы должны сделать это после того, как контроллер домена перезагрузился, и завершилась начальная полномочная репликация. Добавление члена к группе заставляет контроллер домена копировать список членов группы на все другие контроллеры домена. Если эти контроллеры домена удалили учетную запись пользователя из группы, то они восстановят ее после получения модифицированного списка членов группы.
Другая потенциальная проблема, касающаяся группового членства, может произойти в том случае, если групповое членство было изменено на другом контроллере домена до или в процессе официального восстановления. В этом случае измененное групповое членство могло бы реплицироваться на все контроллеры домена, кроме контроллера домена, выполняющего официальное восстановление. Официальное восстановление устанавливает номер USN для восстановленных объектов выше, чем USN, приписанный только что измененному групповому членству.
Таким образом, контроллер домена, выполняющий восстановление с полномочиями, никогда не получит модифицированную информацию о членстве группы, и информация каталога не будет согласована между различными контроллерами домена. Эта несогласованность может быть обнаружена только при рассмотрении списка членов каждой группы. Самый простой способ решения этой проблемы состоит в обновлении списков членов группы вручную.
Третья проблема имеет отношение к домену и доверительным отношениям компьютеров. Когда к домену добавляется компьютер, на котором выполняется система Microsoft Windows NT, Windows 2000, Windows XP Professional или Windows Server 2003, то создается пароль, известный только контроллеру домена и добавленному компьютеру-члену домена. Этот пароль используется для поддержания доверительных отношений между компьютером и доменом. По умолчанию пароль изменяется каждые семь дней. Если вы выполняете восстановление с полномочиями, то будут восстановлены пароли, которые были в использовании при создании резервной копии. Если компьютер-член домена уже получил другой пароль, то доверительные отношения между доменом и компьютером-членом домена не будут функционировать. Доверительные отношения NTLM между доменами Active Directory и доменами Windows NT используют похожие правила, поэтому они также могут перестать работать, если будет восстановлен старый пароль. Доверительные отношения домена можно восстановить, удаляя старые доверительные отношения и создавая их заново. Доверительные отношения рабочей станции с доменом можно восстановить, используя инструмент командной строки NetDom или удаляя рабочую станцию из домена, а затем добавляя ее назад.
Предостережение. Проблемы, которые возникают в результате использования восстановления с полномочиями, предполагают его использование с осторожностью. Эти проблемы показывают важность регулярного создания резервных копий ваших контроллеров домена. Чем старее резервная копия каталога, тем более вероятно, что вы столкнетесь с этими проблемами. Кроме того, вы должны иметь хорошо спроектированную и отработанную программу восстановления после сбоя для восстановлений. Чем быстрее вы можете восстановить каталог, тем меньше проблем вы будете иметь.
Процедура восстановления с полномочиями
Наиболее типичным вариантом восстановления с полномочиями, вероятно, будет восстановление только части каталога. Например, если кто-то случайно удалит OU, вы должны восстановить с полномочиями только эту OU, а не весь каталог.
Чтобы выполнить восстановление с полномочиями, сделайте следующее.
Выполните шаги с первого по пятый процедуры восстановления без полномочий; не перезагружайте сервер, когда восстановление закончено.
Откройте командную строку и напечатайте ntdsutil.
В окне Ntdsutil напечатайте authoritative restore (восстановление с полномочиями).
В окне Authoritative Restore напечатайте restore subtree objectname (восстановление поддерева objectname). Например, чтобы восстановить OU Managers в домене NWTraders.com, нужно напечатать restore subtree ou=managers ou,dc~nwtraders,dc=com. Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например, restore subtree en—managerl,ou—managers ou, dc—nwtraders,dc=com) или раздел приложений.
Чтобы восстановить с полномочиями весь каталог, напечатайте restore database (восстановить базу данных) в окне команды Authoritative Restore.
Выйдите из утилиты Ntdsutil и перезагрузите сервер.
Предостережение. В некоторых случаях потребуется восстановление всей базы данных Active Directory, используя восстановление с полномочиями. Такое восстановление всего каталога - это очень важная операция, она должна выполняться только в тех случаях, когда была разрушена база данных или произошла какая-то другая очень серьезная ошибка. Восстановление с полномочиями всего каталога увеличивает номер USN на каждом объекте в домене и в разделах конфигурации каталога на 100000. Раздел схемы не может быть восстановлен такими образом.
Процесс разрешения имен
Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела (см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.
Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес, запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не может быть найдена.
Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер провайдера посылает итерационный запрос корневому серверу об IP-адресе, который соответствует www.NAmerica.Contoso.com.
Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов, ответственных за домен высшего уровня сот. Этот процесс предоставления списка альтернативных DNS-серверов для дальнейшего контакта называется направлением (referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих серверов с просьбой об IP-адресе.
Сервер сот дает в ответ список серверов, которые являются ответственными за домен Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com, который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он посылает DNS-серверу провайдера IP-адрес нужного хоста.
DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента-преобразователя, и посылает IP-адрес запрошенного Web-сервера.
Компьютер клиента соединяется с www.NAmerica.Contoso.com.
Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS-сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.
Процесс репликации
Выше обсуждались детали создания топологии репликации в Active Directory. В данном разделе рассмотрим репликацию с другой точки зрения. Обратим внимание на то, как на самом деле передается модифицированная информация между двумя контроллерами домена, как контроллеры домена узнают о том, какую информацию они должны копировать партнерам по репликации, настроенным службой КСС.
Проект 0U, основанный на проекте групповых политик
Вторая причина для создания OU заключается в управлении назначением групповых политик. Групповые политики используется для изменения и управления конфигурацией рабочих столов. С помощью групповых политик можно обеспечить пользователям стандартную конфигурацию рабочего стола, включая автоматическую инсталляцию набора приложений. Групповая политика может управлять изменениями, которые пользователи выполняют на своих компьютерах, и конфигурировать параметры настройки защиты. Почти все групповые политики в Active Directory назначаются на уровне OU, так что развертывание групповых политик будет играть важную роль в проекте OU. При планировании структуры OU вы группируете вместе объекты, которые требуют одинаковых параметров настройки групповой политики. Например, если всем пользователям одного отдела требуется одинаковый набор приложений, их можно установить, используя групповую политику. Пользователи могут нуждаться в стандартном наборе отображаемых дисков (mapped drives). Сценарии входа в систему для пользователей можно назначить, также используя групповую политику. Возможно, что вы захотите применить шаблон защиты ко всем файловым серверам вашей организации. Чтобы сделать это, сгруппируйте все файловые серверы в OU и назначьте шаблон защиты, используя групповую политику.
В большинстве компаний низкие требования к уровню проекта OU будут определяться, прежде всего, потребностью применения групповой политики. По умолчанию все групповые политики наследуются от родительских OU. Это означает, что вы можете применить групповую политику на высоком уровне в структуре OU, а затем применить специфичную групповую политику на более низком уровне. Если нужно изменить заданное по умолчанию наследование групповой политики, это можно сделать, создав OU и заблокировав любое наследование групповой политики
на уровне OU. Такая зависимость проекта OU от групповых политик означает, что вы должны понять функциональные возможности групповых политик и требования вашей организации. В главах 11, 12, 13 подробно обсуждается, что можно делать с помощью групповых политик.
Проект OU, основанный на делегировании администрирования
Одна из причин создания структуры OU заключается в возможности делегирования административных задач. Многие компании, которые соединили домены ресурсов Windows NT в единственный домен Active Directory, возможно, захотят делегировать административные задачи, которые обычно выполняли администраторы домена в домене ресурсов. Некоторые компании имеют несколько офисов с локальными сетевыми администраторами в каждом, и они, возможно, захотят делегировать администрирование каждому из этих офисов. Другие компании захотят делегировать определенную административную задачу. Например, дать одному или двум человекам в каждом отделе право сбрасывать пароли пользователей, а также изменять информацию для всех пользователей отдела.
Все это становится возможными путем создания структуры OU в Active Directory и последующим делегированием административного доступа. Возможно представление любого уровня административного доступа на уровне OU. Если вы создаете OU для отдаленного офиса, вы можете представить его администратору полное управление объектами этого офиса. Администратор может выполнять любую административную задачу в этой OU, включая создание дочерних OU и делегирова-
ние разрешений другим администраторам. Если вы создаете OU для каждого отдела, вы можете предоставить очень специфические права, типа права сбрасывания паролей, нескольким пользователям в отделе. Можно предоставить административные права, основанные на типах объектов в OU, например, администраторы отдела могут изменять учетные записи пользователя, но не объекты групп или компьютеров. В главе 9 содержится подробная информация о делегировании администрирования. Следует прочесть эту главу перед созданием проекта OU.
Для большинства компаний организационные единицы высшего уровня будут разрабатываться на основе требований, связанных с делегированием администрирования. Скорее всего, эти единицы OU будут основаны на географическом месте расположения офисов компании или на деловых подразделениях. Эти границы OU будут также и административными границами.
Проектирование доменной структуры
Как только вопрос о количестве развертываемых лесов улажен, необходимо определить доменную структуру в пределах каждого из лесов. Ваша первая задача состоит в том, чтобы задокументировать конфигурацию текущих служб каталога и определить, какая часть текущей инфраструктуры может быть модернизирована, а какая должна быть реструктурирована или заменена. Затем определяется потребное количество доменов и их иерархия.
Проектирование групповой политики
Групповые политики являются мощным средством, предназначенным для управления конфигурацией компьютеров в вашей сети. Реализация групповых политик может быть достаточно сложной, и если она выполнена неправильно, групповая политика может сильно воздействовать на рабочую среду пользователей организации. В данном разделе описываются методики, позволяющих разработать реализацию групповой политики в вашей сети.
Дополнительная информация. Главы 12 и 13 описывают так же методики использования групповых политик для распределения программного обеспечения и управления рабочим столом.
Один из важных вопросов, с которыми вы столкнетесь при проектировании конфигурации групповой политики, состоит в том, сколько групповых политик вам следует реализовать. Поскольку все параметры настройки групповой политики доступны в каждом объекте GPO, вы теоретически можете сконфигурировать их в единственном объекте GPO или развернуть отдельный объект GPO для каждой установки, которую нужно сконфигурировать. В любом случае оптимальное количество объектов GPO будет расположено между этими крайностями, и никакое решение не будет верным для всех ситуаций. Когда запускается компьютер клиента и пользователь входит в систему, все применяемые объек-
ты GPO должны быть загружены и применены к местному компьютеру. Поэтому меньшее количество групповых политик улучшает запуск и производительность входа в систему. Однако наличие только нескольких групповых политик, выполняющих множество различных функций, является более трудным для документирования и управления. Если ваша групповая политика имеет только несколько параметров настройки, ее легче использовать повторно для нескольких OU. Хорошей практикой является использование объекта GPO для конфигурирования только одной группы параметров настройки. Например, вы можете использовать один объект GPO для установки конфигурации защиты, другой -для установки административных шаблонов, еще один - для установки пакета программ.
Другая проблема проектирования связана с тем, где вы хотите развернуть групповую политику. Обычно у вас есть возможность развернуть групповые политики на высшем уровне OU подразделений, а затем можно использовать фильтрацию rpytm и блокирование групповой политики, чтобы групповые политики применялись к соответствующим компьютерам или пользователям. Вы можете также применять большинство групповых политик ниже в иерархии, чтобы избежать конфигурации со сложным наследованием. В большинстве случаев комбинация этих стратегий дает правильный ответ. Если ваша политика должна применяться ко всем пользователям в вашем домене, установите ее настолько высоко, насколько это возможно. По мере продвижения вниз по иерархии групповые политики будут гораздо более специфичными.
Проектирование иерархии доменов
Как только проект корневого домена выполнен, нужно определить количество дополнительных доменов и то, и как они впишутся в пространство имен DNS леса. Используйте рекомендации, полученные ранее. Если текущая служба каталога - это служба для сети Windows NT, то для определения количества доменов Windows Server 2003 вы должны исследовать уже имеющуюся структуру доменов.
Многие крупные компании развернули домены Windows NT, используя модели с одним или несколькими хозяевами домена, в которой одни домены содержали учетные записи пользователей и глобальных групп, а другие — ресурсы компании. В некоторых случаях компании имели дюжины доменов с учетными записями и сотни доменов с ресурсами. Часто домены учетных записей были организованы вокруг географических регионов или деловых подразделений, и каждый из них обычно имел один или несколько доменов ресурсов в пределах одного географического региона или делового подразделения. На рисунке 5-2 показан пример того, как может выглядеть конфигурация доменов.
Переходя к Active Directory, эти компании могут значительно уменьшить количество доменов. Обычный путь обновления для многих состоит в модернизации доменов учетных записей. Поскольку домены Active Directory могут содержать значительно больше объектов, в некоторых случаях компания могла бы соединить несколько главных доменов учетных записей в один домен Active Directory. Как только произойдет модернизация доменов учетных записей, можно реструктурировать домены ресурсов, чтобы они стали организационными единицами в домене
Active Directory. Иногда домены ресурсов можно удалить. Например, некоторые компании имели домены ресурсов для инфраструктуры Exchange Server 5.5. При переходе организации к Exchange Server 2000 серверы могут быть развернуты в домене Active Directory. Когда последний сервер, на котором выполняется Exchange Server 5.5, удаляется, домен Exchange можно также удалить. На рисунке 5-3 показан возможный переход для компании, имеющей несколько доменов Windows NT 4.
Рис. 5-2. Типичная модель с несколькими хозяевами для доменов учетных записей и ресурсов в системе Windows NT
При планировании дополнительных доменов в лесу границы домена обычно определяются или географическим местом расположения корпорации, или деловыми подразделениями. В большинстве случаев предпочтительны домены, основанные на географии. Доменную конфигурацию трудно изменять после развертывания, а домены, основанные на географии, вряд ли будут требовать модификации. Кроме того, в большинстве случаев сетевая топология соответствует географической конфигурации, так что если вы будете создавать дополнительные домены для управления трафиком репликации, то домены, основанные на географии, вероятно, будут наилучшим вариантом. Доменный проект, основанный на деловых подразделениях, выбирается только в том случае, если эти подразделения достаточно автономны. Если каждое деловое подразделение управляет своей собственной службой каталога, то домены, основанные на деловых подразделениях, имеют смысл.
Рис. 5-3. Обновление доменов Windows NT 4 до Active Directory Windows Server 2003
Проектирование инфраструктуры DNS
Как только вы определились с количеством доменов и их иерархией, следующий шаг должен состоять в проектировании инфраструктуры DNS для вашей сети. Служба Active Directory Windows Server 2003 требует DNS, поскольку каждое имя домена теперь является частью пространство имен DNS. Ключевое решение проекта состоит в том, чтобы определить, где расположить домены Active Directory в пределах этого пространства имен. В дополнение к этому вы должны также спроектировать конфигурацию сервера DNS. Если компания уже имеет свою инфраструктуру DNS, то вам придется спроектировать свое пространство имен, чтобы вписаться в текущее пространство имен, а также сконфигурировать DNS-серверы Windows Server 2003 для взаимодействия с существующими серверами DNS.
Проектирование корневого домена леса
Другое важное решение, которое вы должны принять при проектировании службы Active Directory большой компании, — действительно ли вы должны развернуть назначенный корневой домен (называемый также пустым корнем). Назначенный корневой домен (dedicated root domain) -это домен, который выполняет функции корневого домена леса. В этом домене нет никаких учетных записей пользователей или ресурсов, за исключением тех, которые нужны для управления лесом. Лес с назначенным корневым доменом показан на рисунке 5-1.
Для большинства компаний, развертывающих несколько доменов, настоятельно рекомендуется иметь назначенный корневой домен. Корневой домен - это критический домен в структуре Active Directory. Он содержит административные группы уровня леса (группы Enterprise
Admins и Schema Admins) и хозяев операций уровня леса (хозяина именования доменов и хозяина схемы). Кроме того, корневой домен должен быть всегда доступен, когда пользователи входят на другие домены, не являющиеся их домашними доменами, или когда пользователи обращаются к ресурсам, расположенным в других доменах. Корневой домен нельзя заменять, если он разрушен, его нельзя восстановить, вы должны заново построить весь лес.
Рис. 5-1. Лес с назначенным корневым доменом
Назначенным корневым доменом управлять легче, чем корневым доменом, содержащим много объектов. Поскольку база данных каталога будет мала, достаточно просто поддерживать и восстанавливать контроллеры корневого домена. Между контроллерами корневого домена практически нет трафика репликации, так что не сложно расположить контроллеры домена в нескольких офисах компании для гарантии избыточности. Это облегчит также перемещение корневого домена в другое место. Использование назначенного корневого домена облегчает ограничение членства в административных группах уровня леса. Назначенный корневой домен никогда не устаревает, особенно если домену дают групповое (generic) имя.
По этим причинам большинство компаний, выбирающие несколько доменов, должны развертывать назначенный корневой домен. Даже компании, планирующие только один домен, должны рассмотреть преимущества, связанные с развертыванием назначенного корневого домена.
Назначенный корневой домен требует конфигурирования, которое не применяется к другим доменам леса. Поскольку корневой домен содержит хозяина операций леса, контроллеры домена для корневого домена должны быть защищены в максимально возможной степени. Домен леса также содержит группы, которые могут изменять лес и схему. Члены административных групп в корневом домене должны иметь более высокий уровень доверия, чем в случае с любым другим доменом. Вы, вероятно, захотите использовать опцию Restricted Group (Ограниченная группа) в политике Domain Security Policy (Политика безопасности домена) для управления членством этих групп. Конфигурация DNS корневого домена должна быть настолько безопасной, насколько это возможно. Поскольку установка в корневом домене какого-либо дополнительного компьютера маловероятна, вы должны включить безопасные динамические обновления для корневого домена зоны DNS на время инсталляции контроллеров домена, а затем динамические обновления для этой зоны следует отключить.
Проектирование плана восстановления
Ваш план восстановления системы в случае сбоя, или, более оптимистично, просто план восстановления, эквивалентен плану модернизации, но он используется тогда, когда действия по проверке правильности модернизации окончились неудачей. Определите в вашем плане модернизации не только то, что вы будете делать для проверки правильности шагов, выполняемых в процессе перехода, но и то, что вы сможете сделать для восстановления домена до последнего работоспособного состояния. Так вы сможете поддерживать доступ к ресурсам для ваших пользователей, найти ошибки в плане модернизации и попробовать все снова. В следующем разделе рассмотрено планирование восстановления системы после сбоя в процессе перехода к Active Directory.
Проектирование предупреждений
Предупреждение определяется как уведомление, которое вызывается автоматически, когда значение счетчика достигает порогового уровня. Используя инструмент администрирования Performance, имеющийся в системе Windows Server 2003, вы может сконфигурировать предупреждение для любого доступного счетчика функционирования системы.
Примечание. Когда Active Directory Installation Wizard устанавливает Active Directory, он конфигурирует счетчики функциональности в объекте NTDS Performance, который обеспечивает статистику деятельности службы каталога. Эти счетчики применимы ко всему каталогу, включая глобальные каталоги GC.
Счетчики функционирования базы данных Active Directory для базы данных ESENT (Ntds.dit) не устанавливаются во время инсталляции Active Directory. Вы должны добавить их вручную. Чтобы найти автоматизированный сценарий, который устанавливает счетчики функционирования базы данных Active Directory, смотрите статью Install Active Directory Database Performance Counters (Установка счетчиков функционирования базы данных Active Directory) в Центре сценариев Microsoft по адресу http://www.microsoft.com/technet/treeview/defa ult.asp? url —/technet/scriptcenter /monitor/ScrMonO8.asp. Вы можете скопировать этот сценарий в текстовой файл, дать файлу свое название и расширение .vbs, а затем выполнить его для установки счетчиков функционирования базы данных ESENT.
Чтобы создать предупреждение по поводу превышения числа аутен-тификационных запросов протокола Kerberos (порог равен 20-ти запросам в секунду) на контроллере домена, выполните следующие шаги.
Откройте Performance (Производительность) в папке Administrative Tools (Средства администрирования).
Дважды щелкните на Performance Logs And Alerts (Журналы работы и предупреждения), а затем щелкните на Alerts (Предупреждения).
Из меню Action (Действия) выберите New Alert Settings (Параметры настройки новых предупреждений).
В поле Name (Имя) напечатайте название предупреждения, а затем щелкните на кнопке ОК. Это название будет показано в контейнере Performance Logs And Alerts, поэтому используйте такое имя, которое определяет отслеживаемый счетчик.
На вкладке General (Общее) дайте комментарий к вашему предупреждению, а затем щелкните на кнопке ADD (Добавить), чтобы добавить необходимый объект Performance и счетчики (см. рис. 14-1).
Рис. 14-1. Добавление счетчика к новому предупреждению
Введите пороговый предел, запускающий предупреждение. Установите интервал времени для выборки данных функционирования службы (см. рис. 14-2).
Рис. 14-2. Установка порогового предела и интервала выборки9
На вкладке Action (Действия) определите события, которые должны происходить, когда значение счетчика достигнет порогового значения. Чтобы определить время, когда служба должна начать просматривать предупреждения, используйте вкладку Schedule (Расписание). Вкладка Action показывает, что предупреждение может вызвать несколько действий, включая следующие (см. рис. 14-3):
создание записи в прикладном журнале регистрации событий;
генерирование предупреждающего сообщения. Это сообщение может быть послано или по IP- адресу или на имя компьютера;
запуск регистрации характеристик функционирования службы;
выполнение программы.
Рис. 14-3. Определение действий, запускаемых новым предупреждением
В дополнение к опциям, указанным на вкладке Actions, для эффективного мониторинга желательно иметь готовый план действий в ответ на предупреждение. После того как вы определите ваши счетчики, а также базовые и пороговые значения, обязательно задокументируйте корректирующие действия, которые вы предпримите для того, чтобы вернуть индикатор в пределы нормы. Они могут включать поиск неисправностей (например, возвращение контроллера домена в интерактивный режим) или передачу роли хозяина операций. Если ваша система достигла своих максимальных возможностей, возможно, для исправления текущего состояния придется добавить дополнительное дисковое пространство или память. Другие предупреждения потребуют от вас выполнения действий по обслуживанию Active Directory, таких как деф-рагментация файла базы данных Active Directory. Эти ситуации обсуж-
даются далее в этой главе в разделе «Автономная дефрагментация базы данных Active Directory».
Проектирование пространства имен
Как только вы собрали информацию относительно имеющейся инфраструктуры DNS, можно начинать разработку своего пространства имен службы Active Directory.
Проектирование размещения серверов
В проектирование сайта входит определение мест размещения серверов, на которых выполняется система Windows Server 2003, необходимых для обеспечения нужных служб каталога. В большинстве случаев, как только вы завершите проектирование сайта, разместить серверы несложно.
Проектирование структуры леса
Самое главное решение, которое вы должны принять на раннем этапе разработки, - сколько лесов вам потребуется. Развертывание единствен-
ного леса Active Directory означает, что будет возможно простое совместное использование ресурсов и доступ к информации в пределах компании. Использование единственного леса для большой корпорации требует высокой степени доверия между разнообразными и, возможно, разъединенными деловыми подразделениями. В конечном счете, количество развертываемых лесов зависит от того, что является наиболее важным для вашей компании: легкость совместного использования информации в пределах всех доменов леса или поддержка полностью автономного и изолированного управление частями структуры каталога.
Практический опыт. Участие бизнес-заказчиков в проектировании Active Directory
Когда вы проектируете Active Directory для корпорации, важно вовлечь управление компании в этот процесс. Пользователи-бизнесмены являются основными потребителями услуг, которые обеспечивает инфраструктура информационных технологий (IT), поэтому необходимо, чтобы ваш проект удовлетворял их требованиям и имел поддержку со стороны руководства.
Степень участия деловых подразделений в проектировании сильно зависит от компаний. Практически в каждой организации она выражается, по крайней мере, в одобрении высокоуровневых задач проекта. Эти задачи касаются вопросов доступности информации, безопасности, простоты управления и практичности. Менеджеры обычно включаются в принятие решений, которые не могут быть изменены сразу после развертывания. Среди этих решений — вопрос о том, сколько лесов и доменов требуется сети и сколько должно быть развернуто доменных пространств имен.
Проектирование структуры организационной единицы
Как только проектирование на уровне доменов закончено, следующий шаг состоит в создании модели организационной единицы OU для каждого домена. В главе 2 говорилось, что OU используются для создания иерархической структуры в пределах домена. Эта иерархия может затем использоваться для делегирования административных задач или применения групповых политик к совокупности объектов.
Проектирование структуры OU
В большинстве компаний модель OU имеет большую гибкость. При этом следует учесть множество факторов.
Практический опыт. Структура компании и проектирование OU
Первой мыслью при создании структуры организационных единиц становится подражание организационной схеме компании. В некоторых случаях это работает, в некоторых — нет. Организационная схема компании обычно основана на деловых подразделениях без учета того, где фактически располагаются пользователи. Возможно, что члены деловых подразделений рассеяны по всему миру. Группировка этих пользователей в единственную OU может быть весьма неэффективной. Исследование структуры компании и ее организационной модели - это хорошая отправная точка для проектирования OU. Если компания централизована и иерархична, то структура OU, вероятно, отразит эту модель. Если компания представляет большую автономию деловым подразделениям или географическим местам, то проект OU должен отразить этот подход. При исследовании структуры компании исследуйте также структуру управления информационными технологиями (IT). В некоторых компаниях отдельным деловым подразделениям дается большая автономия для управления бизнесом по их собственному усмотрению, но ГГ-управле-ние может оставаться централизованным. В этом случае необходимо проектировать структуру OU, базируясь на структуре 1Т-управления, а не на структуре управления бизнесом.
Проектирование топологии сайта
До настоящего момента в книге обсуждались логические аспекты проектирования Active Directory без учета фактической сетевой топологии организации. Прежде чем развернуть проект Active Directory, необходимо разобраться с проектом сайта, на который непосредственно влияет сетевая топология.
Производительность Active Directory
Счетчики производительности (см. табл. 14-1) выполняют мониторинг основных функций и служб Active Directory. Если не указано другого, пороги определяются в результате мониторинга базовых значений. Чтобы получить доступ к этим счетчикам, откройте Start (Пуск) >Administrative
Tools (Средства администрирования)>Регfоmance(Производительность), а затем щелкните на кнопке Add (Добавить) над диаграммой. Разделы, данные после этой таблицы, описывают установку свойств счетчика.
Табл. 14-1. Основные функции и службы Active Directory
| Объект | Счетчик | Интервал | Почему этот счетчик важен | ||||
| NTDS | DS Search sub-operations/sec (DS поисковые подоперации/секунда) | Каждые 15 минут | Запросы на поиск поддеревьев очень интенсивно используют ресурсы системы. Любое его увеличение может указывать на проблемы с производительностью контроллера домена. Проверяйте, происходят ли случаи неправильного обращения приложений к контроллеру домена. | ||||
| Процесс | % Processor Time(Instance=lsass) (% времени процессора) | Каждую минуту | Указывает процент от времени процессора, используемого службой Active Directory. | ||||
| NTDS | LDAP Searches/ sec (LDAP поиск/ секунда) | Каждые 15 минут | Является хорошим индикатором объема использования контроллера домена. В идеале он должен иметь одинаковые значения для всех контроллеров домена. Увеличение значения указывает на то, что новое приложение обращается к этому контроллеру домена, или что больше клиентов было добавлено к сети. | ||||
| NTDS | LDAP Client Sessions (LDAP сеансы клиентов) | Каждые 5 минут | Указывает текущее количество клиентов, связанных с контроллером домена. Его увеличение указывает на то, что другие машины не выполняют свою работу, перегружая этот контроллер домена. Обеспечивает полезной информацией о том, в какое время дня пользователи преимущественно выходят в сеть, и максимальном числе клиентов, связывающихся с сетью каждый день. | ||||
| Процесс | Private Bytes (Instance=lsass) (Личные байты) | Каждые 15 минут | Отслеживает объем памяти, используемой контроллерами домена. Непрерывный рост значения указывает на увеличение потребности рабочей станции за счет поведения приложений (оставляют дескрипторы) или на увеличение числа рабочих станций, обращающихся к контроллеру домена. При значительном отклонении значения этого счетчика от нормального значения, соблюдаемого на других, равных по положению, контроллерах домена, вы должны исследовать причину этого. | ||||
| Процесс | Handle Count (Instance=lsass) Счетчик дескрипторов) | Каждые 15 минут | Полезен для обнаружения плохого поведения приложения, не закрывающего дескрипторы должным образом. Значение этого счетчика увеличивается линейно по мере добавления клиентских рабочих станций. | ||||
| Процесс | Virtual Bytes (Instance=lsass) (Виртуальные байты) | Каждые 15 минут | Используется для определения того, что Active Directory выполняется при нехватке виртуального адресного пространства памяти, что называет на утечку памяти. Убедитесь, что у вас выполняется самый последний сервисный пакет (service pack), и наметьте перезагрузку на ближайшие нерабочие часы, чтобы избежать простоя системы. Этот счетчик может использоваться для определения того, что остаются доступными менее 2-х гигабайт виртуальной памяти. |
Просмотр информации USN
Номера USN (update sequence number) для любого объекта можно просмотреть с помощью средств администрирования, включенных в инструментальные средства поддержки Windows Server 2003. Один из способов просмотра локального USN исходного контроллера домена, исходного USN и отметки времени (time stamp) для любого атрибута состоит в использовании инструмента командной строки Repadmin. (Полную инструкцию по установке Repadmin смотрите в разделе «Мониторинг и поиск неисправностей репликации» далее в этой главе.) Напечатайте repadmin /showmeta object distinguished name (отличительное имя объекта) в командной строке. Значения uSNCreated и uSNChanged можно увидеть в ADSI Edit через свойства объекта. Чтобы получить доступ к информации репликации через Ldp.exe, найдите объект, щелкните правой кнопкой мыши на объекте, выберите Advanced (Расширенный), затем выберите Replication Metadata (Мета-данные репликации). Значения USN также можно присмотреть через Монитор репликации (см. рис. 4-10). Для этого добавьте сервер к списку мониторинга, а затем щелкните правой кнопкой мыши на сервере и выберите Show Attribute Meta-Data For Active Directory Object (Показать метаданные атрибута для объекта Active Directory). Введите мандат (credentials) для учетной записи с доступом к Active Directory, а затем напечатайте отличительное имя объекта. Часть USN-информации доступна также из обычных средств администрирования. Чтобы посмотреть текущие и исходные значения USN для объекта в инструменте администрирования Active Directory Users And Computers, включите Advanced Features (Расширенные функции) в меню View (Вид), а затем обратитесь к вкладке Object (Объект) в окне Properties (Свойства) объекта.
Уровень и вектор новизны используются для ограничения трафика репликации. Значение уровня представляет собой самое последнее изменение, которое контроллер домена получил от другого контроллера домена, так что контроллер-отправитель не должен снова посылать это значение. Вектор новизны содержит самые свежие обновления, которые были получены от других контроллеров домена, содержащих реплику раздела, так что контроллер-отправитель не должен посылать такие модификации каталога, которые контроллер-адресат уже получил от другого партнера по репликации.
Рис. 4-10. Просмотр мета-данных репликации с помощью Replication Monitor (Монитор репликации)
