Оснастка ad для windows server 2012

Managing Active Directory and Group Policy can be a little obscure due to the prerequisite of installing the Remote Server Administration Tools on Windows 7 and 8. In Server 2012, there is no separate install of the RSAT tools, you just have to know where to look. Fortunately, it proves consistent by being part of the Add/Remove Roles and Features part of the Windows Server operating system. I like the role-based installations because it greatly simplifies the install process, provides you a list of Server’s native capabilities, and keeps the installation minimal by allowing you to manually choose what you want installed after the fact.

To get the Active Directory Users and Computers, you want to be sure to install just the tools you need, not the entire domain services on your server. That is, unless you wish to make your server a domain controller.

Open up Server Manager by clicking the icon pinned to the Taskbar or right-clicking Computer and going to Manage. In the top-right corner of the window, go up to the Manage menu and click ‘Add Roles and Features’.

From here, you will go through a dialog wizard. Follow the on-screen instructions to get to the install on the server you want configured. Choose Role-based or feature-based installation and select your server.

Unless there are other roles you would like installed, skip Server Roles and hit Next to get to the Features.

On the Features page, check Group Policy Management Tools.

The description reads: Group Policy Management is a scriptable Microsoft Management Console (MMC) snap-in, providing a single administrative tool for managing Group Policy across the Enterprise. Group Policy Management is the standard tool for managing Group Policy.

Scroll down a little bit to get to and Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools and check those boxes, particularly AD DS Snap-Ins and Command-Line Tools.

The description reads: Active Directory Domain Services Snap-Ins and Command-Line tools includes Active Directory Users and Computers, Active Directory Domains and Trusts, Active Directory Sites and Services, and other snap-ins and command-line tools for remotely managing Active Directory domain controllers.

You can also select other tools you want like the Active Directory Administrative Center but to specifically get just Active Directory Users and Computers, check the box in front of AD DS Snap-Ins and Command-Line Tools.

Confirm your selections and let the install do its work.

Once the installation completes, you will see ‘Active Directory Users and Computers’ and ‘Group Policy Management Console’ on the Start Screen. You can also find them under the Administrative Tools folder should you want to copy a shortcut to your desktop. Note: using the GPMC from Server 2012 gives you access to New Windows 8 and Server 2012 Group Policies.

Содержание

Введение в основы Active Directory
Создание леса с единственным доменом 
Преимущества наличия единственного домена
Создание леса с единственным доменом
Конфигурация сервера
Конфигурация развертывания
Совместимость операционной системы
Имя домена
Именование корневого домена
Active Directory и DNS 
Функциональные уровни домена
Функциональные уровни леса
Местоположения для файлов и папки SYSVOL
Пароль администратора Directory Services Restore Modc
Запуск мастера Active Directory Domain Services Configuration Wizard
Прежде чем запускать мастер Active Directory Dom ain Services Configuration
Wizard
Конфигурация развертывания для второго контроллера домена
DNS-cepвep для второго контроллера домена
Глобальный каталог для второго контроллера домена
Запуск мастера ADDSCW для второго контроллера домена
Создание организационных единиц учетных записей и групп
Создание организационных единиц
Управление посредством групповой политики 
Центр администрирования Active Directory 
Создание организационных единиц с помощью ADAC
Отличительные имена LDAP 
Создание организационных единиц с помощью PowerShell
PowerShell и Active Directory
Создание учетных записей
Создание учетных записей с помощью Active Directory Administrative Center
Создание пользователей с помощью PowerShell 
Создание групп
Создание групп с помощью PowerShell (ADAC Wi ndows PowerShell History) 
Просмотр хронологии PowerShell
Делегирование управления с использованием организационных единиц
Задачи обслуживания домена 
Присоединение к домену
Вывод из эксплуатации контроллера домена
Устранение неполадок в AD DNS 
Поднятие функциональных уровней домена и леса
Использование утилиты Netdom
Управление временем в домене
Роли FSMO и их передача 
Детализированные политики паролей изменилось?
Создание объекта настройки паролей 
Приоритет объекта настроек паролей
Папка SYSVOL: старое и новое 
Старое: служба репликации файлов
Что собой представляет служба FRS
Преимущества репликации с помощью FRS
Требования и зависимости FRS
Каково будущее FRS?
Новое: репликация распределенной файловой системы
Что собой представляет DFS-R 
Миграция на DFS-R
Шаги миграции
Переходные состояния
Миграция в состояние Prepared 
Верификация Active Directory 
Поднятие функционального уровня домена 
Выполнение миграции
Миграция в состояние Redirected 
Миграция в состояние Eliminated 
Модернизация Active Directory 
Модернизация схемы до Windows Server 2012 
Модернизация домена до Windows Server 2012
Миграция путем модернизации на месте 
Подготовка леса/схемы и домена
Запуск программы установки
Постепенная миграция 
Подготовка к повышению сервера -члена
Подготовка леса /схемы и домена
Построение сервера -члена Windows Server 2012 
Верификация DNS
Подготовка исходного контроллера домена
Повышение сервера -члена
Процедуры, выполняемые после миграции
Переналадка оборудования 
Чистая изначальная миграция
Чистая изначальная миграция является постепенной 
Обработка разрешений в новом домене 
Использование бесплатного инструмента миграции ADMT от Microsoft
Пример проведения миrрации 
Установка доверительного отношения 
Обеспечение дружественности к ADMT на обеих сторонах 
Помещение учетной записи администратора домена в группы 
Administrators в каждом противоположном домене
Включение аудита
Включение криптографических настроек в uелевом домене
Установка ADMT и PES
Небольшие работы на рабочей станции 
Запуск ADMT и миграция 
Графический пользовательский интерфейс, командная строка ил и VBScript
Миграция пользователей и групп с помощью оснастки ADMT 
Миграция с помощью командной строки 
Тестирование доступа к ресурсам перемешенной группой
Перенос локальных профилей
Перенос профилей с помощью оснастки ADMT
Миграция учетных записей компьютеров
Соображения относительно отката
Путь к функциональному уровню леса Windows Server 2012
Введение в Windows Azure Active Directory
Начало работы с Windows Azure Active Directory 
Взаимодействие с Windows Azure Active Directory 
Синхронизация Windows Azure Active Directory
Разновидности входа в Active Directory
Обзор технологии Workplace Join 
Что собой представляет технология Workplace Join

Концепция, положенная в основу Active Directory, великолепна. Слово Active
(активный) подразумевает динамическое поведение, а слово Directory (ката­
лог) предполагает выполнение задач хранения и поиска компонентов. Полностью
Active Directory можно описать так: центральное место, где хранятся и управляются все пользователи и компьютеры, а также формируется поведение инфраструктуры Windows. Компонент Active Directory появился в версии Windows 2000 Server и рас­ширялся в версиях Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 и Windows Server 2008 R2. В современных бизнес-средах Active Directory играет важ­ную роль в качестве централизованного решения по управлению идентификацией и доступом.
Хотя на протяжении некоторого времени Active Directory быта очень устойчивой
системой, специалисты из Microsoft настроили и добавили дополнительные средс­тва, сделав Windows Server 2012 Active Directory еще более надежным, масштабируе­мым, защищенным и простым в управлении решением.
Однако один лишь факт того, что Active Directory очень легко устанавливать и
настраивать, вовсе не означает, что можно просто запустить DCPROMO и пощелкать
на кнопках Next (Далее), а в конце на Finish (Готово). Это больше не будет работать,
к тому же имеются соображения, которые необходимо рассмотреть перед, во время и после установки Active Directory. В противном случае рано или поздно закончится
тем, что вы получите неправильно сконфигурированную и некорректно функционирующую систему. В этой главе будет пролит свет не только на различные аспекты установки и конфигурирования Active Directory, но также на управление и обслужи­вание систем Active Directory.
Вероятно, вам наиболее интересно узнать, что появилось нового в версии Active Directory 2012; в этой и последующих главах вы научитесь устанавливать, конфигу­рировать и обслуживать Active Directory 2012.

В этой главе вы изучите следующие темы:
• создание леса с единственным доменом;
• добавление к домену второго контроллера домена (domain controlleг — ОС);
• принятие решения о добавлении глобального каталога;
• создание учетных записей;
• создание детализированных политик паролей;
• понятие функционального уровня леса Windows Server 2012;
• модернизация домена до Windows Server 2012.
В настоящей главе мы собираемся ссылаться на версии Windows Server 2012 и
Windows Server 2012 R2 просто как на Windows Server 2012. Если какие-то возможности
доступны только в версии Wiпdows Server 2012 R2, на это будет указано специально.

Лучше всего начать с изучения определений и терминов. Поскольку в Active
Oirectory используется много специальных слов, ниже приведен словарь, который должны знать администраторы.
• Рабочая группа (workgroup). Рабочая группа — это по существу один или боль­шее число компьютеров в локальной вычислительной сети Windows, которые
не присоединены к домену. Каждый компьютер находится сам по себе, поэто­му зависимости между ними отсутствуют. Например, на компьютере 1 имеется
локальный пользователь по имени Joe, и на компьютере 2 также имеется локальный пользователь по имени Joe. Имена пользователей совпадают и принадлежат одному и тому же лицу, но это собой совершенно разные пользователи. Следовательно, если вы хотите управлять, к примеру, паролями этих пользователей, то вам придется подключиться или войти в систему на каждом компьютере и затем изменить пароль. Способа центрального управления таки­ми пользователями не существует.
• Домен (domain). Домен — это коллекция объектов, которые совместно исполь­зуют одну базу данных. Это значит, что в примере рабочей группы можно было бы создать одного пользователя Joe в центральной базе данных Active Oirectory и подключить к домену этой базы данных компьютеры 1 и 2 рабочей группы.
Зачем нужен домен? Если все объекты управляются централизованно, нет необходимости в подключении или перемещению к каждому из них для изменения пароля у пользователя. Домен представляет собой намного более широкую
концепцию, но для базового понимания такого примера вполне достаточно.
• Служба домена Active Directory (Active Directory Domain Services). Служба домена
Active Oirectory (Active Oirectory Oomaiп Services — AD OS) интегрирована в ОС Windows Server, но по умолчанию автоматически не устанавливается. Если вы
планируете повысить сервер Wiпdows до контроллера домена, либо существуюшего, либо полностью нового, то должны установить на этом сервере АО DS,создать базу данных Active Oirectory и добавить множество других компонен­тов, которые необходимы для надлежащего функционирования Active Oirectory.Поскольку Active Directory функвионирует как служба Windows в фоновом режиме, ее можно останавливать и запускать. Это крупное усовершенствова­ ние, т.к. устраняется необходимость загрузки в режиме восстановления для выполнения задач авторитетного восстановления или обслуживания базы дан­ных Active Directory; взамен понадобится только остановить службу AD DS и выполнить интересующую операцию.
Каждый контроллер домена имеет собственную копию базы данных Active
Directory, которая динамически обновляется другими контроллерами домена.
Из-за того, что все системы, присоединенные или интегрированные с Active
Directory, зависят от Active Directory, в целях избыточности очень важно иметь, по меньшей мере, два контроллера домена. В противном случае, если сущес­твующий в единственном экземпляре контроллер домена откажет, то остановится работа всей среды.
+ Сайт (site). Сайты представляют физическую структуру или топологию сети.
По определению сайт — это коллекция связанных друг с другом подсетей.
Во многих случаях офисы филиалов создаются в виде сайтов. Мы предпола­
гаем, что системы надежно соединены внутри сети офиса филиала, но име­
ют ограниченное сетевое подключение с головным офисом. В такой ситуации
имеет смысл создать сайт дrlЯ офиса филиала. О сайтах еще много чего можно
сказать, но на данный момент этого вполне достаточно.
+ Репликация (replication). Репликация является, пожалуй, самой сложной темой, относящейся к Active Directory. В Active Directory применяется система репли­кации с несколькими хозяевами. Это значит, что вы можете внести изменение, например, создав пользователя Joe на одном контроллере домена, и оно будет реruшцировано на другой контроллер домена. Разумеется, объекты можно созда­вать, изменять и удапять. При этом любое изменение будет реплицировано на все контроллеры домена внутри сайта в пределах 1 5 секунд, а на контроллеры
домена на разных сайтах не менее чем за 15 минут (по умолчанию за 180 минут).
Active Directory строит наилучший путь репликации с использованием сложного
алгоритма, так что каждый контроллер домена получает актуальные обновления.
+ Объекты (object). Выражаясь кратко, все, что находится в Active Directory, яв­ляется обьектом. Например, пользователь Joe является объектом. Если выизмените его имя, то тем самым измените свойство пользователя Joe, кото­рое хранится в атрибуте под названием First Name (Имя). К тому же, если вы создаете учетную запись компьютера, то группы, организационные единицы,
сайты, подсети IP и т.д. будут объектами со свойства’vfи.
+ Схема (schema). Схема хранит классы дrlЯ создаваемых вами объектов. Можете
думать о схеме как о наборе шаблонов, которые будут применяться при создании
пользователя Joe. Среде Active Directory необходимо знать, как будет выглядеть
пользователь, к примеру, какие он имеет свойства — скажем, имя и фамилию.
Это предоставляется схемой. Если вы планируете установить другое ПО, такое
как Lync или Exchange, то схему понадобится расширить. Почему? Взглянув на
объект пользователя до и после расширения схемы, вы обнаружите, что в нем
появились дополнительные опции (свойства) вроде адреса SJP (Session Initiation
Protoco — протокол инициирования сеанса). Адрес SIP используется д.11я видео­
и голосовых коммуникаций по протоколу Интернета (lnternet Protocol — IP).

• Группвая ПОЛIИТИКа (Group Policy). Как упоминалось ранее, групповые политики необходимы для конфигурирования настроек пользователей и компьютеров.
Они очень удобны, поскольку в одной групповой политике можно сконфи­
гурировать одну или большее количество настроек и применить их к одному
и более пользователей и компьютеров, связав объект групповой политики
(Group Policy object — GPO) с соответствующей организационной единицей
(organizational unit — OU).
В качестве примера давайте предположим, что на каждом сервере нужно вклю­
чить удаленный рабочий стол, чтобы к серверам можно было подключаться с
использованием клиента RDP. Установка этого вручную на каждом компьютере
потребовала бы много работы. Вместо этого понадобится включить настройку
удаленного рабочего стола в групповой политике и связать ее с OU, где нахо­
дится ваш сервер, в результате чего на всех компьютерах внутри данной OU бу­
дет включен удаленный рабочий стол. Объекты GPO можно связывать с сайта­
ми, доменами и организационными единицами. Когда вы повышаете сервер до
контроллера домена, по умолчанию появляются две политики. Каждый домен
имеет стандартную политику домена (Default Domain Policy) и стандартную по­
литику контрот1еров домена (Default Domain Controllers Policy).
• Организационная единица (organi:zational unit). Организационные единицы при­меняются для организации объектов в Active Directory, главным образом объ­ектов пользователей и компьютеров. Организационная единица — это просто
разновидность контейнера, который содержит похожие объекты. Существуют
две главные причины для организации объектов в Active Directory. Пероая при­
чина касается связывания объектов GPO, а вторая объясняется необходимос­
тью в наличии OU дпя делегирования управления.
Предположим, что вы создали организационную единицу по имени USERS
и поместили в нее пользователя Joe. Теперь нужно, чтобы пользователь Joe
всегда получал свои сетевые диски. Следовательно, потребуется создать объект
GPO и связать эту политику с организационной единицей USERS. После этого
пользователь Joe будет получать настройки из объекта GPO и располагать все­ми своими сетевыми дисками.
Значок для OU выглядит как папка из проводника Windows, и поскольку она
используется похожим образом, администраторы часто путаются и применяют
OU подобно папкам Windows для группирования объектов с целью их более
простого нахождения в будущем. Это не главное назначение организационных
единиц. Конечно, вы можете использовать их для группирования и органи­
заuии объектов с целью упрошения их поиска в Active Directory, но основной
их замысел состоит в том, что администратор Active Directory должен иметь
столько OU, сколько необходимо, чтобы применять делегирование управле­
ния и упрамять объектами в OU посредством объектов GPO.
• Стандартная потrrика д ом ена (Default Domain Policy). Стандартная политика до­мена создается сразу после создания первого домена. Эта политика содержитнастройки дпя пользователей и компьютеров, которые будут применяться к це­лому домену. Важно понимать, что данная политика является неотъемлемой дпясреды и не должна удаляться. Ее можно модифицировать, но мы не рекомендуем делать это. При необходимости применения к домену спеuиальных настроек вы должны создать новую политику и сохранить эти настройки внутри нее.
• Стандартная политика контроллеров домена (Default Domain Controllers Policy).
Стандартная политика контромеров домена — также очень важная политика,
которая связывается с контейнером Domain Controllers (Контроллеры домена)
в Active Directory. Настройки, устанавливаемые в стандартной политике конт­
роллеров домена, представляют собой спеuифичные конфигурации, которые
применяются только к контроллерам домена. Если вы повышаете сервер, яв­
ляющийся членом домена, до контроллера домена, он автоматически поме­
щается в контейнер Domain Controllers. Существует очень мало случаев, когда
придется касаться этой политики.
• Лес (forest). Лес — это одиночный экземпляр Active Directory. Внутри леса мож­
но иметь один или несколько доменов, совместно использующих одну и ту же
схему. В сущности, настроив единственный контроллер домена, вы создаете
наименьший из возможных лес. Он также называется лесом с единственным
доменом. На лес также ссылаются как на граниuу безопасности, внутри кото­
рой доступны пользователи, компьютеры и другие объекты.
• Глобальный каталог (global catalog — GC). Глобальный каталог содержит инфор­
мацию о каждом объекте в любых доменах внутри леса с несколькими доменами
Active Directory. Глобальный каталог хранится на контроллерах доменов, которые сконфигурированы как серверы глобального каталога, и его данные распростра­няются посредством репликации Active Directory. Внутри леса имеется только один глобальный каталог, но несколько его копий. Приложения вроде Exchange или клиенты обращаются к глобальному каталогу за информацией об объектах из леса. Глобальный каталог в домене содержит полные сведения об объектах о домене, но только частичную информацию об объектах в лесе. Глобальный ката­лог предлагает также друтие службы, такие как предоставление ссылок на друтие объекты в разных доменах, преобразование основных имен пользователей (user pri11cipal name — UPN) и кеширование членства в универсальных группах.
• Доверительное отношение (trust). Доверительное отношение — это соединениемежду доменами с целью доступа к их ресурсам, таким как серверы и прило­жения. Например, это можно было бы применять, если некоторым пользова­
телям необходим доступ к обшим файлам или информации из интрасети дру­
гого домена. Если вы установите домен и дочерние домены, Active Directory
автоматически создаст транзитивное доверительное отношение. В результате
вы сможете получать доступ из корневого домена к объектам в дочерних доме­
нах и наоборот. Когда нужен доступ к ресурсам в другом лесе, можно создать
доверительное отношение какой-нибудь формы для соединения обоих лесов.
• Дерево (tree). Если вы строите один или несколько доменов внутри того же
самого леса, который имеет непрерывное пространство имен и/или совмест­
но используют одну и ту же схему, то вы создаете дерево. Непрерывное про­
странство имен — это домен, разделяющий то же самое имя корневого доме­
на. Например, для корневого домена Ьigf irт. сот непрерывное пространство имен может выглядеть как marketing . Ьigfirт . сот. Дерево Active Directory является коллекция доменов, которая построена на основе иерархии транзи­тивных доверительных отношений.

Создание леса с единственным доменом

Как вы уже знаете, лес с единственным доменом — это простейшая топология
Active Directory, которую только можно построить. Согласно обшей рекомендаuии,
домен Active Directory необходимо создавать при наличии 10 или более пользовате­лей. Домен можно было бы также создать и при меньшем количестве пользователей, поскольку никаких оrраничений здесь не предусмотрено; все дело лишь в сложнос­ти и затратах. Преимущества создания домена очевидны:
• управление пользователями и разрешениями из центрального места;
• uентрализованная зашита и управление всеми системами с использованием
объектов GPO;
• предоставление дополнительных зависимых от Active Directory служб.
Вас может интересовать, должны ли вы придерживаться одного домена или зачем мо­жет понадобиться добавление дополнительных доменов в инфраструктуру. Когда только возможно, вы должны создавать лес с единственным доменом, т.к. он проще в настройке и управлении. Существует ряд ситуаций, при которых может быть рассмотрен вопрос создания более одного домена. Поскольку служба Windows Server 2012 Active Directory в версии Windows Server 2008 R2 не изменялась, перечисленные ниже правила по-преж­нему актуальны. Несколько доменов должны применяться в следующих случаях.
• Вы имеете дело с очень медленными каналами глобальной сети (WAN) и пере­
живаете по поводу производительности репликации. Это становится даже бо­
лее важным при наличии очень большого объема изменений в атрибутах или
объектах внутри Active Directory.
• У вас есть унаследованный домен, который должен быть предохранен.
• Ваш домен очень динамичен и объекты в нем изменяются часто. В этом слу­
чае трафик репликации может оказаться чрезмерным при достижении порога
в 100 ООО объектов. Одной из опций для разделения трафика репликации ямя­
ется разделение домена.
Важно понимать. что причины создания нескольких доменов связаны не с тем,
что один домен приближается к своим техническим пределам; проблема кроется в репликации, которая может привести к возникновению множества проблем в инф­раструктуре. Ранее мы обсуждали, что единственный домен — это наименьший лес, который можно создать. Точно так же, как можно установить несколько доменов в лесе, имеется возможность создания множества лесов. Ниже приведены некоторые причины для создания нескольких лесов.
• Вы должны обеспечить так называемую административную автономию.
Возможно, некоторые отделы внутри вашей компании не доверяют друг дру­
гу. Или, может быть. существуют причины, связанные с безопасностью, вроде
полной изоляции инфраструктуры /Т отдела кадров. Также, возможно, нет со­
глашения по изменениям схемы.
• Вам необходимо отделить приложения и службы от остальной инфраструк­
туры. Может потребоваться установить кластеры Hyper-V в отдельном лесе
(структуре) и установить инструменты управления, такие как продукты сис­
темного центра (System Center), в другом лесе. Имейте в виду, что чем больше лесов Active Directory вы строите, тем быстрее растет сложность и затраты на управление. достигая уровня, которого вы могли не ожидать.

Преимущества наличия единственного домена

Лреимущества наличия единственного домена вполне очевидны.
• Стоимость. В случае построения одного домена рекомендуется установить хотя
бы два контроллера домена для обеспечения избыточности. Конечно, при ус­
тановке дополнительных контроллеров доменов для новых доменов или лесов
стоимость лицензий, оборудования, ПО, а также затраты на управление и об­
служивание добавочных серверов осегда уоеличивается. Несмотря на возмож­
ность виртуализации любого контроллера домена, все равно прИдется платить
за хранение и управление такими серверами.
• Управление. Любой добавляемый домен будет иметь дополнительные объекты,
которыми необходимо управлять. Кроме того, есть много сложных задач по
настройке разрешений между доменами или даже между лесами, а также по
применению вложения групп для совместного использования ресурсов либо
поддержания всех доменов и лесов в работоспособном состоянии.
• Восстановление в аварийных ситуациях. Active Directory — очень сложный ком­понент в плане восстановления домена или даже леса. Всегда проще восстано­вить один домен, а не два и более.
В Windows Server 2008 были оведены детализированные политики паролей. Они
решают давнишнюю проблему, которая вынуждала создавать еще один отдельный
домен. Детализированные политики паролей позволяют создавать несколько политик в отношении паролей. В ранних версиях Active Directory могла существовать только одна политика паролей. В Windows Server 2012 детализированные политики паролей остались теми же, что и в версии Windows Server 2008, но был предложен дружественный к пользователю интерфейс для более простого управления ими.

Создание леса с единственным доменом

Вы можете обнаружить, что основы Active Directory не претерпели никаких изме­нений. Поскольку большинство терминов уже раскрыты, все готово к рассмотрению процесса построения леса с единственным доменом. Но прежде чем приступить к созданию нового домена, необходимо прояснить ряд моментов:
• версия Windows Server 201 2;
• конфигурация сервера;
• конфигурация развертывания;
• совместимость операционной системы;
• имя домена;
• функциональный уровень леса;
• функциональный уровень домена;
+ DNS;
• расположение файлов;
• пароль администратора DSRM (Directory Services Restore Mode — режим вос­
становления службы каталогов).
Все эти моменты будут подробно обсуждаться в последующих разделах главы.

В Microsoft упростили ситуацию с версиями и предлагают всего две редакции
Windows Server 201 2, которые можно использовать при настройке контроллеров до­мена: Standard и Datacenter. Между ними нет отличий в функциональности, доступ­ности или компонентах. Разница касается условий лицензирования и количества виртуальных машин, которые можно запускать под управлением каждой редакции.
В начале книги отличия между этими двумя версиями объяснялись более подроб­
но. Когда необходимо установить контроллер домена, вы всегда можете выбрать ре­дакцию Windows Server 201 2 Standard, а если позволяет лицензионное соглашение,можете установить редакцию Windows Server 201 2 Datacenter. Следует также иметь в виду, что ОС Windows Server 201 2 доступна только в виде 64-разрядных версий;
32-разрядных версий не существует в принципе. Это важно при планировании мо­
дернизации контроллеров доменов. Модернизация на месте 32-разрядной системы
до 64-разрядной невозможна.

Конфигурация сервера

После установки редакции Windows Server 2012 Standard понадобится сконфигу­
рировать имя и IР-адрес сервера. Просто ради ясности: мы используем редакцию
Windows Server 2012 Standard, потому что ее функциональность идентична редакции
Windows Server 2012 Datacenter. Единственное отличие связано с лицензией.
Имя сервера
Перед повышением до контроллера домена компьютеру необходимо назначить
окончательное имя. Какие имена серверов следует считать удачными? Об именова­нии серверов можно было написать отдельную книгу, но есть несколько основных аспектов, которые должны быть приняты во внимание.
• Не применяйте в именах серверов название компании, отдела, региона или
другие имена, которые со временем могут измениться.
• Выбирайте короткие имена; администратор будет вам благодарен.
• Используйте аббревиатуры для идентификации серверных ролей.
Общепринятой схемой именования контроллеров доменов является DCOl, DC02
и т.д. Переименовать контроллер домена можно с помощью графического пользова­тельского интерфейса либо инструмента Netdom.
IР-адрес
Поскольку клиенты и серверы ищут контроллер домена с использованием DNS,
и ваш контроллер домена преимушественно имеет установленную роль DNS, вы
должны всегда назначать ему статический IР-адрес. В противном случае ваш конт­роллер домена превратится для других систем в движушуюся мишень при попытке его нахождения. Если вы конфигурируете только адрес 1Pv4, рекомендуется оставить включенным IPvб.
Вам может показаться, что все уже готово к запуску DCPromo. Неплохая идея, но вы получите лишь окно с сообшением о том, что это больше не работает.

Установка серверной роли контроллера домена
Чтобы установить серверную роль контролле­ра домена, понадобится запустить диспетчер сер­веров (Server Manager) и выбрать в меню Manage
(Управление) пункт Add Roles and Features (Добавить роли и компоненты), как показано на рис. 7.1 . Запустится мастер, который позволит выбрать роль
или компонент для установки. В Windows Server 2008
Man:;ge Т ools View Help
Add Roles and features
Remove Roles and Feat•Jres
J— — — —-
Add Servers
Create SeIVer Group
f—
Server Manager Properties
R2 для роли или компонента предусмотрены два от-
Рис. 7 .1. добавление к сер­
дельных мастера. Мастер добавления ролей и компо-
веру роли Active Directory
нентов (Add Roles and Features Wizard) установит все
двоичные файлы, необходимые для последующего запуска мастера конфигурирова­
ния службы домена Active Directoгy (Active Directoгy Domain Services Configuration
Wizard — ADDSCW).
Когда мастер завершит работу, вам нужно вернуться в окно диспетчера серверов
и щелкнуть на значке с восклицательным знаком желтого цвета (рис. 7.2).
Это предоставит возможность повысить сервер до контроллера домена (рис. 7.3).
Последующие шаги очень похожи на работу утилиты DCPromo, которая применя­
лась в версии Windows Server 2008 R2.
Мастер предложит несколько вариантов; вы должны либо выбрать, либо ввести
соответствующую информацию. В зависимости от выбранного варианта мастер бу­
дет изменять отображаемые экраны.

Конфигурация развертывания

Опция конфигурации развертывания позволяет указать, должен ли новый до­мен создаваться в новом лесе или же добавляться в существующий лес. Если вы­бран вариант добавления в существующий лес, можно добавить контроллер домена
к существующему домену (это будет показано позже в данной главе) либо создать новый домен.
Для первого контроллера домена выбор прост — будет создан новый домен в новом лесе.ПРОБЛЕМА АУТЕНТИФИКАЦИИ
Контроллеры доменов, функционирующие под управлением Windows Server 2008
и последующих версий, в том числе Windows Server 201 2, имеют опцию Allow
cryptography algorithms compatiЫe with Windows NT 4.0 (Разрешить криптографи­ческие алгоритмы, совместимые с Windows NT 4.0), которая по умолчанию отключе­на. Унаследованные криптографические алгоритмы, используемые -в Windows NT 4.0,могут быть взломаны с помощью современных технологий.
По этой причине в Mjcrosoft усилили защиту контроллера домена за счет настройки групповой политики, которая предотвращает вход из оборудования и клиентов, при­меняющих слабые криптографические алгоритмы Windows NT 4.0. Это может бытьклиент SАМ В А Server Message ВJock (SMB), который не способен установить безо­пасный канал с контроллером домена Wшdows Server 2008 или выше, либо устройство хранения SMB, не умеющее создать безопасный канал с контроллером домена. Чтобы обойти указанное ограничение, потребуется включить эту настройку в стандартной политике контроллеров домена (Defaнlt Domain Controllers Policy). Дополнительные сведения доступны по ссьmке http : / /support .microsoft . com/kЬ/942564/.

Совместимость операционной системы

В Windows Server 201 2 появилась файловая система ReFS (Resilient File System — отказоустойчивая файловая система). Эта файловая система более устойчива к отка­зам, чем NTFS. Она предоставляет более высокую uелостность и масштабируемость, а также обладает встроенной проактивной идентификацией ошибок. Из-за ее высо­ких качеств у вас может возникнуть искушение выбирать файловую систему ReFS для всех предстоящих проектов по развертыванию серверов, но, к сожалению, ей присущи ограничения, которые вы должны иметь в виду.
• Файловая система ReFS доступна только в Windows Server 2012.
• Файловая система ReFS используется только для томов данных. Не существует
методов применения ReFS на томе ОС или загрузочном томе.
Как администратор Active Directory, вы должны знать следующий передовой опыт.
• Дгlя хранения папки SYSVOL, базы данных Active Directory и журнальных фай­
лов Active Directory используйте только NTFS.
• Не устанавливайте папку SYSVOL на томе или диске, сформатированном с
файловой системой ReFS.
• Не устанавливайте базу данных Active Directory на томе или диске, сформати­рованном с файловой системой ReFS.
Если вы попытаетесь выбрать диск, сформатированный с файловой системой ReFS,
для папки SYSYOL, базы данных Active Directory или журнального файла, вы получите
сообщение об ошибке, указывающее на необходимость выбора диска NTFS.

Имя домена

Поскольку это первый контроллер домена, вы выберете вариант с добавлением но­вого леса. Таким образом, понадобится также установить DNS и глобальный каталог. И DNS, и GC являются обязательными для первого контроллера домена в лесе. Установить в качестве первого контроллера домена контроллер домена только для чтения (read­ only domain controller — RODC) невозможно, так что данная опция недоступна.

Именование корневого домена

Назначение имени корневому домену является, пожалуй, наиболее трудной час­тью работы, При настройке контроллера домена в испытательной среде заботиться
об имени нет необходимости. Но ситуация меняется, когда нужно построить домен или лес в производственной среде. Поскольку NetBIOS-имя домена будет появлять­ся где-то на стороне клиента, руководству может не понравиться видеть это имя на своих рабочих столах после входа в систему. Мы настоятельно рекомендуем обсу­дить и утвердить выбранное имя домена у ответственного менеджера.
На что должно быть похоже имя домена? Как вам известно, допустимое имя
корневого домена Active Directory выглядит подобно полному имени домена (fully qualified domain name — FQDN). В нем присутствуют две части: действительное имя и суффикс, такой как bigf irrn. с от, mydornain . local или forest . сот. Все они являются допустимыми именами доменов. В Windows Server 2003 можно было выбирать имя домена с единственной меткой наподобие bigfirm, rnydornain или forest, и оно поддерживалось Microsoft. Но по мере того, как приложения вроде Exchange развивались и начали зависеть от Active Directory и DNS, имена доменов с единственной меткой больше не разрешены. Если вы попытаетесь создать домен с единственной меткой в Windows Server 201 2, то получите сообщение об ошибке.
Во второй части домена верхнего уровня можно применять суффикс.
Ниже перечислены преимущества наличия одного и того же имени для Active
Directory и публичного DNS-имени, такого как bigfirm. com.
• Адреса URL веб-приложений компании одинаковы независимо от того, внутренние они или внешние.
• Открытые сертификаты можно использовать внутренне.
• Адрес SIP в Lync имеет тот же самый вид, как адрес электронной почты и ад­рес входа в систему.
• Учетные данные для входа в систему могут применяться в качестве адреса
электронной почты.
Один из крупных недостатков заключается в том, что с точки зрения брандмауэра нелегко различать внутренние и внешние зоны. Многие администраторы специально стараются избегать использования имен доменов верхнего уровня Интернета, чтобы не путать их с внутренними сетями.
Как видите, с каждым вариантом связаны свои достоинства и недостатки. В це­
лом мы не можем рекомендовать какое-то одно соглашение об именовании. В кон­
це концов, имя должно соответствовать существующим у вас техническим требова­ниям и также удовлетворять политике безопасности, принятой в компании.

Active Dlrectory и DNS

Важно знать, что Active Directory сильно зависит от DNS. Нет DNS, не будет и
Active Directory. Почему? Active Directory регистрирует все типы записей служб (SRV)в DNS, чтобы находить специфичные службы, которые необходимы для коррект­ного функционирования Active Directory. Приблизительно 80% проблем нерабочей службы Active Directory имеют отношение к DNS.

Когда вы установите свой контроллер домена, отобразится диалоговое окно с
предупреждением о том, что не удается создать делегирование для DNS. Причина
связана с тем, что мастер настройки Active Directory конфигурирует DNS; он так­же пытается создать делегирование для DNS-cepвepa, однако он еще не установлен. Закройте это диалоговое окно и продолжайте.

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

Во время работы мастер настройки Active Directory предЛожит выбрать функциональный уровень домена. Функциональный уровень домена зависит от опера­ции.

В ранних версиях Windows Server компоненты, доступные в лесе домена, зависе­ли от функциональных уровней Active Directory.
Функциональный уровень домена Windows Server 2003
• Можно переименовывать контроллеры доменов с помощью Netdorn. ехе.
• Добавлен атрибут lastLogonTirnestarnp.
• Имеется возможность переадресации контейнеров Users (Пользователи) и
Cornputers (Компьютеры).
• Подuерживается избирательная аутентификация для указания, кто имеет до­
ступ к тем или иным ресурсам в доверенном лесе.
• Имеется ограниченное делегирование с целью зашиты учетных данных деле-
гированног»° пользователя с применением Kerberos.
Функциональны й уровень домена Windows Server 2008
• Предоставляется подuержка DFS-R для папки SYSVOL.
• Доступна подuержка алгоритмов шифрования AES 128 и AES 256 для KerЬeros.
• Предоставляется детальная информация о последнем интерактивном входе в
систему.
• Используются детализированные политики паролей.
Функциональны й уровень домена Windows Server 2008 R2
• Обеспечение механизма аутентификации определяет метод входа в систему,
применяемый пользователем. Это хранится в маркере KerЬeros.
• Автоматическое управление SPN доступно для учетных записей управляемых
служб (Managed Sel’ice Accounts).
Функциональны й уровень домена Windows Server 2012
• Подuержка КОС доступна для утверждений, комплексной аутентификации и
защиты Kerberos через две настройки: Always provide claims (Всегда предостав­лять утверждения) и Fail unarmored authentication requests (Отклонять незащи­щенные запросы на аутентификацию).
За подробным списком возможностей, доступных на каждом функциональном
уровне, обращайтесь по следующему URL:
http : / /technet . mi crosof t . com/en-us / l ibrary/
understanding-active-directory-functional-levels (WS . 1 0 ) . aspx

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

Функциональные уровни леса идентифицируют возможности внутри леса.
Функциональные уровни домена зависят от операционной системы контроллеров
домена, а функциональные уровни леса — от функциона..�ьного уровня домена.
Поднять функциональный уровень леса выше самого низкого функционального
уровня домена в лесе невозможно.
Функциональный уровень леса также можно выбирать во время установки Active
Directory. Подuерживаются следующие функциональные уровни леса:
• Windows Sel’er 2003
• Windows Server 2008
• Windows Sel’er 2008 R2
• Windows Sel’er 2012
Как и с функциональным уровнем домена, функциональный уровень леса можно
поднимать после того, как был повышен DC. Сначала понадобится поднять функ­
циональный уровень каждого домена в лесе до одного и того же уровня, а затем под­нять до такого же уровня функциональный уровень леса. Помните, что прежде чем можно будет поднять функциональный уровень леса, все функциональные уровни домена должны быть одинаковыми (рис. 7.5).

Рис. 7.5. Выбор функционального уровня леса в мастере ADDSCW
Точно так же как разные функциональные уровни домена добавляют средства
к домену, разные функциональные уровни леса предоставляют разнообразные воз­
можности.
• Wmdows Server 2003. Функциональный уровень леса Windows Server 2003 под­
держивает следующие средства.
• Возможность создания доверительных отношений в лесе.
• Возможность переименования домена.
• Возможность развертывания контроллера домена только для чтения
(RODC).
• Усовершенствованное средство проверки целостности знаний (Knowledge
Consistency Checker — КСС).
• Усовершенствованная репликация связанных значений (linked-value
replicatioп), при которой реплицируются только различия членства в группах.
• Перечисление на основе доступа в пространстве имен DFS.
• Windows Server 2008. Функциональный уровень леса Windows Server 2008 не
предлагает каких-то дополнительных возможностей.
• Wmdows Server 2008 R2. Корзина Active Directory (Active Directory Recycle Bin) позволяет восстанавливать удаленные объекты без необходимости в переза­
пуске контроллера домена в режиме восстановления Active Directory (Active
Directory Restore Mode). Вы должны включать поддержку Active Directory
Recycle Bin с использованием командлетов PowerShell. Корзина Active
Directory — это великолепное средство, которое было улучшено в Windows
Server 201 2. Теперь корзину намного проще настраивать и управлять ею, как
будет показано далее в этой книге.

• Windows Server 2012. Функциональный уровень леса Windows Server 2012
не предлагает каких-то дополнительных возможностей.
Что измЕнилось в ФУнкциондльных УРовнях WrNDows SERVER 2012 R2
При написании этой книги мы пользовались предварительной версией Windows
Server 201 2 R2. Хотя в Active Directory мало что изменилось, внесены определенныеизменения в функциональные уровни по сравнению с предшествующей версией.
Контроллер домена Windows Server 2012 R2 можно добавить в существующую среду с функциональным уровнем Wtвdows Server 2003. Но примите во внимание, что функци­ональные уровни домена и леса Wmdows Server 2003 объявлены устаревшими. Во время развертывания Windows Server 2012 R2 в существующей среде Wmdows Server 2003 бу­дет предложено перейти на более высокий функциональный уровень. Самым низким функциональным уровнем, который можно выбрать в Wiпdows Server 2012 R2, явля­ется функциональный уровень домена и леса Wшdows Server 2008. Полномасштабный обзор нового функционального уровня доступен по следующей ссылке: http : //technet . microsoft . com/en-us/library/
understanding-active-directory-functional-levels . aspx

Местоположения для файлов и папки SVSVOL

Мастер Active Directory Domain Services Configuration Wizard запросит местополо­жение для различных файлов Active Directory и для общей папки SYSVOL.
Общая папка SYSVOL применяется для совместного использования информации, такой как сценарии и элементы объектов групповой политики, контроллерами домена. Папка SYSVOL, база данных Active Directory и журнальные файлы должны быть помещены на диск, сформатированный с файловой системой NTFS. База данных и журнальные файлы могут располагаться на разных дисках при условии, что они сформатированы как NTFS (рис. 7.6).В Windows Server 2012 появилась новая файловая система Resilient File System
(ReFS), которая предлагает более высокую uелостность и масштабируемость и об­ладает встроенной проактивной идентификаuией ошибок. Вы можете подумать,
что она была бы наилучшим местом для размешения какого-то компонента Active
Directoгy, но как обсуждалось ранее, это не поддерживается, т.е. в ReFS нель3я помещать ни бюу данных Active Diгectoгy, ни журнальный файл Active Diгectoгy, ни папку SYSVOL.
В своей основе Active Diгectoгy является крупной базой данных, а базы данных
имеют основной файл данных и файл журнала транзакuий. Изменения, предназна­
ченные для базы данных, сначала записываются в файл журнала транзакций, кото­рый впоследствии периодически проверяется — это просто необычный способ ука­зать, что изменения в файле журнала транзакций зафиксированы в базе данных.Журнал транзакuий обеспечивает для базы данных Active Diгectoгy высокую отказоустойчивость и возможности восстановления. Если на сервере пропадает элек­тропитание где-то в середине процесса внесения изменения, с помошью этого журнала Active Directoгy может гарантировать, что после перезагрузки сервера база
данных будет находиться в согласованном состоянии. Любые изменения, занесенные
в журнал, фиксируются в базе данных, а незавершенные изменения, записанные в журнале, игнорируются.
С точки зрения производительности возможно увеличение производительности
DC путем перемещения файлов журнала траюакций на другие диски. Для достижения оптимальной производительности Active Directory вы можете применять конфи­гураuию, подобную показанной ниже:
• диск С: — операuионная система;
• диск D: — файл базы данных Active Diгectoгy и папка SYSVOL;
• диск Е: — файл журнала транзакuий.
При такой конфигурации каждый диск должен быть отдельным шпинделем (от­
дельным физическим диском). Единственный диск с тремя разделами не даст ника­кого выигрыша в производительности. Вдобавок, если дисковые устройства имеют разные скорости, вы должны поместить ОС на самый быстрый диск, файл журнала транзакций — на следующий в порядке убывания скорости диск, а папку SYSVOL — на самый медленный диск. С операционной системой и журналом транзакций связано наиболее интенсивное использование.
Чтобы еше немного оптимизировать контроллер домена, можно провести различие между интенсивными операциями чтения и интенсивными операuиями записи.
При наличии интенсивных операuий чтения вы должны предоставить контроллеру
домена столько памяти, чтобы было достаточно для кеширования базы данных в па­мяти. В случае интенсивных операuий записи улучшить производительность можно за счет добавления следующего оборудования:
• аппаратные контроллеры RAJ D;
+ диски с высоким числом оборотов в минуту;
• батарейный модуль кеширования (batteгy backed wгite-caching — BBWC) на
контроллере RAI D.

Все это звучит хорошо и имеет смысл, но что произойдет, если вы виртуализи­
руете свой контроллер домена? В таком случае неплохо добавить к контроJUJеру до­мена достаточный объем памяти, чтобы он мог кешировать базу данных. Если вы собираетесь размещать журнал транзакций, базу данных и папку SYSVOL на разных виртуальных дисках, то улучшения производительности, скорее всего, окажутся ми­нимальными. Проблема в том, что все виртуальные диски находятся под одним и тем же номером логического устройства (Logical Unit Numbeг — LUN), и данный номер LUN распространяется на весь массив дисков. Это значит, что все вирту­альные диски совместно используют те же самые физические диски в хранилище.
С теоретической точки зрения было бы лучше поместить каждый файл в отдельный
массив или LUN. В любом случае вы должны применять самое быстрое устройство
хранения из тех, что есть в наличии.
Хорошей отправной точкой при выяснении, имеется ли проблема с дисковой
производительностью, может быть просмотр перечисленных ниже счетчиков произ­
водительности. Каждый из этих счетчиков должен иметь низкое значение:
• Avg. Disk Queue Length (Средняя мина очереди к диску)
• Avg. Disk Read Queue Length (Средняя мина очереди к диску на чтение)
• Avg. Disk Write Queue Length (Средняя мина очереди к диску на запись)
Давайте рассмотрим пример. Если домен включает 100 пользователей, вы можете
хранить файлы базы данных и журнала транзакций на диске С: вместе с операционной системой и не заметить никаких проблем с производительностью. С другой стороны, если вы поддерживаете 50 ООО пользователей, то наверняка стремитесь контролировать малейшие аспекты производительности сервера, поэтому хотите разнести файлы базы данных и журнала транзакций по разным дискам. При постро­ении тестовой системы можно благополучно оставить все на диске С:.
ПЕРЕМЕЩЕНИЕ ФАЙЛОВ БАЗЫ ДАННЫХ И ЖУРНАЛА ТРАНЗАКЦИЙ
В Wiпdows Server 20 l 2 бьша введена перезапускаемая служба Active Directory Domai11 Services (AD DS), которую можно применять для выполнения задач по управлению базой данных без необходимости в перезапуске контроллера домена в режиме восстановления службы каталогов (Directory Services Restore Mode — DSRМ). Если нужно переместить журнал или базу данных на другой диск, можно воспользовать­ся утилитой командной строки NTDSUtil. Из-за характеристики AD DS перезапус­кать контроллер домена в режиме DSRM не придется; понадобится лишь остановитьслужбу Windows AD DS и выполнить задачу.

Пароль администратора Directorv Services Restore Mode

Если когда-либо придется проводить обслуживание или восстановление Active
Directory, вы будете применять режим Directory Services Restore Mode. Для доступа к режиму DSRM нажмите клавишу , чтобы попасть в меню Advanced Options (Дополнительные опции). Это меню также позволяет получить доступ к различным опциям Safe Mode (Безопасный режим).
После выбора Directory Services Restore Mode будет преможено войти в систе­
му. Тем не менее, Active Directory не запускается, поэтому использовать учетную запись Active Directory нельзя. Вместо этого будет применяться специальная учетная
запись администратора с другим паролем. Мастер Active Directory Domain Services
Configuration Wizard предлагает установить этот пароль, как показано на рис. 7.7.

Рис. 7. 7. Установка пароля администратора режима Directory Services
Restore Mode
Обязательно документируйте устанавливаемый здесь пароль. Многие организа­
ции документируют критически важные пароли, записывая их и сохраняя в безопасном месте. Без этого пароля доступ к режиму DSRM невозможен. Иногда пароль учетной записи администратора DSRM путают с паролем обычного администрато­ра, устанавливаемым для учетной записи Domain Admins (Администраторы домена), но это разные пароли. С точки зрения безопасности пароль администратора DSRM критически важен для того, чтобы локально войти в систему контроллера домена и получить доступ к базе данных Active Directory. Если вы осознаете, что в этой базе данных хранятся все пароли, то весьма ответственно отнесетесь к тому, где сохра­нить пароль администратора DSRM.

Запуск мастера Active Directory Domain Services configuration Wizard

Теперь, когда вам известно, с чем вы столкнетесь, можно переходить к добавлению роли Active Directory и запуску мастера Active Directory Domain Services Configuration Wizard. В Windows Server 2012 добавление роли Active Directory по су­ществу приводило к добавлению всех необходимых двоичных файлов, после чего можно бьuю конфигурировать Active Directory.
В приведенных далее шагах предполагается наличие чистой установки Windows
Server 2012 без каких-либо дополнительных установленных ролей.

ИЗМЕНЕНИЕ ПАРОЛЯ АДМИНИСТРАТОРА DSRM
При наличии 1 00 контроллеров домена довольно трудно контролировать каждый
пароль администратора DSRM. Вдобавок может потребоваться изменить какой-то
пароль DSRM. Изменить пароль можно старым способом, запустив утилиту DSMGMT или NTDSUtil на функционирующем контроллере домена. Для изменения пароля DSRМ входить в режим DSRМ не понадобится. За дополнительными сведениями поэтому поводу обращайтесь к следующей ссьmке:
http : //technet .microsoft . com/en-us /library/cc75334 3 . aspx
Один странный способ сохранения пароля DSRМ известным в случае его изменения предполагает его синхронизацию с паролем учетной записи какого-то пользователя домена. Как это работает? Для начала необходимо создать учетную запись пользо­вателя домена, к примеру, DSRМAccount. Это может быть учетная запись обычного пользователя домена.
Теперь учетная запись администратора DSRM синхронизирована с учетной записью DSRМAccount в Active Directory. Однако это синхронизирует пароль не навсегда, а только на данный �юмент. Таким образом, если вы измените пароль учетной записи DSRМAccount, вам придется выполнять показанную выше команду еще раз. Здесь можно щ1бо применять объект GPO ко всем контроллерам домена посредством за­планированной задачи, чтобы запускать эту команду на регулярной основе, либо на­писать сценарий PowerShell ддя вьmолнения команды на всех контроллерах домена.
В будущем нужно лишь запустить утилиту С : WindowsSystem32NTDSUtil . ехе и предоставить ей следующие параметры:
«SET DSRМ PASSWORD» «SYNC FROM DOМAIN ACCOUNT DSRМAccount» Q Q
По данной теме в TechNet имеется исчерпывающая статья:
http : //Ьlogs . technet . com/Ь/askds/archive/2009/03/11/
ds-restore-mode-password-maintenance . aspx

В случае если есть дополнительные устаноменные роли, вы можете столкнуться
с небольшими отличиями.
1. Войдите на сервер Windows Server 201 2 с использованием учетной записи, име­ющей полномочия администратора.
2. Откройте диспетчер серверов (Server Manager) и выберите в меню пункт
ManageqAdd Roles and Features (УпрамениеQДобавить роли и компоненты).

3. Просмотрите сведения на экране Before you begin (Прежде чем начать) мастера.
4. Выберите переключатель Role-Based ог Feature-Based installation (Установка
на основе ролей или на основе компонентов) и щелкните на кнопке Next
(Далее).
5. Выберите целевой сервер из пула серверов (рис. 7.8).
6. Выберите роль Active Directory Domain Services (Служба домена Active Directory)и добавьте рекомендуемые компоненты, такие как Remote Server Administration Tools (Инструменты дистанционного администрирования серверов).
7. На экране Features (Компоненты) ничего выбирать не придется.
8. Просмотрите сведения на экране Active Directory Domain Services.
9. Если вы хотите перезапустить сервер автоматически, отметьте флажок Restart the destination server automatically if required (При необходимости автоматичес­ки перезапускать целевой сервер).
После установки двоичных файлов в диспетчере серверов появляется значок с
восклицательным знаком желтого цвета.
10. Щелкните на этом значке с восклицательным знаком и затем щелкните на
ссьшке Promote this server to а domain controller (Повысить этот сервер до кон­троллера домена).
Это приведет к запуску мастера Active Directory Domain Services Configuration
Wizard.
1 1 . На экране Deployment Configuration (Конфигурация развертывания) мастера выберите переключатель Add а new forest (Добавить новый лес) и введите имя корневого домена (рис. 7.9). Укажите желаемое имя домена, состоящее из двух частей. Щелкните на кнопке Next.
12. Оставьте дЛЯ функциональных уровней леса и домена стандартные варианты
Windows Server 2012. Удостоверьтесь в том, что флажок возле Domain Name
System (DNS) Server (Сервер системы доменных имен (DNS)) отмечен, чтобы
установить роль DNS. Флажок возле Global Catalog (GC) (Глобальный каталоr
(GC)) уже отмечен и это изменить нельзя, поскольку данный сервер является
первым контроллером домена в домене. Два раза введите пароль администра­
тора Directory Services Restore Mode (DSRM). Щелкните на кнопке Next.
Active Directory попытается найти DNS-cepвep. Если предварительно настроен­
ный DNS-cepвep отсутствует, вы получите предупреждение с указанием на то,
что зона мя вашего домена не может быть создана. Это вполне нормально.
13. Для продолжения щелкните на кнопке Next.
14. Нет никаких причин изменять имя NetBIOS для домена. Оставьте имя, пред­
ложенное по умолчанию, и щелкните на кнопке Next.
15. Отобразятся пути к файлу базы данных, файлу журнала и папке SYSVOL. Эти
пути можно было бы изменить, но примите стандартные варианты и щелкните
на кнопке Next.
16. Просмотрите выбранные опции на экране обзора и щелкните на кнопке Next.
Обратите внимание на кнопку View script (Просмотреть сценарий) справа вни­
зу (рис. 7. 10). В результате щелчка на этой кнопке откроется окно редактора
Notepad с подготовленными командами PowerShell мя настройки леса соглас­
но выбранным ранее опциям.
17. Просмотрите команды и их опции (рис. 7.1 1).
Командное окно PowerShell можно открыть на любом сервере Windows Serv­er 2012, где установлена роль Active Directory Domain Services, и скопировать в него эти команды. В окне командной строки PowerShell будет запрошен па­роль DSRM. По причинам безопасности мастер скрывает пароль, поэтому он не виден в сценарии PowerShell.Но если вы хотите, чтобы пароль не запрашивался каждый раз при запуске
сценария, можете воспользоваться строкой, добавленной в предыдущем при­
мере, которая поместит пароль в сценарий:
-Sa feModeAdrninistratorPassword ( ConvertTo-SecureString «P@sswOrd»
-AsPlainText -Force ) ‘
18. По завершении мастера вы окажетесь на экране Prerequisite Check (Проверка
предварительных условий), на котором отобразятся два предупреждения, но
мастер с помощью галочки зеленого цвета укажет на то, что проверка всех
предварительных условий прошла успешно, Как обсуждалось ранее, выда­
ча таких предупреждений вполне нормальна. Щелкните на кнопке lnstall
(Установить).

Установка леса займет некоторое время. По завершении работы мастера и не­
скольких перезагрузок вам будет предложено войти в систему.
19. Нажмите комбинацию клавиш , чтобы войти в систему.
Пароль для учетной записи администратора домена — это тот же самый па­
роль, который был указан для учетной записи локального администратора до
запуска мастера Active Directory Domain Services Configuration WIZard.
На этом все. Вы создали лес с единственным доменом. Следующий логический
шаг заключается в создании резервного контроллера домена.
На рис. 7.12 показан экран для шага 17, когда осуществлялось повышение серве­ра до контроллера домена Windows Server 2012 с применением PowerShel.
Рис. 7 .12. Установка контроллера домена с использованием PowerShell
ДИСТАНЦИОННОЕ АДМИНИСТРИРОВАНИЕ WINDOWS SERVER 2012
Сервер Wmdows рекомендуется администрировать, не входя в систему самого сервера;
взамен на клиенте можно установить инструменты Remote Server Administratioп Tools
(RSAT). Инструменты RSAT предлагаются в виде отдельно загружаемого файла.
Инструменты RSAT для Windows 8 могут управлять Wmdows Server 2012, а также име­ют ограниченную функциональность для Windows Server 2008 и Wmdows Server 2003.
Обзор о том, чем можно управлять в той или иной версии Wiпdows Server доступенпо ссылке:
http : / /support . microsoft . com/kЬ/2 693643
Чтобы загрузить RSAT для Windows 8, проследуйте по ссылке:
http : //www . microsoft . com/en-us /download/details . aspx?id=28 972
Инструменты RSAT для Wmdows 8. 1 необходимы для управления Windows Server 2012
R2 и Windows Server 201 2. Они также предлагают ограниченную функциональность
для управления Windows Server 2008 R2 и Wi11dows Server 2008. Чтобы загрузить RSAT
для Wiпdows 8. l, проследуйте по ссылке:
http : //www . microsoft . com/en-us/download/details . aspx?id=39296

добавление второго контроллера домена
Всегда когда это возможно, вы должны иметь nторой контромер домена, который
намного упростит задачу nосстановления после аварии. Единственный контромер до­мена создает значительный риск, т.к. становится точкой потенциального отказа. В слу­чае утери его работоспособности перестанет функционировать вся сеть и ситуация ста­нет критической. В этом отношении в Windows Server 2012 ничего не изменилось.
Когда есть второй контромер домена, то при отказе одного из контроллеров сеть продолжит работать. Пользователи по-прежнему будут иметь возможность входа в до­мен, их работа не прерывается, групповые политики применяются, и могут выпол­няться обычные задачи администрирования. Ситуация не будет критической, хотя работы nам прибавится. Кроме того, восстанавливать отказавший ОС намного проще, если в домене имеется другой функuионирующий ОС. Если уж на то пошло, то вы можете даже создать совершенно новый DC, не прибегая к резервной копии. Когда откажет последний ОС в домене, вам придется воспользоваться резервной копией Active Oirectory, и восстановление домена потребует значительного объема работы.
Помимо этого, вам придется терпеть нависающих над головой нервных менеджеров, непрерывно вопрошающих «Долго еще?» или «Могу я чем-нибудь помочь?».
Точно так же как вы запускали мастер Active Oirectory Domain Services Configuration Wizard для создания первого ОС, вы запустите его д11Я создания второго ОС. Для до­бавления контроллера домена необходима учетная запись с разрешением Oomain Admins. Также понадобится принять во внимание следующие аспекты:
• конфигурация развертывания;
• DNS;
• глобальный каталог.

Прежде чем запускать мастер Active Directory Domain Services Configuratlon Wizard

Установите роль Active Directory Oomain Services на сервере с чистой установкой Windows Server 2012 с помощью мастера Add Roles and Features Wizard. Затем нуж­но иметь статический IР-адрес, назначенный второму контроллеру домена. lР-адрес ONS-cepвepa указывает на первый ОС, чтобы сервер мог найти домен.
Вам необходим доступ к свойствам TCP/lP сетевого адаптера. Для этого выполните перечисленные ниже шаги.
1. Нажмите комбинацию клавиш на клавиатуре сервера с Windows
Server 201 2.
2. Введите ncpa. cpl и щелкните на кнопке ОК.
3. Щелкните правой кнопкой на элементе Local Area Connection (Подключение
по локальной сети) и выберите в контекстном меню пункт Properties
(Свойства).
4. Выберите в списке компонент lnternet Protocol Version 4 (TCP/1Pv4) (Протокол Интернета версии 4 (TCP/1Pv4)) и шелкните на кнопке Properties (Свойства).
Удостоверьтесь в наличии статического lР-адреса, совместимого с вашей сетью.
5. Введите 1 Р-адрес ONS-cepвepa, как показано на рис. 7. 13.
В рассматриваемом примере DNS-cepвep имеет IР-адрес 1 92. 168.0.45.
6. Закройте все отрытые окна.
Вам не придется присоединять сервер к домену до того, как вы повысите его до
контроллера домена. Мастер конфигурирования автоматически выполнит необхо­
димые шаги и поместит объект этого компьютера в контейнер Domain Controllers
внутри Active Directory.

Конфигурация развертывания для второго контроллера домена

Поскольку домен уже имеется, вам доступны различные варианты конфигурации
развертывания. Чтобы добавить второй DC, понадобится выбрать переключатель
Add а domain controller to an existing domain (Добавить контроллер домена в сущест­вующий домен), как показано на рис. 7. 14.

Упомянутый переключатель необходимо выбирать для каждого нового контрол­
лера домена, добавляемого в домен. Чтобы создать дочерний домен, следует выбрать переключатель Add а new domain to an existing forest (Добавить новый домен в су­ществующий лес).

DNS-cepвep для второго контроллера домена

Должны ли вы добавлять DNS-cepвep ко второму DC? Конечно!
Если на первом DC функционирует DNS-cepвep (что рекомендуется), то на
втором DC также должен быть запущен DNS-cepвep. Если вы следовали шагам по
повышению первого DC, то он функционирует в зоне, интегрированной с Active
Directory. Добавляя DNS-cepnep ко второму DC, вы обеспечите избыточность с сов­сем небольшими накладными расходами. Второй DNS-cepвep можно также исполь­зовать для балансировки нагрузки.
Вспомните, что Active Directory зависит от DNS. Если нет доступных DNS­
cepвepoв для DC, чтобы просматривать записи SRV в поисках контроллеров доме­
нов и необходимых служб, Active Directory функционировать не будет. Для Active Directory чрезвычайно важно иметь работающую систему DNS.
При наличии двух DNS-cepвepoв можно сконфигурировать серверы и клиенты
на взаимодействие с ними обоими. Для компьютеров в сети рекомендуется указы­
вать один предпочитаемый и один альтернативный DNS-cepвep. Если предпочита­
емый DNS-cepвep не отвечает на запросы, компьютеры будут обращаться к альтер­нативному DNS-cepвepy.
Одна половина компьютеров должна использовать в качестве предпочитаемого
первый DNS-cepвep, а другая половина — второй DNS-cepвep.
В случае динамически назначаемых 1 Р-адресов можно сконфигурировать одну
половину областей видимости клиентов DHCP для развертывания первого DNS­
cepвepa как предпочитаемого, а вторую половину — для развертывания второго
DNS-cepвepa как предпочитаемого.
Очень важно запомнить, что после повышения сервера до контроллера домена
необходимо изменить настройки DNS сети. Удостоверьтесь, что у контроллера до­мена в качестве предпочитаемого DNS-cepвepa указан его собственный I Р-адрес.
По установившейся практике контроллеры домена всегда указывают на самих себя,если на них установлены DNS-cepвepы.

Глобальный каталог для второго контроллера домена

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

запуск мастера ADDSCW для второго контроллера домена

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

Отличия по РАЗМЕЩЕНИЮ ГЛОБАЛЬНОГО КАТАЛОГА
Вопросы относительно размещения GC возникают постоянно. Это хорошо прояснено
в статье КВ223346, которая доступна по ссьmке http: / /support .microsoft . com/kЬ/223346/ru.
Лес с единственным доменом
В лесе, который содержит единственный домен Active Directory, фантомы отсутству­ют. Фантом — это ссылка на объект в другом контексте именования. Например, если вы добавите пользователя В из домена В к группе А в домене А, то можете заметить, что на вкладке Members (Члены) окна свойств этой группы отображается значок другого вида. Он является фантомом. Поскольку такие фантомы не создаются, ра­бота для хозяина инфраструктуры отсутствует. Хозяин инфраструктуры может быть размещен на любом контроллере домена вне зависимости от того, содержит этот контроллер домена глобальный каталог или нет. Если вы пока не знаете, что собой представляет роль хозяина инфраструктуры и другие роли FSMO, прочитайте раздел
«Роли FSMO и их передача» далее в этой главе.
Лес с несколькими доменами
Если на каждом контроллере домена, входящего в лес с несколькими доменами, хра­нится также и глобальный каталог, то фантомы отсутствуют, а хозяин инфраструк­туры бездействует. В таком домене хозяин инфраструктуры может быть помещен на любой контроллер домена. На практике большинство администраторов размещают глобальный каталог на каждом контроллере домена в лесе.
Если в данном домене, входяmем в лес с несколькими доменами, нет ни одного конт­роллера домена с глобальным каталогом, то хозяин инфраструктуры должен быть поме­щенна контроллер домена, на который не планируется добавлять глобальный каталог.
Если вы уже присоединили его к домену, то столкнетесь с небольшими отличиями.
1 . Войдите на сервер с использованием учетной записи, имеющей полномочия
локального администратора.
2. Если это еще не сделано, установите роль Active Directory Domain Services, для чего откройте диспетчер серверов и выберите в меню пункт ManageqAdd Roles and Features (Управлениес:> Добавить роли и компоненты). После этого следуйте шагам мастера, как поступали при добавлении первого контроллера домена.
В качестве альтернативы можно было бы открыть окно командной строки
PowerShel и запустить следующий командлет; он установит те же самые ком­
поненты, как и в случае запуска мастера:
Add-WindowsFeature AD-Domain-Services , RSAT-AD-AdminCenter,
RSAT-ADDS-Tools , GPMC
3. В диспетчере серверов щелкните на значке с восклицательным знаком желто­
го цвета и затем щелкните на ссылке Promote this server to а domain controller (Повысить этот сервер до контроллера домена).
Если после выполнения командлета PowerShel значок с восклицательным зна­
ком желтого цвета не появился, щелкните на значке обновления в окне диспетчера серверов.

4. На экране Deployment Configuration (Конфигурация развертывания) мастера
выберите переI01ючатель Add а domain controller to an existing domain (Добавить контроллер домена в существующий домен). Укажите имя домена и предо­ставьте учетные данные администратора домена bigfirm. com. Если учетнаязапись, которую вы применяли для входа на сервер, не является членом груп­пы Domain Administrators (Администраторы домена), вам также понадобится
ввести другие учетные данные. Щелкните на кнопке Next (Далее).
ПРОБЛЕМЫ с АО? ПРОВЕРЬТЕ DNS!
Если вы получаете ошибку, указывающую на то, что с каким-то контроллером
домена не удается установить связь, проверьте корректность написания имени
домена и удостоверьтесь в наличии функционирующей службы DNS на DNS­
cepвepe. Проверьте, сконфигурирована ли система на использование этого DNS­
cepвepa. Проще всего пропинговать имя домена. Например, если домен имеет имя
Ьigfirm. сот, то выполнение команды ping Ьigfirm. сот должно дать четыре от­вета. Если не получено ни одного ответа, это четко указывает на то, что либо DNS­ cepвep недостижим (проверьте настройки TCP/IP и брандмауэра), либо служба DNSфункционирует некорректно.
5. На экране Domain Controller Options (Параметры контроллер домена) отметьте флажки Domain Name System (DNS) server (Сервер системы доменных имен (DNS)) и Global Catalog (GC) (Глобальный каталог (GC)), как показано на
рис. 7.15. Удостоверьтесь, что для имени сайте выбрано Default-First-Site-Name. Вам также необходимо ввести пароль DSRM. Распространенная практика пре­дусматривает выбор в качестве пароля DSRM на втором DC такого же пароля,
как и на первом DC. Щелкните на кнопке Next.
6. Если появится предупреждение о делегировании DNS, щелкните на кнопке
Next.

7. На экране Additional Options (Дополнительные параметры) можно указать, что установка Active Directory должна проводиться из носителя.
Для создания установочного носителя из текущей базы данных Active Direc­
tory можно воспользоваться утилитой NTDSUtil. Эта утилита создаст снимок
состояния базы данных на определенный момент времени, который впоследс­
твии можно предоставить мастеру ADDSCW в качестве источника. Преиму­
щество заключается в том, что в таком случае придется реплицировать толь­
ко изменения, внесенные после момента создания снимка. Эта возможность
очень удобна, когда есть медленный канал WAN и нежелательно реплициро­
вать базу данных Active Directory целиком по медленному каналу.
8. В данном случае выберите для репликации переключатель Any domain controller
(Любой контроллер домена). Щелкните на кнопке Next.
9. На экране Paths (Пути) оставьте без изменений пути для базы данных, файла
журнала и папки SYSVOL, а затем щелкните на кнопке Next.
10. На экране Review Options (Обзор параметров) просмотрите параметры и при
желании щелкните на кнопке View Script (Просмотреть сценарий), чтобы со­
хранить выбранные параметры для выполнения той же самой настройки в бу­
дущем. Щелкните на кнопке Next.
1 1. На экране Prerequisites Check (Проверка предварительных условий) удосто­
верьтесь в том, что проверка прошла успешно. Вы заметите те же самые пре­
дупреждения, которые обсуждались во время установки первого контроллера
домена. Щелкните на кнопке lnstall (Установить).
1 2. После завершения установки щелкните на кнопке Close (Закрыть) и контрол­
лер домена будет автоматически перезагружен.
13. Войдите в систему на контроллере домена, и мастер Active Directory Domain
Services Configuration Wizard завершит задачу.
Установка Active Directory из носителя
Ранее мы упоминали, что с помощью утилиты NTDSUt i l можно создать снимок
текушего состояния базы данных Active Directory и затем применять его для повы­шения до нового контроллера домена. Следуюший шаг заключается в копировании этого снимка на переносной диск или устройство и последующая установка конт­роллера домена с использованием данного носителя. Создание носителя подобного рода описано в детальном руководстве по установке AD DS, доступном в TechNet:
http : //techne t . microsoft . com/en-us/library/cc770654 . aspx

Создание организационных единиц, учетных записей и групп

После создания домена понадобится создать организационные единицы (OU),
учетные записи пользователей, учетные записи компьютеров, группы и т.д. На вы­бор доступны два средства: унаследованный инструмент Active Directory Users and Computers (Пользователи и компьютеры Active Directory ) , или ADUC, либо Active
Directory Administrative Center (Центр администрирования Active Directory ) , или ADAC. Будушие новые возможности и задачи по управлению Microsoft будет поме­щать в ADAC, поэтому имеет смысл приступить к работе с этой новой консолью.

Оба инструмента позволяют создавать что угодно с помощью простого приема
«указал и щелкнул». Тем не менее, все задачи можно также выполнить из команд­ной строки, предпочтительно PoweгSl1ell. Это очень удобно в паре ситуаuий:
• требуется создать или модифиuировать множество объектов, и вы желаете на­
писать сuенарий для проuесса;
• на сервере установлена версия Serveг Саге, и вы не хотите пользоваться инс­трументом ADUC или графическим интерфейсом ADAC.

Создание организационных единиц

Организаuионные единиuы применяются для организаuии объектов в рамках
Active Directory. Любой объект (такой как пользователи, компьютеры, группы и т.д.)
может быть помещен внутрь OU, чтобы упростить администрирование ним. Вот две
главные технические причины, по которым будет создаваться OU:
• управление посредством групповой политики (Group Policy);
• делегирование администрирования.

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

Объекты групповой политики (Group Policy object — GPO) могут быть созданы и
привязаны к сайтам, доменам и организационным единиuам. Если вы хотите, чтобы некоторым пользователям была назначена определенная групповая политика, мо­жете создать организаuионную единиuу, поместить в нее учетные записи и связать с ней объект GPO.
Однако если вы не создали ни одной организаuионной единиuы, то единствен­
ный способ назначения объектов GPO обычным учетным записям — делать это че­
рез стандартную политику домена (Default Domain Policy), которая в равной степени применяется к пользователям и компьютерам. Представьте себе, что вы хотите раз­вернуть приложение для всех пользователей в отделе продаж, используя групповуюполитику. Но если вы привяжете объект GPO к домену, то данное приложение полу­чат все пользователи компании, а не только пользователи отдела продаж.
Вместо этого имеет смысл создать OU (скажем, по имени Sales), переместить в
нее учетные записи пользователей и компьютеров отдела продаж и затем привязать объект GPO к организаuионной единице Sales. При наличии других групп или пользователей, к которым желательно применить спеuифичные объекты GPO, для них также можно создать OU и поместить туда соответствующие объекты пользова­телей и компьютеров.
Еще один способ применения объектов G РО к определенным объектам пользо­
вателей и компьютеров предусматривает создание группы доступа Active Directoryи добавления в эту группу всех пользователей, к которым требуется применить настройки политики. После создания и наполнения группы ее можно добавить в раздел Security Filteriпg (Фильтрация безопасности) объекта GPO и удалить стандар­тную группу Authenticated Users (Аутентифицированные пользователи) из на­строек Security Filtering. За более подробными шагами обращайтесь в главу 9, где показано, как выполнять эту и другие задачи.

центр администрирования Active Directorv

В версии Windows Server 2008 R2 центр администрирования Active Directory
(Active Directory Administrative Center) уже был встроенным, но создавать объекты с его помощью бьuю проблематично, так что использовалась консоль Active Directory Users and Computers. В Windows Server 2012 появился более развитый центр адми­нистрирования Active Directory. Он был перепроектирован и полностью основывает­ся на PowerShell. Теперь можно копировать последние команды из окон хронологии Windows PowerShell, изменять их и создавать собственный сценарий, позволяющий ускорить выполнение задачи.
Тем не менее, консоль Active Directory Users and Computers по-прежнему доступ­ на и работает в Windows Server 2012, предлагая ту же самую функциональность, что и в версии Windows Server 2008 R2.

создание организационных единиц с помощью ADAC

Чтобы создать организационную единицу с применением Active Directory
Administrative Center, выполните следующие шаги.
1 . Войдите в систему Windows Server 201 2. Щелкните на значке Active Directory
Administrative Center (Центр администрирования Active Directory). В качестве
альтернативы можно нажать комбинацию клавиш , чтобы от­
крыть окно Run (Выполнить), ввести dsac . ехе и щелкнуть на кнопке ОК.
2. Щелкните правой кнопкой мыши на имени домена и выберите в контекстном
меню пункт NewOrganizational Unit (СоздатьqОрганизационная единица).
3. Введите Sales в текстовом поле Name (Имя) и удостоверьтесь, что флажок
Protect from accidental deletion (Защитить от случайного удаления) отмечен
(рис. 7. 16).

Рис. 7 .16. Создание организационной единицы по имени Sales
ACTIVE DIRECTORY В WINDOWS SERVER 201 2 323
4. Щелкните на кнопке ОК, и организационная единица будет создана.
5. Допускается также создавать дочерние OU. Щелкните правой кнопкой
мыши на только что созданной организационной единице Sales и выберите в
контекстном меню пункт NewqQrganizational Unit.
6. Введите Users в текстовом поле Name и щелкните на кнопке ОК. На рис. 7. 17
можно видеть окно Active Directory Administrative Center с организационной
единицей Users, которая является дочерней по отношению к организацион­
ной единице Sales.

Рис. 7 .17. Организационные единицы в Active Directory Administrative Center
ЗАЩИТА от УДАЛЕНИЯ
Средство защиты от случайного удаления, включаемое путем отметки флажка Protect from accidental deletion, позволяет предотвратить неумышленное удаление объекта кем-нибудь (даже администратором). Несмотря на то что ADAC предлагает подтвер­дить удаление, многие из нас щелкают в таких диалоговых окнах, не замечая вопроса.
Тем не менее, если удалить объект действительно нужно, это можно сделать. Для этого в ADAC щелкните на объекте правой кнопкой мыши, выберите в контекс­тном меню пункт Properties (Свойства) и снимите отметку с флажка Protect from accidental deletion.
Вы можете обнаружить два объекта Users внутри Active Directory, но они совер­шенно разные. Организационная единица Users внутри OU под названием Sales -это организационная единица, с которой связаны объекты GPO. Контейнер Usersвнутри домена является только контейнером (не организационной единицей) и не может иметь связанные объекты GPO. Организационные единицы идентифицируются немного отличающимися значками — не просто папкой, а папкой с изобра­жением поверх; это напоминает о том, что они представляют собой нечто большее,чем всего лишь контейнер.

Отличительные имена LDAP

Для коммуникаций в Active Directory используется облегченный протокол доступа
к каталогам (Lightweight Directory Access Protoco — LDAP). В протоколе LDAP для
уникальной идентификации каждого объекта в каталоге применяется отличительное
имя (distinguished name — DN). Прежде чем взглянуть, как объекты создаются в ко­мандной строке или сценарии, необходимо разобраться с компонентами DN.
Формат DN выглядит как список конструкций типОбъекта=имяОбъекта, раз­
деленных запятыми. Например, домен по имени bigfirm. com содержит два ком­
понента (bigfirm и com), которые идентифицируются следующим образом:
dc=bigfirm, dc=com
Организаuионные единицы имеют тип объекта ou, а контейнеры U s e rs и
Computers идентифицируются посредством cn (common name — общее имя). Ниже
приведено отличительное имя для организационной единицы Sales:
ou=Sal e s , dc=bigfirm, dc=com
Контейнер Users имеет такое отличительное имя:
cn=Users , dc=bigfirm, dc=com
Контейнер — это объект Active Directory, который создается внутри Active
Directory, когда вы повышаете сервер до контроллера домена. Такой объект содер­жит стандартные пользователи и группы для Active Directory и также имеет полно­стью отличающиеся от организационной единицы атрибуты. Другое крупное отли­чие заключается в том, что к этому контейнеру не могут применяться групповые
политики.
Учетная запись с именем Sally. Smi th, находящаяся в организаuионной едини­uе Sales, имеет следующее имя DN:
cn=Sa l ly . Smith, ou=Sales , dc=bigfirm, dc=com
Учетная запись с именем Joe . Johnson, находящаяся в контейнере Users, имеет
такое имя DN:
cn=Joe . Johnson , cn=Users , dc=bigfirm, dc=com
Если организационная единица является вложенной или содержит внутри себя
другие OU, то в имени DN первой будет указана самая глубоко вложенная OU.
Например, если организационная единица Sales имеет дочернюю OU по имени
Users, внутри которой содержится пользователь по имени Maria, то DN будет вы­глядеть следуюшим образом:
cn=Maria, ou=Users , ou=Sales , dc=bigf irm, dc=com
Если имя DN включает пробелы, оно должно быть помещено в кавычки, чтобы
гарантировать его корректную интерпретацию. Например, приведенное ниже имя
не содержит пробелов, поэтому кавычки не требуются:
cn=�aria, ou�Users, ou=Sales , dc=bigfirm, dc=com

Однако то же самое имя ON с пробелом должно включать кавычки:
«cn=Maria, ou=Users , ou=Sales , dc=bigfirrn, dc=corn»
Имена ON в LOAP не чувствительны к регистру символов. Следующие два име­
ни ON будут интерпретироваться как один и тот же объект:
cn=Maria , ou=Users , ou=Sales, dc=bigfirrn, dc=corn
CN=Mari a , OU=Users , OU=Sales , DC=bigfirrn, DC=corn

Создание организационных единиц с помощью PowerShell

Средство PowerShell существует на протяжении нескольких лет, и со временем
важность его знания растет. В Windows Server 2008 R2 версия PowerShell 2.0 была встроенной и уже обладала развитой поддержкой мя множества компонентов и ро­лей. Благодаря объектной ориентации, PowerShell имеет цельную и хорошо спро­ектированную архитектуру. В Microsoft интенсивно продвигают PowerShell, поэтому его можно использовать мя управления практически всеми аспектами в Windows Server 2012.
В Windows Server 201 2 встроена версия PowerShel 3.0, а в Windows Server 2012 R2 — версия PowerShell 4.0, которые имеют огромное количество новых команд, предназначенных мя более легкого управления сервером. Исследование всех новых возможностей могло бы потребовать написания нескольких книги по этой теме.
Здесь мы лишь продолжим наш пример, чтобы дать вам о них общее представление.
Если вы не знаете, каким инструментом командной строки воспользоваться, скажем, DSAdd, Windows Script Host (WSH) или PowerShell, то изучайте PowerShell — он представляет собой технологию настоящего и будущего.
Если вы устанавливали второй контроллер домена в соответствии с приведенным
выше пошаговым руководством, то уже должны иметь доступ к командам Active
Directory PowerShe\. Проверьте, установлен ли компонент АО DS Snap-lns and
Command-Line Tools (Инструменты оснасток АО OS и командной строки). Чтобы
найти его, запустите мастер Add Roles and Features Wizard и щелкайте на кнопке Next (Далее) до тех пор, пока не попадете на экран, где выбираются компоненты.
Он должен выглядеть так, как показано на рис. 7.1 8.
В среде Windows Server 2012 щелкните на значке PowerShell в панели задач; этоприведет к открытию командного окна PowerShell, отображающего командную под­сказку PS С: Usersadrninistrator>. В следующем разделе вы узнаете, как с по­мощью PowerShell создать организационную единицу по имени PS _ ou.

PowerShell и Active Directorv

В PowerShell доступен крупный набор команд, для работы которых необходимо
предоставить только несколько дополнительных параметров. Такие команды называются команплетами и они являются главными рабочими лошадками в PowerShell.
При наличии определенных ролей, установленных в Active Directory, доступнно­вые команплеты, но для работы с ними сначала понадобится их импортировать в сеанс PowerShell. В большинстве случаев новые команплеты поступают в виде моду­лей, и пля того, чтобы сделать доступной их функциональность, эти модули необхо­димо загрузить.
Модуль импортируется следующим образом:
Import-Module ActiveDirectory
Процесс импорта требует некоторого времени, после чего снова появится командная подсказка. Затем введите команду для создания организационной единицы по имени PS ou:
New-ADOrganizationalUnit -Name PS_OU -Server DC02 .bigfirm. com
— Path «DC=Ьigfirm, DC=com»
Возможно, придется изменить имя сервера DC02 . Ьigfirm. com и компонент до­
мена «DC=Ьigfirm, DC=com», чтобы они соответствовали вашим действительным
именам. Если команда не работает, и вы получаете ошибку, первым делом удосто­верьтесь в отсутствии опечаток. Вообще PowerShell нечувствителен к регистру сим­волов, т.е. совершенно неважно, какими символами записана команда — прописны­ми или строчными.
В PowerShell 3.0 исчезла необходимость в предварительном импорте модуля с
помощью команды Import-Module ActiveDirectory, как делалось в примере.
PowerShell 3.0 распознает командлет New-ADOrgani zationalUnit и импортирует
соответствующий модуль. Если модуль был импортирован ранее, этот шаг пропус­кается.
Первый командлет New-ADOrgani zat ionalUnit состоит из глагола и сущес­
твительного английского языка, которые разделены дефисом (-). Это базовый
проектный принцип в PowerShell, направленный на упрощение запоминания ко­
мандлетов. Например, если вы хотите извлечь (get) организационную единицу AD
(AD organizational unit), то можете ввести Get-ADOrganizationalUni t, а для удале­ния (remove) организационной единицы ввести Remove-ADOrgani zationalUnit.
Командлету New-ADOrganizationalUni t предоставлялось несколько парамет­
ров, так что давайте кратко рассмотрим их. Параметр -Name указывает имя OU;
обратите внимание на наличие пробела между -Name и именем PS _ OU. Параметр -Server задает контроллер домена, где необходимо создать OU, а в параметре -Path указано местоположение новой OU. Предоставить можно намного больше парамет­ров. Чтобы увидеть все опции, введите Get-Help New-ADOrganzationalUni t или просто help New-ADOrganzationalUni t.

Вас может интересовать, существует ли способ создания сценария, который бы
ускорил выполнение задач. В рассматриваемом примере в этом мало смысла, пото­му что мы имеем дело всего лишь с одной строкой кода. Мы даже не затронули вер­хушку айсберга, но что, если вы хотите одновременно создать 10 организационных единиц, например, PS _ OUl, PS _ OU2 и т.д» удалить такие OU и воссоздать их? Для таких действий стоит создавать сценарий.
В Windows Server 2012 вы получаете интегрированную среду для разработки и
запуска сценариев PowerShell в готовом виде. Этот инструмент называется Windows PowerShell ISE (lntegrated Scripting Environment — интегрированная среда написания сценариев). Она представляет собой редактор сценариев, который помогает быстрее строить сценарии и также позволяет запускать сценарии прямо из консоли. Среда Windows PowerShell ISE имеет ряд великолепных средств наподобие Intelisense,
которое содействует в поиске подходящего командлета и предоставляет в разде­
ле команд детальные сведения о командлетах. Есть еще много чего для исследова­ний; здесь мы лишь кратко коснемся особенностей написания сценария в Windows
PowerShell ISE. Выполните перечисленные ниже шаги.
1 . Запустите Windows PowerShell ISE, щелкнув правой кнопкой мыши на значке
PowerShell в панели задач. В открывшемся контекстном меню вы увидите за­
дачу под называнием Windows PowerShell ISE.
Значок PowerShell должен быть закреплен в панели задач; если это не так, за­
пустите Windows PowerSheI ISE через меню Start (Пуск).
2. В меню View (Вид) удостоверьтесь, что возле Show Script Рапе (Показать па­нель сценария) имеется отметка.
3. В панели сценария (верхняя область белого цвета) среды Windows PowerSheI
ISE введите следующие строки (рис. 7 .19):
Обратите внимание, что во второй строке применяется цикл ForEach для
выполнения 10 итераций. $i содержит текущий номер итерации. Например,
при первой итерации цикла $i хранит число 1 , при второй итерации $ i со­
держит число 2 и т.д. На каждой итерации цикла выполняется командлет
New-ADOrgani zationalUnit. Поскольку вызов этого командлета необходимо
разнести на две строки, в конце третьей строки имеется символ обратной га­
лочки ( · ) , который позволяет перенести команду на следующую строку.
4. Выберите пункт меню Filec:::>Save As (Файлс:::>Сохранить как) и сохраните сце­
нарий в библиотеке Documents (Документы) под именем CreatelOOUs . psl.
В этот момент вы имеете сценарий PowerShell, который можно запускать, но,
скорее всего, он не может быть выполнен без изменения среды.
5. Возвратитесь в среду Windows PowerShell ISE. Введите Get -Ex и нажмите
клавишу . Обратите внимание на открывшееся меню, отображающее
все команды, которые начинаются с Get-Ex * . Такая функция называется
Intellisense. В данном случае в списке присутствует только один командлет,
Get-Execut ionPolicy.
6. Итак, командой будет Get-ExecutionPolicy. Нажмите . В панели
меню щелкните на значке воспроизведения в виде треугольника зеленого цве­
та или нажмите клавишу .
В случае стандартной установки результатом будет вывод слова Restr icted
(Ограничено) в окне синего цвета ниже панели сценария, а это значит, что за­
пустить сценарий не удастся.
7. Очистите панель сценария, введите следующую команду для изменения поли­
тики выполнения (Execution Policy) и нажмите клавишу :
Set-ExecutionPol icy RemoteSigned
8. В ответ на запрос изменения щелкните на кнопке Yes (Да). Это разрешит вы­
полнять локапьные сценарии.
9. Выберите пункт меню Filec:::>Open (ФайлОткрыть) и укажите ранее сохра­
ненный сценарий, C::reatelOOUs psl .
10. Теперь сценарий можно выполнить нажатием клавиши .
Есю1 все прошло успешно, вы можете запустить Active Directory Admiпistrative
Center и увидеть новые организационные единицы. В случае возникновения ошибок пересмотрите сценарий. Когда сценарий вводится впервые, ошибки будут нередким явлением, особенно при вводе длинных строк.

Создание учетных записей

После создания ряда организационных единиц понадобится создать определенные учетные записи. Для доступа в домен пользователям и компьютерам необходи­мы учетные ‘Записи.

POWERSHELL 4.0 в WINDOWS SERVER 201 2 R2
ОС Windows Server 2012 R2 поставляется с последней и самой лучшей версией
PowerShell 4.0. Важно понимать, что версия PowerShell 4.0 обратно совместима с бо­лее ранними версиями. Это означает, что наши примеры будут работать n Windows
Server 2012 PowerShell 3.0 и Windows Server 2012 R2 PowerShell 4.0.
Как и в случае организационных единиц, для создания учетных записей можно
использовать либо Active Directory Users апd Computers, Active Directory Administrative
Center и DSAdd, либо PowerShel.
Создание учетных записей компьютеров часто автоматизируется. Когда компью­
тер присоединяется к домену, для него автоматически создается учетная запись ком­пьютера. По умолчанию такая учетная запись создается в контейнере Cornputers
(Компьютеры), но это можно изменить с применением инструмента командной стро­ки Redircrnp, синтаксис использования которого выглядит следующим образом:
Redircmp DN
Например, если пользователь присоединил компьютер к домену, и вы хотите создать учетную запись компьютера в организационной единице Sales, то должны ввести такую команду:
Redircmp «OU=Sales, DC=Ьigfirm, DC=com»
Если необходимо вернуть стандартную настройку, введите команду:
Redircmp «CN=Computers , DC=Ьigfirm, DC=com»
Не забудьте привести настройки контроллера домена (DC=xxx) в соответствие с
вашей средой.

Создание учетных записей с помощью Active Directorv Administrative Center

Чтобы создать учетную запись пользователя с применением Directory Admi­
nistrative Center, выполните следующие шаги.
1. Запустите Active Directory Administrative Center, нажав комбинацию клавиш
для открытия диалогового окна Run (Выполнить), введите
dsac. ехе в текстовом поле и щелкните на кнопке ОК.
2. Щелкните правой кнопкой мыши на созданной ранее организационной еди­
нице Sales и выберите в контекстном меню пункт New�User (Создатьq
Пользователь).
3. Введите для пользователя имя, фамилию и имя для входа в систему.
4. Здесь же введите пароль, подтвердите его и удостоверьтесь, что выбран пере­
ключатель User must change password at next log оп (Пользователь должен из­
менить пароль при следующем входе в систему).
Это гарантирует, что пользователь изменит свой пароль, и никто другой не
будет знать его, даже вы. Диалоговое окно выглядит подобно показанному на
рис. 7.20.
ПОЛЬЗОВАТЕЛЬСКОЕ ИМЯ ДЛЯ ВХОДА В СИСТЕМУ
Компании обычно имеют установившийся стандарт, касающийся создания имя для
входа в систему. Распространены методы взятия инициала имени и полной фами­
лии, полных имени и фамилии, имени, точки и фамилии и т.п. Если вы начинаете
работу в новой компании, то должны ознакомиться с таким стандартом и следовать ему при создании учетных записей.
Если учетная запись совместно используется несколькими пользователями
(соответствует, к примеру, временной должности, занимаемой разными работниками), может понадобиться отметить флажок User cannot change password
(Пользователь не может изменять пароль). При создании учетных записей
служб (учетных записей пользователей, применяемых для запуска служб) вы
можете отметить флажок Password never expires (Срок действия пароля ни­когда не истекает), чтобы устаревание паролей не блокировало такие учетные
записи. Наконец, если учетную запись не планируется использовать в течение
какого-то времени, подумайте о том, чтобы ее отключить.
5. Просмотрите выбранные установки и щелкните на кнопке ОК.

Создание пользователей с помощью PowerShell

До появления PowerShell для создания пользователей и других объектов Active
Directory применялся инструмент под названием DSAdd. На то время это был хо­роший инструмент, а сейчас он считается унаследованным, но по-прежнему вели­колепно работает. Он может быть шагом в направлении пакетных сценариев и поз­воляет заглянуть в автоматизированный мир командной строки. Но единственный путь для получения полноценных возможностей автоматизации предусматривает использование PowerShel.
Подобно тому, как вы применяли PowerShel для создания организационных еди­
ниц, можно также создавать учетные записи пользователей. Вы будете удивлены,
узнав, что базовый командлет не особенно отличается от команды DSAdd. Вот этот
командлет:
New-ADUser -Path «OU=Sales, DC=Ьigfirm, DC=com» -AccountPassword
( ConvertTo- SecureString P@ssword -As PlainText -force )
-Name «Maria Smith» -Given:1ame Maria -Surname Smith ‘
-DisplayName «Maria Smith» -SamAccountName «Maria . Smith»
-UserPrincipalName «Maria . Smith@Ьigfirm . com» -ChangePasswordAtLogon 1
-EnaЫed 1
Приведенный пример команды PowerShell создает пользователя с именем Maria
Smi th. Преимущество инструмента PowerShel заключается в том, что он объектно­ориентирован.
Обратите внимание в этом примере, что мы можем не просто указать пароль в
форме строки; мы сначала преобразовываем строку в SecureString и затем пе­
редаем результат преобразования параметру -Acco unt P a s sword. Параметрам -ChangePassword.AtLogon и -EnaЬled необходимо значение булевского типа — о (для «ложь») или 1 (для «истина»). Остальная часть команды не требует особых пояснений.

создание групп

Также может понадобиться создать несколько групп. Самой распространенной
причиной создания групп является необходимость в объединении пользователей.
Более конкретно, глобальные группы доступа создаются для организации пользова­телей и последующего назначения этим группам нужных разрешений. Когда толь­ко возможно, вы должны назначать разрешения группам, а не пользователям. Вы могли слышать старое высказывание: «Пользователи приходят и уходят, но группы остаются навсегда». Даже если вы слышали его раньше, оно по-прежнему имеет смысл и позволяет запомнить, что разрешения следует назначать не пользователям, а группам.
Для примера предположим, что у вас есть несколько пользователей в отделе
продаж. Вместо назначения разрешений каждому индивидуальному пользовате­
лю из отдела продаж вы можете создать одну глобальную группу доступа по имени
G _ Sales, поместить в нее всех пользователей указанного отдела и назначить разре­шения группе G _ Sales.
Если пользователь покидает отдел продаж, вы удаляете его из группы G _ Sales, после чего он больше не будет иметь разрешений данной группы. Когда в отделе продаж появляется новый пользователь, вы помещаете его в группу G_Sales, и он получит те же разрешения, что и остальные пользователи группы.
Это звучит довольно просто, однако существуют и другие типы групп, каждая из
которых имеет свое предназначение. Группы бывают двух типов — рассьuтки и до­ступа. Группы рассылки используются для электронной почты, а группы доступа — для назначения разрешений. Группы доступа также могут применяться для элект­ронной почты.

Различают три области действия группы.
• Глобальная (global). Глобальные группы предназначены LUIЯ объединения поль­зователей. Это наиболее часто используемые группы, и одна такая группа бу­дет создаваться далее в главе. Пользователи помещаются в глобальные группы, которым назначены нужные разрешения.
• Локальная домена (domain local). В некоторых реализаuиях доменов локальные
группы домена применяются согласно принuипу AGDLP, где А означает «ac­
counts» (учетные записи), G указывает на «global groups» (глобальные группы),
DL означает «domain local groups» (локальные группы домена), а Р указывает
на «permissions» (разрешения). Учетные записи пользователей помещаются в
глобальные группы. Глобальные группы помещаются в локальные группы до­
мена, а локальным группам домена назначаются разрешения. При таком ис­
пользовании локальные группы домена являются дополнительным уровнем
для идентификаuии ресурсов. Рекомендуемый подход к разработке своей стратегии группирования предполагает применение принципа AGDLP.
• Универсальная (universal). Универсальные группы используются только в средах с несколькими доменами. Например, в сети имеются два домена, Europe и Uni tedStates, в каждом из которых есть глобальная группа G _ Sales. Можно создать универсальную группу UG _ Sales, членами которой будут эти две груп­пы G_Sales, т.е. UnitedStatesG_Sales и EuropeG _ Sales. Затем группу UG _ Sales можно использовать повсюду внутри предприятия. Любые измене­ния в членстве в отдельных группах G _ S a les не будут приводить к реrтикации группы UG_Sales. Теперь универсальную группу можно добавить в локальную группу домена и обеспечить распознавание ресурсов для отдела продаж по всему миру. Такая стратегия называется AGUDLP, где дополнительная буква Uозначает «universal group» (универсальная группа).
Самый распространенный способ создания описанных выше групп предусматривает применение инструмента Active Directory Users and Computers или Active Directory Administrative Center. Чтобы создать глобальную группу доступа, выполни­те следующие шаги.
1 . Запустите Active Directory Administrative Center, нажав комбинаuию клавиш
для открытия диалогового окна Run (Выполнить), введите
d.sac . ехе в текстовом поле и щелкните на кнопке ОК.
2. Щелкните правой кнопкой мыши на организационной единице Sales и выберите в контекстном меню пункт Newo::>Group (Создать�Группа).
3. Введите G _ Sales в поле Group name (Имя группы). Диалоговое окно должно
выглядеть похожим на показанное на рис. 7.2 1 . Щелкните на кнопке ОК.
4. Щелкните правой кнопкой мыши на организационной единице Sales и вы­
берите в контекстном меню пункт Newo::>Group. Введите G _ SalesAdmins в поле Group name. Щелкните на кнопке ОК.
Группа G _ SalesAdmins создана, и ей можно назначить разрешения, например,
делегировав управление организационной единице, как будет описано далее в главе.

Создание групп с помощью PowerShell (ADAC Windows PowerShell History)

В предыдущих примерах посредством PowerShell создавались организационные
единицы и пользователи. Мы показывали команды, необходимые для создания того
или иного объекта. А что если вы не знаете, какую команду применить, или хотите получить определенную помощь? Если при создании групп с использованием Active Diгectory Admiпistrative Ceпter вы следовали приведенным выше шагам, то все долж­но быть вам доступно.
1 . После создания группы G _ SalesAdmins щелкните на стрелке вниз внутри круга
справа от надписи Windows PowerShell History (Хронология Windows PowerShell) в окне консоли (рис. 7.22). Вы увидите все задачи, которые были ранее выполнены в
ADAC. Также вы должны видеть последние две команды New-ADGroup (рис. 7.22).
Рис. 7.22. Просмотр хронологии PowerShell
2. Щелкните на значке + слева от командлета, чтобы развернуть его и увидеть
все параметры.
3. Щелкните правой кнопкой мыши на первом командлете New-ADGroup, вы­
режьте и скопируйте его в окно PowerShel. Затем измените значения парамет­
ров -Name и -SamAccountName группы на что-нибудь другое, например:
New-ADGroup -GroupCategory : » Security»
-GroupScope : «Globa l »
-Name : «G SalesPowerUsers »
-Path : «OU=Sales , DC=bigfirm, DC=com»
-SamAccountName : «G SalesPowerUsers»
-Server : » DC02 . Ьigfirm . con»
4. Запустите команду, нажав .
Ес.1и ошибок не возникло, то вы только что создали еше одну глобальную группу.

Просмотр ХРОНОЛОГИИ Powershell

Вы видели на рис. 7.22, что задачи, которые ранее выполнялись в Active Directory
Administrative Center, транслируются в команды PowerShel и отображаются в панели
Windows PowerShell History. Поскольку средство ADAC построено поверх PowerShell,
все действия будут представлены внутри панели Windows PowerShell History в виде команд. В Windows Server 201 2 Active Directory имеется свыше 140 командлетов
PowerShel, поэтому изучение синтаксиса их всех займет очень много времени.
Таким образом, мы рекомендуем чаше заглядывать в панель Windows PowerShell
History, которая поможет в освоении этих команд.
В верхней части панели Windows PowerShell History присутствует несколько эле­ментов управления.
• Сору (Копировать). Ссылка Сору предназначена для копирования одной или
нескольких команд. Чтобы скопировать несколько команд, можно при нажа­
той клавише шелкать на нужных командах.
• Search (Поиск). С помощью поля Search можно искать любой командлет
внутри хронологии PowerShell. Просто начинайте вводить несколько первых
букв и панель сузится, отображая только результаты поиска.
• Start Task (Начать задачу) и Епd Task (Завершить задачу). Если вы хотите
сгруппировать свои команды, то перед выполнением любого действия в ADAC
можете щелкнуть на ссылке Start Task и указать имя задачи, а по завершении
действия щелкнуть на ссылке End Task. Для создания следующей группы ко­
манд эти шаги потребуется повторить.
• Clear All (Очистить все). Щелчок на ссылке Clear All приводит к очистке хро­нологии команд.
• Show All (Показать все). Когда флажок Show All отмечен, то каждая задача, вы­полняемая в ADAC, будет показана в панели Windows PowerShell History. Если
этот флажок не отмечен, будут отображаться только задачи, манипулирующие
Active Directory. По умолчанию флажок Show All не отмечен.

делегирование управления с использованием организационных единиц

Ранее в этой главе упоминалось, что одной из причин создания организационной
единицы является делегирование управления и, безусловно, одно из преимуществ
АО заключается в том, что вам позволено наделять частичными или полными административными полномочиями определенную группу пользователей. Это значит, что сеть с одним доменом можно разделить на такие организационные единицы, как Uptown (спальный район) и Downtown (деловой район), или Marketing (отдел маркетинга), Engineering (конструкторский отдел) и Management (отдел управле­ния), либо же иным образом. Вероятно, наиболее распространенным требованием или причиной делегировать управление организационной единице является предо­ ставление персоналу технической поддержки разрешения сбрасывать пароли поль­зователей. Еще одним часто запрашиваемым разрешением считается возможность
изменения только определенных атрибутов в объектах пользователей или групп.
Разумеется, на протяжении своей карьеры как администратора Active Directory вы столкнетесь со многими другими требованиями. Даже если вы не особо заинтересо­ваны в делегировании, в главе 9 будет дан хороший старт к делегированию управле­ния в Active Directory.

задачи обслуживания домена

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

Присоединение к домену

Чтобы присоединить сервер Windows Server 2012 к домену, выполните перечис­
ленные ниже шаги. После присоединения к домену сервер станет сервером-членом.
1. Войдите в систему на локальном сервере.
2. Откройте диспетчер серверов и щелкните на элементе Local Server (Локальный
сервер).
3. Щелкните на ссылке справа от слова Domain (Домен) в верхнем левом углу.
4. Откроется диалоговое окно System Properties (Свойства системы). Перейдите
в нем на вкладку Computer Name (Имя компьютера) и щелкните на кнопке
Change (Изменить).

5. Выберите переключатель Domain (Домен) и введите имя домена, к которо­
му нужно присоединиться. Диалоговое окно должно выглядеть похожим на
показанное на рис. 7.23, где видно, что система находится в рабочей группе
WORКGROUP, а на рис. 7.24 мы добавили домен, к которому необходимо присо­
единиться. Щелкните на кнопке ОК. Будет предложено предоставить данные
учетной записи, имеющей разрешение на вход в домен.
6. Введите учетные данные и щелкните на кнопке ОК.
7. Спустя некоторое время вы увидите диалоговое окно с приветствием.
Щелкните в нем на кнопке ОК. Будет выдано сообщение о необходимости
последующей перезагрузки компьютера. Щелкните на кнопке ОК.
8. Щелкните на кнопке Close (Закрыть), чтобы закрыть диалоговое окно
System Properties.
9. Вы получите еще одно напоминание о том, что сервер должен быть перезаг­
ружен. Щелкните на кнопке Restart Now (Перезагрузить сейчас).
После того, как сервер перезагрузится, он станет членом домена, т.е. сервером­
членом.
Автономное ПРИСОЕДИНЕНИЕ к ДОМЕНУ
В Windows Server 2008 R2 поя.вилась новая возможность, позволяющая присоединять
систему Windows 7 / Windows 8 или Windows Server 2008 R2 / Windows Server 2012 кдомену, не контактируя с контроллером домена. Это может быть удобно в ситуаuии, когда компьютер не располагает надежным подключением к корпоративной сети.
ОС Windows Server 2012 также предлагает эту возможность, но графический пользова­тельский интерфейс для ее конфигурирования по-прежнему отсутствует. Более под­робные сведения об автономном присоединении к домену приведены в статье Tecl1Net
по адресу http : / /technet .microsoft . com/en-us/library /dd392267 . aspx,
которая бьша обновлена для Windows Server 2012.

вывод из эксплуатации контроллера домена

Если возникает необходимость вывести из эксплуатации один из контроллеров
домена, крайне важно делать это корректно. При выведении его из эксплуатации вы удаляете все компоненты Active Oirectory и возвращаете контроллеру домена роль сервера-члена.
Правильный вывод из эксплуатации контроллера домена особенно важен, когда
это делается для первого ОС. Первый ОС в домене включает несколько ролей хозя­ина операций (Operations Master), иногда называемых ролями FSMO (FlexiЫe Single Master Operations — гибкие операции с одним хозяином), которые являются неотъ­емлемыми мя корректного функционирования домена. Если этот сервер просто от­кажет, и вы не сможете вернуть ему работоспособность, приготовьтесь к появлению
некоторых проблем, пока вы не выведете его правильно из эксплуатации.
Самый легкий метод вывода из эксплуатации контроллера домена предусматри­
вает запуск командлета PowerShel по имени Uninstall ADDSDornainCor_tro1ler. В Windows Server 2008 R2 была возможность запустить утилиту DCPromo, чтобы по­низить контроллер домена, но в версии Windows Server 2012 утилита DCPromo от­сутствует. Указанный команд11ет будет выполнять задачи, очень похожие на те, что
делала утилита DCPromo в прошлых версиях Windows. Если контроллер домена, на котором запускается данный командлет, все еще функционирует и содержит все роли FMSO, то командлет передаст эти роли новому контроллеру домена, понизит текущий контроллер домена, переместит объект компьютера из организационной единицы Doma in Controllers (Контроллеры домена) в контейнер Computers (Компьютеры) и позаботится о ряде других деталей. Роль сервера ONS по-прежнему будет установлена и работать, но если ваши зоны DNS бьиlИ интегрированными с Active Oirectory (Active Directory integrated — ADI), они больше не будут доступны.
Если такой сервер просто откажет, и вы не сможете запустить на нем Uпinstall­
ADDSDoma iпCoпtrol ler, то потребуется удалить И’J домена все зависимости от него, такие как записи SRV в DNS, которые указывают на этот контроллер доме­на, и другие глубоко скрытые следы в Active Directory. В предшествующих версиях Windows это был довольно долгий и утомительный процесс, при котором исполь­зовалась утилита NТDSUt i l и проводилось много ручной работы. Тем не менее, с помощью оснастки Active Directory Users and Computers, доступной в Windows Server 2012, можно просто удалить объект контроллера домена из организационной единицы Domaiп Coпtrollers и на этом все.
Для тех, кто проходил через длительный процесс анализа метаданных с помощью
NТDSUtil и других инструментов, это стало великолепным дополнением.
1. Запустите оснастку Active Oirectory Users and Computers и найдите в ней орга­низационную единицу Domain Controllers.
2. Отыщите контроллер домена, который необходимо вывести из эксплуатации.
Щелкните на нем правой кнопкой мыши и выберите в контекстном меню
пункт Delete (Удалить).
3. Удостоверьтесь в том, что выбрали корректный DC, и щелкните на кнопке
Yes (Да) в диалоговом окне с заnросом nодтверждения.
Откроется диалоговое окно с предупреждением, что вы пытаетесь удалить ОС
из AD, не используя мастер Active Oirectory Installation Wizard.

4. Отметьте флажок This Domaiп Coпtroller is permaпeпtly offliпe апd сап по
loпger Ье demoted usiпg the Active Directory Domaiп Services lпstallatioп Wizard
(DCPROMO) (Этот контроллер домена постоянно отключен и не может больше
понижаться с использованием мастера установки AD DS (DCPROMO)) и щел­
кните на кнопке Delete (Удалить), как показано на рис. 7.25.
Если этот DC является сервером глобального каталога, вы получите диалого­
вое окно с запросом, желаете ли продолжить.

Рис. 7.25. Удаление контроллера домена
5. Щелкните на кнопке Yes (Да).
Если сервер имел любые роли Operations Master, будет выдано сообщение о
необходимости передачи этих ролей (или роли) на другой контроллер домена.
6. Щелкните на кнопке ОК, и другой контроллер домена захватит эти роли
(роль).
Если отказавший контроллер домена позже восстановить, вы не сможете удалить
Active Directory с применением Uninstall-ADDSDomainControl ler. Однако су­
ществует обходной путь. Вместо ввода просто Uninstall-ADDSDomainController
введите Uninstall-ADDS DomainControl ler -ForceRemoval . Переключатель
-ForceRemoval позволит Active Directory удалиться без доступа к другому DC в домене. Этот командлет поддерживает и другие параметры, которые можно про­
смотреть, введя Get-Help Uninstall-ADDSDomainController. Например, пе­
реключатель -Force будет подавлять любые предстоящие предупреждения, что
может быть удобно при его использовании внутри сценария, а переключатель
-DemoteOperationМasterRole принудительно запустит понижение Active Directory, даже если обнаружена какая-нибудь роль Operations Master. Естественно, вы можете комбинировать все эти параметры для удаления Active Directory из висячего конт­роллера домена.

Устранение неполадок в AD DNS

Распространенная проблема, возникающая в DNS, заключается в том, что запи­
си SRV не создаются, когда сервер перезагружается. За создание этих записей отве­
чает служба netlogon, и временами она дает небольшие сбои после перезагрузки
сервера. В качестве напоминания: записи SRV применяются для нахождения в до­
мене контроллеров домена, выполняющих специфические службы или удерживаю­
ших определенные роли.

СПРАШИВАЙТЕ, ПРЕЖДЕ ЧЕМ УНИЧТОЖАТЬ
Согласитесь, было бы неruюхо иметь какое-то представление о будущем, чтобы уви­
деть, что произойдет, если предпринять определенные действия. Предположим, что у
вас есть контроллер домена, который вы хотели бы понизить, но не уверены, что были
удовлетворены все предварительные условия. Ваш друг PowerShell 3.0 предлагает ко­
мандлеты, которые вы можете опробовать, прежде чем действительно что-то сделать.
В данном примере вы можете запустить командлет Test-ADDSDomainContro ller
Uninstal lation. Он выполнит проверку; чтобы выяснить, удовлетворены ли все
предварительные условия для понижения. После запуска этого командлета вам будет
сообщено состояние успеха или отказа, а также другая полезная информация. Как и со всеми остальными командлетами, вы можете запустить Get-Help или просто Test-ADDSDomainControllerUninstallation, чтобы получить сведения о других необязательных параметрах для него.
По мере все большего погружения в PowerShell 3.0, вы обнаружите и другие ко­мандлеты Теst-, например, Test-ADDSDomainControl lerinstallation, Test­
ADDSDomaininstallation, Test-ADDSReadOnlyDomainControllerAccountCreation
и т.д. За дополнительной информацией по этой теме обращайтесь к статье TechNet
по адресу http : / /technet . microsoft . com/en-us/library/hh974719 . aspx.К примеру, службы внутри домена часто нуждаются в обнаружении сервера
глобального каталога, эмулятора РОС, контроллера домена внутри заданного сай­та или просто контроллера домена в рамках домена. Службы запрашивают у DNSсоответствующие записи SRV, и при условии, что они существуют, сервер может быть найден. Тем не менее, иногда такие записи не создаются после перезагрузки.
На рис. 7.26 показано окно консоли DNS Manager (Диспетчер DNS), открытое для
отображения того, какие записи были созданы корректно. Обратите внимание, что имена некоторых папок начинаются с символа подчеркивания ( _ msdcs, s i tes, tcp и _ udp ) . Каждая из этих папок содержит записи SRV.

Если вы столкнулись с проблемами подКJiючаемости и заметили, что записи SRV
отсутствуют в DNS, это просто исправить. Перейдите в окно командной строки и
выполните следующие две команды:
Net stop netlogon
Net start netlogon
Служба netlogon воссоздаст записи и все станет работоспособным.

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

После первоначального создания леса или после проведения модернизации от сре­ды Windows Server 2008 может понадобиться поднять функциональные уровни домена
и леса. Основной причиной является получение преимуществ от дополнительных возможностей, доступных на более высоких уровнях. Хотя функциональные уровни леса Window Server 201 2 не предлагают каких-то новых возможностей, вы можете все равно стремиться к поднятию функционального уровня домена до Windows Server 2012. Так или иначе, потребуется выполнить следующие общие шаги.
l. Удостовериться, что на всех контроллерах домена функционирует Windows
Server 2012.
2. Поднять функциональный уровень домена до Windows Server 2012.
3. Поднять функциональный уровень леса до Windows Server 201 2.
Важно помнить, что после поднятия уровня откатиться обратно не получится.
Если текущий функциональный уровень домена Windows Server 2008 R2, и вы под­нимете его до Windows Server 201 2, вы больше не будете иметь возможность под­нятия чего-либо меньшего, чем сервер Windows Server 201 2 до контроллера домена.
В случае если это вписывается в ваши планы, поднимайте уровни.
ФУНКЦИОНАЛЬНЫЙ УРОВЕНЬ (НЕ) МОЖЕТ БЫТЬ ПОНИЖЕН
Хорошо, это не совсем так. П ри наличии функционального уровня леса Windows
Server 2012 функциональные уровни леса и домена можно было бы понизить до
Wmdows Server 2008 R2. Это нельзя сделать в графическом пользовательском интер­ фейсе, но для решения такой задачи можно запустить две команды PowerShell.
Вот как понизить функциональный уровень леса до Windows Server 2008 R2:
Set-ADForestMode — Identity «bigfirm . com»
-ForestMode Windows2 008R2 Forest
А так понизить функциональный уровень домена до Wiпdows Server 2008 R2:
Set-ADDomainMode — Identity «Ьigfirm . com»
-DomainMode Windows2008R2Domain
Помните, что понижение функционального уровня леса также нарушит работу зави­симых средств, например, Dyпamic Access C o nt ю l (Динамический контроль доступа).
Ниже перечислены четыре инструмента, которые можно использовать для под­нятия функциональных уровней домена и леса:
• Active Directory Users and Computers (Пользователи и компьютеры Active
Directory) — для поднятия функционального уровня домена;
ACТIVE DIRECTORY В WINDOWS 5ERVER 201 2 341
• Active Directoiy Domains and Trusts (Домены и доверительные отношения Active
Directoiy) — для поднятия функционального уровня леса;
• Active Directory Administrative Center (Центр администрирования Active
Directoiy) — для поднятия функциональных уровней домена и леса;
• PowerShell 3.0 — для поднятия функциональных уровней домена и леса.
Выберите подходящий метод в зависимости от версии. Поскольку инструмент
Active Directoiy Administrative Center является новым, мы рассмотрим эту консоль и
покажем, как с ее помощью поднимать функциональные уровни домена и леса.
Чтобы поднять функциональный уровень домена, выполните следующие шаги.
1 . Запустите Active Directoiy Administrative Center, нажав комбинацию клавиш
для открытия диалогового окна Run (Выполнить), введите
dsac . ехе в текстовом поле и щелкните на кнопке ОК.
2. Откроется консоль Active Directoiy Administrative Center.
3. Щелкните правой кнопкой мыши на имени домена и выберите в контекстном
меню пункт Raise the domain functional level (Поднять функциональный уро­
вень домена), как показано на рис. 7.27.
4. Просмотрите информацию в окне Raise Domain Functional Level (Поднятие
функционального уровня домена).
Обратите внимание, что это окно информирует о текущем функциональном
уровне и предоставляет возможность поднять его. Выберите в раскрывающем­
с·я списке вариант Windows Server 2012.
5. Щелкните на кнопке ОК.
Вы получите еще одно предупреждение о том, что это действие необратимо.
6. Щелкните на кнопке ОК.
Спустя некоторое время отобразится диалоговое окно с сообщением о том, что
уровень был успешно поднят.
7. Щелкните на кнопке ОК.
С

Рис. 7.27. Поднятие функциональных уровней в Active Directory Administrative Center
Поднятие функционального уровня леса осуществляется аналогично.
1. Запустите Active Directory Administrative Ceпter, нажав комбинацию клавиш
для открытия диалогового окна Run (Выполнить), введите
dsac. ехе в текстовом поле и щелкните на кнопке ОК.
2. Откроется консоль Active Directory Administrative Center.
3. Щелкните правой кнопкой мыши на имени домена и выберите в контекс­
тном меню пункт Raise the forest functional level (Поднять функциональный
уровень леса).
4. Просмотрите информацию в окне Raise Forest Functional Level (Поднятие
функционального уровня леса).
Обратите внимание, что это окно информирует о текущем функциональном
уровне и предоставляет возможность поднять его. Выберите в раскрывающем­
ся списке вариант Windows Server 2012.
5. Щелкните на кнопке ОК.
Вы получите еще одно предупреждение о необратимости этого действия.
6. Щелкните на кнопке ОК.
Спустя некоторое время отобразится диалоговое окно с сообщением о том, что
уровень был успешно поднят.
7. Щелкните на кнопке ОК.
Многие дополнительные возможности более высоких функциональных уров­
ней станут доступными автоматически и лишь некоторые (такие как корзина Active
Directory (Active Directory Recycle Bin)) для своего включения требуют выполнения
добавочных шагов.
Поднятие ФvнкционАЛьных vРовней доменА и лесА с помощью PoweRSHELL
Поднятие функциональных уровней домена или леса не входит в число ежедневных
задач администратора. Возможно, вы будете делать это несколько раз за всю свою карьеру и, скорее всего, не станете применять сценарий для поднятия уровней.
Следовательно, это не особенно удачный случай использования PowerShell. Но для того чтобы показать, что это возможно с помощью нового PowerShell 3.0, ниже при­ведено соответствующее описание.
Чтобы поднять функциональный уровен ь домена, откройте командное окно
PowerShell и введите:
Set-ADDomainMode — Identity «Ьigfirm . com»
-DomainМode Windows2012Domain
Вам понадобится подтвердить действие путем ввода У. После этого домен
Ьigfirm . сот будет поднят до функционального уровня домена Windows Setver 2012.
Чтобы поднять функциональный уровень леса, откройте командное окно PowerSheH
и введите:
Set-ADForestMode -Identity «Ьigfirm . com»
-ForestMode Windows2012Forest
Это действие также необходимо подтвердить путем ввода У. Затем лес Ьigfirm. сот
будет поднят до функционального уровня леса Windows Server 2012.

Использование утилиты Netdom

Одним из полезных инструментов командной строки является Netdom (диспет­
чер доменов). Он доступен на любом сервере, повышенном до контроллера домена.
Хотя Netdom главным образом используется для управления доверительными отно­шениями в средах с более чем одним доменом, существуют также и другие примнения.
Переименование компьютеров (включая контроллеры доменов)
Команда netdorn cornputernarne позволяет безопасно переименовывать кон­троллеры доменов и серверы-члены. В ранних версиях Windows переименование
контроллера домена было невозможно без его предварительного понижения до сер­
вера-члена. Примите во внимание, что даже при использовании Netdorn для пере­
именования контроллера домена может требоваться пара перезагрузок, прежде чем
все будет приведено в порядок — особенно это касается DNS. Что более важно, вы не должны переименовывать серверы, которые являются серверами сертификатов
(т.е. на них функционируют службы сертификатов Active Directory (Active Directory
Certificate Services)). Сервер сертификатов должен сохранять свое имя. Имя, встроенное в сертификат, идентифицирует сервер, которому он выдан, и сервер, который
выпустил сертификат. Сертификаты проверяются путем запроса исходного сервера,
но если имя изменилось, то сертификаты не смогут быть подтверждены.
Переименование контроллера домена предусматривает назначение ему альтерна­
тивного имени и изменение альтернативного имени на основное имя контроллера
домена. Например, если в домене bigfirrn . com есть контроллер домена по имени DCO l, и его нужно переименовать на осо з , то сначала потребуется назначить ему
альтернативное имя DСО З с помощью следуюшей команды:
Netdorn computername DCOl /add : DCO З . bigfirm . com
В этот момент сервер имеет два имени: основное и альтернативное. Теперь изме­ните имя компьютера на альтернативное посредством такой команды:
Netdom computername DCOl /makeprimary : DCOЗ . bigfirm . com
Инструмент Netdom сообшит об успешном завершении процесса и запросит пе­резагрузку сервера. После перезагрузки контроллер домена изменит альтернативное имя на имя, которое ранее было основным.
Последний шаг заключается в удалении старого имени DCOl из объекта компью­терамя контроллера домена:
Netdom computername DСОЗ /remove : DCO l . bigfirm . com
Теперь контроллер домена имеет новое имя.
Присоединение компьютера к домену
Если вы хотите присоединить компьютер к домену из командной строки или че­
рез сценарий, можете воспользоваться Netdorn. Ниже показан простейший вариант команды:
Netdom j oin serverOl /d : bigfirm . con /reboot
Эта команда присоединит компьютер по имени serverOl к домену Ьigfirrn. сот и выполнит перезагрузку. Обычно учетная запись компьютера, присоединенного к
домену, помешается в контейнер Computers (Компьютеры). Как упоминалось ра­нее, с помощью команды redircmp учетные записи компьютеров можно создавать
где-то в другом месте.
Решить данную задачу возможно также и с применением Netdom, но это труд­
нее, чем с использованием инструментов командной строки для службы катало­гов (наподобие DSMove). Например, чтобы переместить учетную запись компьюте­ра из контейнера Computers в организаuионную единиuу Sales, после команды
NetDom j oin введите следующую команду DSMove:
Dsmove «CN=ServerO l , CN=Computers , DC=Ьigfirm, DC=com»
-newparent «OU=Sales , DC=Ьigfirm, DC=com»
Присоединение компьютера к домену с помощью PowerShell
Утилита Netdom — очень хороший инструмент Дll Я управления доменом, и опре­деленные задачи могут быть выполнены только посредством Netdorn. С точки зре­ния присоединения компьютеров к домену PowerShell может помочь, когда к доме­ну необходимо добавить несколько компьютеров или даже дистанuионно добавить к
нему компьютеры рабочей группы. Ниже показана базовая команда Д11Я добавления
сервера Windows Server 2012 по имени ServerOl к домену Ьigfirrn. com:
Add-Computer -ComputerName ServerOl
-LocalCredenti a l ServerOl Administrator
-DomainName «oigfirm. com»
-OUPath «OU=Sales , DC=Ьigfirm, DC=com»
-Credential bigfirmadministrator -Restart -Force
Эту команду можно запустить на контроллере домена Windows Server 2012 и дистанционно присоединить сервер ServerOl к домену. Во время выполнения этой ко­манды два раза запрашиваются пароли; первый раз понадобится ввести пароль ло­кального администратора (параметр -LocalCredential), а второй раз необходимо
ввести пароль для учетной записи, которая имеет разрешение на создание учетной
записи компьютера в домене (параметр -Credential).
Другие команды Netdom
Инструмент Netdorn поддерживает множество других команд, которые можно
применять для управления доменом. Полный справочник по Netdom доступен по
ccылкe http : / /technet . rnicrosoft . com/en-us/library/cc772217 . aspx.
Ниже перечислено несколько других команд, которые могут быть интересными.
+ NetDorn Reset. Сбрасывает учетную запись компьютера. Иногда система не
может войти в домен из-за утери учетной записи в домене. Зачастую обычного
сброса учетной записи оказывается достаточно для решения проблемы.
• NetDorn Reset Pwd. Сбрасывает пароль для входа компьютера в домен. Если
компьютер долго не подключался к домену, возможно, истек срок действия
пароля дЛЯ учетной записи. Эта команда может решить данную проблему.
• NetDom Remove. Удаляет компьютер из домена.
+ NetDom quc:ry fsrno. Временами требуется быстро найти роли Operations Master
внутри домена. Вместо того чтобы щелкать в разных окнах графического пользовательского интерфейса, с помощью этой команды можно легко отобразить
все роли Operations Master.

Управление временем в домене

Протокол аутентификации КегЬегоs, ис­пользуемый Active Oiгectory, требует, чтобы
все компьютеры в домене были синхронизи­рованы друг с другом. Если какой-то компью­
тер теряет связь с контроллером домена на период более пяти минут, будет возможность подключиться к сети, но все службы могут работать неправильно до тех пор, пока не бу­дет скорректировано время. По этой причине синхронизация времени очень важна в доме­не. Синхронизация времени достигается пос­редством иерархии. Она начинается с серве­ра, содержащего роль РОС Opeгations Masteг (Хозяин операций основного контроллера до­мена), которым обычно является первый контроллер домена, созданный в домене, и распространяется на все системы внутри домена.
Чтобы выяснить, на каком сервере находится эта роль, выполните следующие шаги.
1. Запустите оснастку Active Oiгectory Users and Computers.
2, Щелкните правой кнопкой мыши на имени домена и выберите в контекстном
меню пункт Operations Masters (Хозяева операций).
3. В открывшемся диалоговом окне Operations Masters (Хозяева операций) перей­дите на вкладку PDC (Основной контроллер домена), как показано на рис. 7.28.
В идеальном случае контроллер домена, на котором расположена роль РОС,
сконфигурирован для синхронизации с действительным источником NTP (Netwoгk
Тime Ргоtосо — протокол сетевого времени). Остальные компьютеры в домене бу­дут получать показания времени от этого сервера.
• Все контроллеры домена будут синхронизировать свое время со временем на РОС.
• Все компьютеры и серверы-члены будут синхронизировать свое время со вре­менем на контроллере домена, где они прошли аутентификацию.
• Если компьютер специально сконфигурирован так, чтобы не получать показа­ния времени от контроллера домена, на котором он прошел аутентификацию,
он должен быть синхронизирован с сервером NTP в точности как контроллер
домена с ролью РОС Operations Masteг.
При условии, что основной контроллер домена имеет корректное время, а пользова­тели не изменяют показания времени в своих системах, все будет работать нормально.
ОГРАНИЧЕНИЕ ИЗМЕНЕНИЙ ПОКАЗАНИЯ ВРЕМЕНИ С ПОМОЩЬЮ ГРУППОВОЙ ПОЛИТИКИ
Нередко администраторы настраивают групповую политику (Group Policy), чтобы
пользователи не могли изменять показания времени и непредумышленно изымать
свои системы из домена. Настройка System Time Group Policy (Групповая политика
системного времени) находится в Computer/PoliciesjWindows Settings/Security Settings/
Local PoliciesjUser Right Assignment (Компьютер/Политики/Настройки Windows/
Настройки безопасности/Локальные политики/Назначение прав пользователям).

Для проверки и синхронизации времени будет применяться служба времени
Windows (Windows Time Service; w32 tm). Служба w32tm запускается из командной
строки.
Представленная ниже команда позволяет сравнить пять выборок текущего вре­мени с данными из сервера времени Microsoft (time . windows . com) и проконтро­лировать, насколько точными они являются. В выводе будет отражено, опережают
ли показания времени на вашем сервере (обозначено с помощью +) или же отстают
(обозначено с помощью — ) :
w32tm /stripchart /computer : time . windows . com /samples : S /dataonly
Синхронизировать время на контроллере домена с ролью PDC Operations Master
можно с использованием внутреннего источника времени, если он есть, и внешнего
источника времени в противном случае. При синхронизации с внешним сервером NTP
посредством службы w32tm удостоверьтесь, что UDР-порт 123 открыт в брандмауэре.
С помощью показанной далее команды время в системе можно синхронизиро­вать с внешним сервером времени. Доступно несколько серверов времени, но в дан­ном примере применяется сервер времени Microsoft (t ime . windows . com) и сервер
времени NIST ( t im e . :-ii s t . g o v ) :
W32 tm /config «/manualpeerlist : time . nist . gov, time . windows . com»
/syncfromflags : manual /reliaЫe : yes /update
Параметр syncfromflags указывает, что сервер будет синхронизироваться с
одним из серверов в группе manua lpeerl i st . Можно задать только один сервер
времени (и тогда опустить кавычки) или доставить множество таких серверов, раз­
деленных запятыми, как сделано в примере команды.
Кроме того, имеет смысл перезапустить службу времени с использованием сле­
дующих команд:
Net stop w32t ime
Net start w32time
После перезапуска службы можно ввести показанную ранее команду w32 tm,
чтобы проверить точность показания времени. Если вы измените время, то может
пройти пять минут, прежде чем служба w32tm снова проведет синхронизацию и установит правильное показание времени.
В этом разделе рассматриваются различные задачи и приемы обслуживания, ко­торые вы наверняка сочтете полезными для поддержания своей сети в работоспо­собном состоянии. Это определенно неполный список, но в нем отражены основы.
Новейшим средством, которое поможет сократить объем необходимых действий по
обслуживанию, являются детализированные политики паролей. Это средство позво­ляет устанавливать множество политик блокировки паролей для учетных записей,
не создавая новый домен.

Роли FSMO и их передача

Служба Active Directory содержит в себе роли FSMO (FlexiЬe Single Master
Operations — гибкие операции с одним хозяином), которые применяются для вы­
полнения различных задач внутри леса и домена. Существуют две роли на уровне
леса и три роли на уровне домена. В табл. 7. 1 описаны названия, области действия
и назначение этих ролей.
Аст1vе D1RECTORY в W1Noows SERVER 201 2
Таблица 7.1. Роли FSMO
Роль FSМО
Schema Master (Хозяин схемы)
Domain Namiпg Master
(Хозяин именования доменов)
Область
действия
Лес
Лес
Назначение
Содержит в себе схему леса
Управляет именами доменов
347
lпfrastructure Master Домен Обеспечивает междоменные ссылки на объекты
(Хозяин инфраструктуры)
PDC Emulator
(Эмулятор основного контроллера
домена)
RID Master (Хозяин относительных
идентификаторов (RID))
Домен
Домен
Отвечает за время в лесе
Обрабатывает измене ния паролей
Является точкой подключения для управления
объектами GPO
Блокирует учетные записи
Управляет и пополняет пулы RID (relative
ideпtifier — относительный идентификатор)
В определенных ситуациях, например, при выводе из эксплуатации контроллера
домена, модернизации домена или в случ.ае возникновения проблем с производи­
тельностью, понадобится передать эти роли новому контроллеру домена. Каждая из
указанных ролей должна быть все время доступной в Active Directory. Один из способов переноса или передач.и этих ролей новому контроллеру домена предусматри­вает использование утилиты NTDSUtil.
Чтобы передать роли FSMO домена, выполните описанные далее шаги.
1 . Откройте окно командной строки ( cmd . ехе). введите NTDSUti l и нажмите
.
2. Введите roles и нажмите .
3. Введите connections и нажмите .
4. Теперь необходимо подключ.иться к серверу, который в будущем будет содер­
жать эти роли FSMO. Введите connect to server [Имя_ сервера] и нажмите
.
5. Введите qui t и нажмите .
6. Первой будет передаваться роль РОС Emulator. Введите transfer pdc и на­
жмите . Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
7. При необходимости можно ввести transfer rid master и нажать для
перемещения роли RID Master. Вы должны подтвердить запрос, щелкнув на
кнопке Yes (Да).
8. При необходимости можно ввести transfer infrastructure master и на­
жать для перемещения роли l nfrastructure Master. Вы должны подтвер­
дить запрос. щелкнув на кнопке Yes (Да).
9. Теперь, когда передача всех ролей FSMO домена завершена, введите qui t и
нажмите . затем снова введите qui t и нажмите . чтобы закрыть
окно командной строки.
Разумеется, приведенные шаги должны быть выполнены в каждом домене.

Если вы решите передать роли FSMO уровня леса, выполните следующие шаги.
. Откройте окно командной строки (cmd . ехе), введите NTDSUti l и нажмите
.
2. Введите roles и нажмите .
3. Введите connections и нажмите .
4. Теперь необходимо подключиться к серверу, который в будущем будет со­
держать эти роли FSMO. Введите connect to server [Имя:_ сервера ] и на­
жмите .
5. Введите qui t и нажмите .
6. Первой будет передаваться роль Schema Masteг. Введите transfer schema
master и нажмите . Вы должны подтвердить запрос, щелкнув на кноп­
ке Yes (Да).
7. При необходимости можно ввести transfer naming master и нажать
для перемещения роли Domain Naming Master. Вы должны подтвердить за­
прос, щелкнув на кнопке Yes (Да).
8. Теперь, когда передача всех ролей FSMO леса завершена, введите qui t и
нажмите , затем снова введите quit и нажмите , чтобы закрыть
окно командной строки.
После переноса всех ролей FSMO на ноflый контроллер (или контроллеры)
домена может понадобиться проверить, все ли работает так, как ожидается. Мы
предполагаем, что вы запустите в окне командной строки команду netdom query
fsmo role, которая отобразит сведения о том, какой контроллер домена содержит в
себе те или иные роли FSMO.

Детализированные политики паролей

Прежде чем реализовывать детализированные политики паролей, необходимо
удостовериться в том, что ваша среда удометворяет минимальным требованиям.
• В домене развернут контроллер домена Windows Server 201 2.
• Функuиональный уровень домена должен быть установлен в Windows
Server 2008.
Создавать объекты настройки паролей (password-settings object — PSO) могут
только члены группы Domain Admins (Администраторы домена).

Создание объекта настройки паролей

В Windows Server 201 2 для создания объектов настройки паролей доступен ве­ликолепный графический пользовательский интерфейс. По сравнению с Windows
Server 2008 R2 внутренне ничего не изменилось; возможности остались теми же.
Однако огромное преимушество заключается в том, что управлять объектами PSO
теперь можно через графический пользовательский интерфейс, особенно когда дело доходит до набора значений времени для записей продолжительности, что ранее требовало больших усилий.

Чтобы создать объект PSO для группы G_ITAdmins, выполните перечисленные
ниже шаги.
1 . Запустите Active Directory Administrative Center, нажав комбинацию клавиш
для открытия диалогового окна Run (Выполнить), введите
dsac . ехе в текстовом поле и щелкните на кнопке ОК. Можете также запус­
тить Active Directory Administrative Center.
2. Переключитесь на древовидное представление и выполните прокрутку вниз,
пока не увидите элемент System/Password Settings Container (Система/
Контейнер настроек паролей).
3. Щелкните правой кнопкой мыши на элементе Password Settings Container
и выберите в контекстном меню пункт Newc::>Password Settings (Создатьq
Настройки паролей), как показано на рис. 7.29.
Рис. 7 .29. Контейнер настроек паролей в ADAC
4. В поле Name (Имя) открывшегося диалогового окна Create Password Settings
(Создание настроек паролей) введите PSO_G_ITAdmins, а в поле Precedence
(Приоритет) укажите значение 10.
5. Удостоверьтесь, что флажок Enforce minimum password length (Установить минимальную длину пароля) отмечен, и укажите длину 15 символов.
6. Удостоверьтесь, что флажок Enforce minimum password age (Установить минимальный срок действия пароля) отмечен, и укажите продолжительность зо
дней.
7. Удостоверьтесь, что флажок Enforce account lockout policy (Применить по­
литику блокирования учетных записей) отмечен, и укажите в поле Number of
failed logon attempts allowed (Количество попыток неудачного входа в систему)
значение 5.
8. В области Directly Applies То (Напрямую применять к) щелкните на кнопке
Add (Добавить). Выберите группу G _ ITAdmins и щелкните на кнопке ОК.

9. Для остальных настроек оставьте то, что выбрано по умолчанию. Диалоговое
окно должно иметь вид, подобный показанному на рис. 7.30.
1 О. Щелкните на кнопке ОК, чтобы закрыть это диалоговое окно.
Вы должны увидеть, что в контейнере настроек паролей внутри Active Directory
Admiпistrative Center появился объект PSO под названием PSO G ITAdmins.
Теперь вам нужно какое-то доказательство того, что этот объект PSO работает,
и просмотреть имеющиеся настройки. В предшествующих примерах мы создавали
пользователя по имени s а 1 1 у Smi th. Давайте предположим, что этот пользователь является IТ-администратором и, следовательно, данного пользователя необходимо добавить в группу G _ ITAdmins. Пользователь Sally Smith должен получить новые настройки паролей; в этом легко убедиться, войдя в систему на сервере с помощью учетной записи sally . smi th. Еще один способ выяснить, какие правила объекта PSO применяются к пользователю, предполагает выполнение следующих шагов.
1 . Запустите Active Directory Administrative Center.
2. Перейдите в организационную единицу Sales, в которой был создан пользо­
ватель Sally Smith.
3. Щелкните правой кнопкой мыши на имени Sally Smith и выберите в кон­
текстном меню пункт View resultant password settings (Просмотреть результи­
рующие настройки паролей), как показано на рис. 7.3 1 .
4. Откроется диалоговое окно для группы PSO _ G _ ITAdmins и вы увидите объект PSO, применяемый к пользователю Sally Smith.
5. Щелкните на кнопке ОК, чтобы закрыть это диалоговое окно.
Важно знать о том, что объекты PSO можно связывать с другими группами в до­
полнение к глобальным группам доступа. Однако когда для пользователя определен результирующий набор политики (Resultant Set of Policy — RSOP), принимаются во внимание только те объекты PSO, которые напрямую связаны с объектом пользовате­ля или с глобальной группой доступа, членом которой является пользователь. Объекты
PSO, связанные с группами рассылки или другими группами доступа, игнорируются.

Приоритет объекта настроек паролей

В предыдущем примере было сконфигурировано несколько настроек паролей,
которые установлены аналогично настройкам стандартной политики домена (Default
Domain Policy) в домене. Есть еще одна настройка, на которую следует взглянуть.
В диалоговом окне Create Password Settings (см. рис. 7.30) можно было указать зна­чение в поле Precedence (Приоритет). Приоритет определяет, какому объекту PSO будет отдано предпочтение, если к объекту пользователя применятся сразу несколь­ко объектов PSO.
Давайте применим к группе G_ITAdmins два объекта PSO, один с приоритетом
10, а другой с приоритетом 5. Объект PSO с приоритетом 5 получит преимущество,
поскольку предпочтение отдается более низким значениям приоритета по сравнению с более высокими.
Это имеет смысл, если вы просто используете группы и применяете объект PSO
на уровне группы. Но что произойдет, когда вы примените объект PSO к группе
G_ITAdmins, в которой состоит пользователь Sally Smith, и еще один объект PSO напрямую к пользователю Sally Smi th?
Давайте снова возьмем группу G _ ITAdmins, членом которой является пользо­
ватель Sally Smi th, и применим к ней объект PSO с приоритетом 10. Создайте
еще один объект PSO с приоритетом 1 5 и примените его напрямую к пользователю Sally Smith. Объект PSO, примененный к пользователю Sally Smith напрямую, получит предпочтение, хотя значение его приоритета больше.
Способ применения объекта PSO определяется следующим образом.
Обьект PSO, который связан напрямую к обьекту пользователя, является резуль­
тирующим обьектом PSO. Если с обьектом пользователя никакие обьекты PSO
не связаны, сравнивается членство пользователя в глобШiьных группах доступа,
а также все обьекты PSO, применимые к пользователю на основе его членства в
этих глобальных группах. Результирующим обьектом PSO будет такой обьект,
который имеет наименьшее значение приоритета.

папка SVSVOL: старое и новое

Действительно замечательной характеристикой Active Directory, которая сохра­
няется еще с 2000 года и по-прежнему актуальна, является то, что Active Directory представляет собой распределенную базу данных. Могут существовать более од­ного контроллера домена, на которых хранятся записываемые копии базы данных каталога, что устраняет необходимость в наличии первичного (поддерживающего запись) и вторичного (не поддерживающего запись) серверов. Внутри каждого конт­роллера домена Active Diгectory имеется пара папок, которые содержат общие ресур­сы, используемые для предоставления функций доступа и репликации различным контроллерам домена. Папка, хранящая эти общие ресурсы, называется SYSVOL.
В ней хранятся общая папка NETLOGON (со сценариями входа и объектам GPO
для клиентских компьютеров в домене), сценарии входа пользователей, групповая политика Windows, промежуточные папки и файлы службы репликации файлов (File Replication Service — FRS), папки и файлы для синхронизации и соединения файловой системы.
В этом разделе рассматриваются следующие темы:
введение в службу репликации файлов;
+ переход на репликацию распределенной файловой системы (Distributed File
System Replication);
+ обнаружение текущего состояния перехода с применением команды dfsrmig.

Старое: служба репликации файлов

Часто, когда мы считаем что-то в мире технологий старым, с ним ассоциируется
негативный подтекст. В данном конкретном случае «старая» означает ссылку на спо­соб, которым выполнялась определенная работа в прошлом. Изменения, внесенные в SYSVOL версией Windows Server 2008 R2 и также Windows Server 201 2, охватывают
новую методологию проведения репликации материалов SYSVOL между партнерами
репликации через весь домен.
ИЗМЕНИЛАСЬ ли СЛУЖБА FRS в WINDOWS SERVER 201 2?
Нет. Служба FRS работает таким же образом, как в Wiпdows Server 2008 R2, но ее преемник называется DFS-R.
Репликация распределенной файловой системы ( Distributed File System
Replication — DFS-R) обладает значительными преимуществами по сравнению со
службой FRS, однако это вовсе не означает, что старый метод является неудач­
ным. В действительности во всех версиях Active Directory за исключением Windows
Server 2008 R2 и Windows Server 2012 применяется «старый» метод. Службу FRS по­лезно исследовать и понять ее работу, поскольку она преобладает в сетях, в которые планируется добавлять серверы Windows Server 2012.
Понимание функциональности FRS упростит переход от FRS на DFS-R. Но когда
нужен такой переход? Он необходим при модернизации домена Windows Server 2003 до Windows Server 201 2 либо при модернизации домена Windows Server 2008 (R2), в котором не была реализована DFS-R, но который планируется обновить до Windows Server 2012. Для поддержания uелостности папки SYSVOL репликаuия FRS использует то, что называется соединениями файловой системы (file system junction).
Вы должны освоить работу FRS и некоторые операuии, ассоuиированные с репли­
каuией FRS. Каждый контроллер домена, на котором функuионирует FRS, содер­
жит следующие общие ресурсы и компоненты SYSVOL:
• общая папка N ETLOGON;
• сuенарии входа пользователей;
• групповая политика Windows;
• промежуточные папки и файлы FRS;
• соединения файловой системы.
Соединения файловой системы широко применяются во всей структуре SYSVOL.
Они являются функuией файловой системы NTFS 3.0, которая была введена в
Windows 2000 Server. Точки соединения предназначены для устранения утери или
разрушения данных, которое может произойти при изменении структуры SYSVOL.
Точки соединения в SYSVOL предназначены мя управления хранилищем единс­
твенных копий (single-instance store — SS), которое представляет собой место, где одиночные копии содержимого используются множеством потребителей, например, компьютерами. Точки соединения также называют точками повторной обработки(reparse point). Точка соединения — это физическое местоположение на жестком диске, которое указывает на порuию данных, находящуюся где-то в другом месте на этом диске или на каком-то другом физическом устройстве хранения. В хранили­ще единственных копий физические файлы существуют только в одном экземпляре внутри файловой системы, а в SYSVOL файл находится в SYSVOLstagingdornain или в SYSVOL enterprise и SYSVOL stagingenterprise. Эти дополнительные структуры папок являются точками повторной обработки, которые переадресуют файловый ввод или вывод в исходные местоположения.
Такая конфигураuия точек соединения / точек повторной обработки поддержива­
ет согласованность данных за счет гарантии существования данных в единственном экземпляре. Кроме того, конфигурация разрешает иметь более одной точки доступа к отдельной порции данных. Идея состоит в том, чтобы обеспечить избыточностьданных без их дублирования. Точки соединения привязывают пространство имен целевой файловой системы к локальному тому NTFS. Лежащие в основе точки пон­торной обработки позволяют файловой системе NTFS прозрачно переадресовать операuию на целевой объект. В итоге, если вы модифиuируете данные в структу­ре SYSVOL, изменения будут происходить непосредственно в физических файлах.
Например, при выполнении операции вырезания и вставки в структуре SYSVOL,
которая содержит точки соединения, эта операция произойдет в точке соединения.

что собой представляет служба FRS

Служба FRS бьша введена в Windows 2000 Server для репликации папок в рас­
пределенной файловой системе (Distributed File System — DFS) и папки SYSVOL.
Она реплицирует файлы и папки, хранящиеся в SYSVOL на контроллерах домена
и общие папки DFS. Когда служба FRS обнаруживает, что в файл или папку внут­
ри реплицируемого обшего ресурса внесено изменение, она автоматически репли­
цирует обновленную папку на другие серверы. FRS является службой репликаuии
с несколькими хозяевами, т.е. любой сервер, участвующий в репликации, может
инициировать обновления и последующие репликации, а также может разрешать
конфликты между файлами и папками, обеспечивая согласованность данных между
серверами-партнерами репликации.
Служба FRS сохраняет данные синхронизиро­ванными между множеством серверов и позволяет сетям увеличивать доступностьданных для своих клиентов. Если один сервер становится недостижимым, файлы и папки по-прежнему доступны, поскольку они существуют на другом сервере.
Служба FRS полезна при репликации в географически рассредоточенных средах ре­гиональных сетей, т.к. данные могут быть синхронизированы с каждым физическим местоположением, что устраняет необходимость использовать клиентами подключе­ния к WAN для доступа к информации из SYSVOL или DFS. Служба FRS, пожалуй, наиболее известна по своей роли в репликации данных SYSVOL между контролле­рами внутри домена.
Каждый контроллер домена имеет структуру папки SYSYOL, содержащую файлы и папки, которые должны быть доступными и синхронизиро­ванными между контроллерами в домене. Общая папка N ETLOGON, системные политики и настройки групповой политики являются частью структуры SYSVOL и нуждаются в репликации на все контроллеры домена в домене.

Преимущества репликации с помощью FRS

Когда вы совершаете добавления, изменения или удаления в SYSVOL, служба
FRS вступает в действие и реплицирует эти изменения на другие контроллеры доме­на в домене. Ниже перечислены преимущества службы FRS.
• Шифрованный протокол RPC. Служба FRS применяет аутентификацию
Kerberos к удаленным вызовам процедур (гemote ргосеduге call — RPC) для
шифрования данных, которые передаются между участниками репликации.
• Сжатие. Служба FRS сжимает файлы в промежуточной папке, используя сжа­
тие NTFS. Файлы пересылаются по сети между участниками репликации в
сжатой форме, экономя пропускную способность сети.
• Разрешение конфликтов. Служба FRS разрешает конфликты между файлами и
папками, чтобы обеспечивать согласованность данных у участников реплика­
ции. Если создаются или модифицируются два файла с идентичными имена­
ми, то FRS применяет простое правило для разрешения конфликта. которое
выглядит как «выигрывает последний записывающий». Служба определяет са­мое последнее обновление и считает этот файл авторитетным, после чего реплиuирует данную версию файла другим участника репликации. Если на разных
серверах создаются две одинаково именованных лапки, FRS идентифицирует
этот конфликт, но будет использовать другую методику для его разрешения.
В таком случае служба FRS переименует папку, которая была создана послед­
ней, и реплицирует обе папки членам репликации. Затем администратор мо­
жет вручную разрешить конфликт без потенциальной потери данных.
• Непрерьmная репликация. Служба FRS обеспечивает непрерывную репликацию
между членами групп репликации. Изменения реплицируются FRS в пределах
трех секунд после того, как были сделаны.
• Отказоустойчивый путь репликации. Служба FRS не применяет широковеща­
тельные рассыпки при репликации. Она может предоставить множество путей

для поддержки связности между серверами. Если член репликаuии недосту­пен, FRS отправит данные по другому пути. Служба FRS предотвращает от­
правку идентичных файлов любому члену репликации более одного раза.
• Планирование репликации. Интересной особенностью службы FRS является
возможность планирования репликации на определенные моменты времени и
интервалы. Это становится по-настоящему удобным, когда необходимо репли­
цировать данные по каналам WAN. Можно запланировать выполнение репли­
кации на часы, когда линия WAN минимально загружена.
• Целостность репликации. Служба FRS поддерживает целостность репликации
с использованием порядковых номеров обновлений, чтобы регистрировать изменения в журнале на сервере-члене репликации. Служба FRS способна управлять репликаuией, даже если один из членов без уведомления прекраща­ет работу. Когда этот член восстановит работоспособность, FRS реплицирует
изменения, которые произошли в его отсутствие, а также обновления, сде­ланные в локальных файлах на сервере-члене до того, как он перестал функционировать. В средах, предшествующих Windows Server 2008, служба FRS
применяется главным образом в двух целях — репликация DFS и репликаuия
SYSVOL. Службу FRS можно использовать для поддержания данных в иерар­
хиях DFS синхронизированными между членами топологии репликации. FRS
и DFS являются независимыми топологиями, и для DFS не требуется наличие
FRS. Чтобы обеспечить актуальность данных на серверах-членах DFS, можно
применять и друтие методы репликаuии.
Источник
Большая часть сведений, предлагаемых в этом и следующем разделах, взята из веб­сайта Microsoft TechNet:
http : //technet . microsoft . com/en-us/library/cc78 1582 (v=WS . 10 ) . aspx Обращайтесь на указанный веб-сайт за дополнительной информацией.

Требования и зависимости FRS

Репликация SYSVOL поддерживается FRS. Служба FRS реплицирует SYSVOL с
использованием топологии, сгенерированной средством проверки целостности зна­ний (Knowledge Consistency Checker — КСС), и также имеет собственные объекты Active Directory, которые реплиuируются посредством репликации Active Directory.
Средство КСС отвечает за построение топологии репликации Active Directory. Оно применяет очень сложный алгоритм для нахождения наиболее эффективного спосо­ба построения объектов подключений между контроллерами домена.
КАК НАСЧЕТ AD?
Важно запомнить, что хотя служба FRS используется для репликации SYSVOL, она
не применяется в качестве механизма для репликапии Active Directory. Есть две части, которые необходимо реплицировать. Одна часть — это содержиr.юе Active Directory, такое как пользователи, к о м п ью т ер ы и группы, а друтая часть — содержи­мое папки SYSVOL наподобие групповых политик. Служба FRS используется только
для репликации части SYSVOL, но не части Active Directory.

Для работы службы FRS должны быть удовлетворены некоторые требования и
зависимости.
• Репликация Active Directory. Служба FRS требует правильного функционирования репликации Active Directory, чтобы объекты FRS в Active Directory находи­лись на всех контроллерах домена в домене.
• DFS. Если вы собираетесь применять FRS для поддержания данных синхронизированном состоянии в папках на отдельных физических серверах, то
должны сначала построить пространство имен DFS. (Для репликации SYSVOL
в этом нет необходимости.)
• DNS. Служба FRS требует работающей инфраструктуры DNS. Служба FRS ис­
пользует DNS для преобразования имен членов репликации.
• Аутентификация Kerberos. Служба FRS требует функционирующей среды
KerЬeros.
• NTFS. Служба FRS применяет журнал USN (update sequence number — порядко­
вый номер обновления) на томах NTFS, чтобы идентифицировать изменения
или обновления файлов.
• Удаленные вызовы процедур (RPC). Служба FRS требует традиционных под­
ключений IP и RPC для взаимодействия с членами репликации и контролле­
рами домена в домене.

каково будущее FRS?

В ближайшем будущем служба FRS исчезнет. ОС Windows Server 201 2 все еще
поддерживает репликацию SYSVOL с помощью FRS, но это старая технология и бу­
дущее за файловой системой DFS-R, которая обладает множеством преимуществ по
сравнению с FRS. Если вы устанавливаете совершенно новую среду Active Directory на сервере Windows Server 2012, то получите DFS-R сразу после повышения сервера.
FRS в WINDOWS SERVER 201 2 R2
Служба репликации файлов (File Replicatio11 Service) в Windows Server 2012 R2 объяв­лена устаревшей, но она по-прежнему доступна. По этой причине самое время при­ступить к планированию использования DFS-R.

новое: репликация распределенной файловой системы

Как было показано ранее в этой главе, служба FRS применялась с момента появления Active Directory в Windows 2000 Server для репликации SYSVOL на контроллеры домена во всем домене Active Directory. В Windows Server 2008 R2 была введена новая опция для репликации SYSVOL в домене, которая называлась Distributed File SystemReplication (Репликация распределенной файловой системы), или DFS-R.
Эта опция присутствует также и в Windows Server 2012. Она представляет собой основанный на состоянии механизм репликации с несколькими хозяевами, который поддерживает планирование репликации и регулировку полосы пропускания. Репликация DFS-R использует алгоритм сжатия RDC (Remote Differential Compression — удаленное разностное сжатие).
Алгоритм RDC — это протокол «передачи разниuы по проводам»,
применяемый для обновления клиентов и серверов через сеть. Он обнаруживает
вставки, удаления и модификаuии в файлах данных и реплиuирует партнерам по
репликаuии только изменения, а не целые файлы. Алгоритм RDC может предоста­
вить значительные изменения репликации SYSVOL между контроллерами домена в домене.

что собой представляет DFS-R

Многие из вас знакомы с распределенной файловой системой (Distributed File
System — DFS). Файловая система DFS используется для формирования единого
прозрачного пространства имен, в котором пользователи могут получать доступ к
общим ресурсам, расположенным в разнообразных местах во всей сети. Такое про­странство имен DFS может находиться во множестве местоположений. Как говорит само название, это по-настоящему распределенная файловая система. DFS не явля­ется нововведением Windows Server 2012; она существовала на протяжении многих лет. На самом деле, пространство имен DFS — это один из двух сценариев (наряду с репликацией SYSVOL), в которых вы обнаружите службу FRS.
Когда была выпущена версия Windows Server 2008 R2, разработчики из Microsoft
обновили способ, которым служба DFS реплицировала файлы и папки. Вместе с
DFS было включено новое средство под названием DFS-R. Репликация DFS-R за­
меняет FRS в DFS, а также в репликации SYSVOL внутри доменов Active Directory, в
которых функциональный уровень домена не ниже Windows Server 2008.
Аrlгоритм RDC. упомянутый в предыдущем разделе, очень эффективен, посколь­
ку благодаря тому, что он обнаруживает изменения в файлах и папках, то вместо
репликации целого файла или папки (как делала служба FRS) реплиuируются толь­ко изменения, произведенные в файле или папке. Во время репликации алгоритм RDC может сэкономить громадный объем полосы пропускания сети. Для реплика­uии файлов и папок DFS-R применяет группы репликаuии.
Группа репликации — это просто набор серверов, в котором каждый сервер назы­вается члено.м группы. Каждый член участвует в репликации одной или более репли­uированных папок.
Реплицированная папка — это такая папка, которая остается синхронизированной на каждом сервере-члене группы репликации.
Топология, планирование и регулировка полосы пропускания для группы реп­
ликаuии применимы к каждой реплицированной папке. Каждая реплиuированная
папка имеет уникальные настройки, такие как фильтры файлов и папок, позволя­
ющие фильтровать файлы и подпапки внутри нее. Управлять DFS-R можно с ис­
пользованием инструмента управления DFS либо из командной строки с помощью
DFSRADMIN, DFSRDIAG, DFSUTIL, DFSCMD и DFSDIAG.
Недостаток DFS-R в том, что на контроллерах домена должна быть установле­
на ОС версии не ниже Windows Server 2008, Windows Server 2008 R2 или Windows
Server 2012. Если у вас все еще функuионирует Window Server 2003 или давно забы­тая ОС Windows 2000 Server, вам придется придерживаться FRS до тех пор, пока вы не решите перейти на контро1U1еры домена более новой версии и воспользоваться DFS-R.

Что нового в DFS-R ВЕРСИИ W1нoows SERVER 2012
Репликация DFS-R в Wiпdows Server 20 1 2 не содержит особо много новых функ­ций. Усовершенствования в основном ограничиваются исправлением ошибок и
улучшениями в области устранения неполадок; механизм стал более отказоустой­
чивым. Детальную информацию о том, что появилось нового, читайте в TechNet:
для Wmdows Server 2012 — http : / / technet .microsoft . com/en-us/ library /dn281957 . aspx и для Windows Se1ver 2012 R2 — http : / /technet . microsoft . сот/
en-us/l ibrary/dn28 1 957 . aspx.

Миграция на DFS-R

Требование для использования DFS-R состоит в том, что функциональный уро­
вень домена должен быть не ниже Windows Server 2008. Это означает всего лишь по­вышение всех контроллеров домена до Windows Server 2008 или выше. Вам может показаться, что достаточно просто модернизировать контроллеры домена Windows Server 2003 до Windows Server 2008 или выше, и все было бы в порядке. Однако это не сработает. Процесс миграции из FRS на DFS-R в действительности предусмат­ривает проход по нескольким состояниям, во время которых репликация SYSVOL переходит с репликации FRS на репликацию DFS-R. Точные определения шагов и состояний приводятся в следующем разделе.
Мы настоятельно призываем вас провести миграцию репликации FRS на DFS-R.
Служба FRS поддерживается в Windows Server 201 2, но ходят слухи, что FRS может больше не поддерживаться в будущих версиях Windows Server. По этой причине пла­нируйте заранее и предпринимайте эти шаги.

шаги миграции

Описанные далее шаги миграции для Windows Server 201 2 остались такими же,
как они были в Windows Server 2008 R2. Процесс миграции включает в себя прави­ла миграции настроек на контроллере домена, являющемся эмулятором основного контроллера домена (РОС Emulator), и ожидание, пока остальные контроллеры до­мена последуют этим правилам. Состояния миграции могут быть определены как локальные на контроллере домена или глобальные в отношении контроллеров в домене. Глобальное состояние миграции устанавливается с помощью утилиты ко­мандной строки dfsrmig, которая применяется для установки одной из фаз про­цесса миграции. Эта настройка делается в Active Oirectory и затем реплицируется на все контроллеры домена. Каждый контроллер домена имеет собственное состоя­ние миграции. Репликация OFS-R на каждом ОС опрашивает Active Directory, что­бы выяснить глобальное состояние миграции, в которое ОС должен перейти. Если глобальное состояние миграции отличается от локального состояния миграции, то DFS-R попытается перевести локальное состояние так, чтобы оно соответствова­ло глобальному состоянию. Локальное состояние миграции может быть любым из набора устойчивых или переходных состояний. Миграция SYSVOL проходит че­рез четыре основных состояния (обычно называемых устойчивыми состояниями)и шесть временных состояний (обычно называемых переходными состояниями).
Переходные состояния ведут ОС в устойчивые состояния.

При миграции SYSVOL из FRS в OFS-R существуют четыре устойчивых состоя­ния, или фазы. Эти состояния называются Start (Начало), Prepared (Подготовлена),
Redirected (Переадресована) и Eliminated (Устранена). На них также ссылаются пос­редством порядковых чисел.
• Start (состояние О). Прежде чем начнется миграция SYSVOL, служба FRS реп­
лицирует общую папку SYSVOL.
• Prepared (состояние 1). Служба FRS по-прежнему реплицирует общую папку
SYSVOL, которая используется доменом, в то время как OFS-R реплицирует
копию общей папки SYSVOL. Эта копия SYSVOL не применяется для обслу­
живания запросов от других ОС.
• Redirected (состояние 2). Копия OFS-R общей папки SYSVOL становится от­
ветственной за обслуживание запросов от других ОС. Служба FRS продолжает
реплицировать исходную папку SYSVOL, но OFS-R теперь реплицирует про­
изводственную папку SYSVOL, которую используют контроллеры домена, на­
ходящиеся в состоянии Redirected.
• Eliminated (состояние 3). DFS-R продолжает поддерживать всю репликацию
SYSVOL. Исходная папка SYSVOL удаляется, и служба FRS больше не репли­
цирует данные SYSVOL.
Источник
Большая часть сведений, предлагаемых в этом разделе, взята из веб-сайта MicrosoftTechNet:
http : / /technet.mi crosoft . com/en-us/library/dd64 1052 . aspx
Обращайтесь на указанный веб-сайт за дополнительной информацией.
Во время миграции с помощью команды dfsrmig осуществляется проход по че­
тырем устойчивым состояниям. Во время этого процесса можно наблюдать некото­
рые видимые изменения.
1 . Процесс миграции создает копию папки SYSVOL. Служба FRS реплицирует
исходную папку SYSVOL, расположенную в с : windows SYSVOL. Механизм
DFS-R реплицирует копию папки SYSVOL, находящуюся в с : windows
SYSVOL dfsr.
2. Отображение общей папки SYSVOL изменяется с FRS на OFS-R. Изначально
отображение общей папки SYSVOL, с : windowsSYSVOL, использовалось для
информации, которая активно реплицируется службой FRS. Позже в про­
цессе миграции местоположение общей папки SYSVOL будет отображено на
с : windowsSYSVOL_dfsr, и данные, активно потребляемые Active Oirectory,
будут реплицироваться OFS-R.
3. Процесс миграции удалит исходную копию папки SYSVOL.

Переходные состояния

По мере перемещения из одного устойчивого состояния в другое, каждый конт­
роллер домена будет также проходить через последовательность переходных состояний. Существуют пять переходных состояний, пронумерованных от 4 до 9. Каждое состояние имеет название, поясняющее то, что происходит во время перехода:
• Подготовка (состояние 4)
• Ожидание начальной синхронизации (состояние 5)
• Переадресация (состояние 6)
• Устранение (состояние 7)
• Откат переадресации (состояние
• Откат подготовки (состояние 9)
На рис. 7.32 иллюстрируется процесс миграции через четыре устойчивых состоя­
ния и переходные состояния, возникающие между устойчивыми состояниями.
Star1 (Начало)
Рис. 7.32. Состояния миграции на DFS-REliminated
(У с транена)
Возможно, вас интересует, как в точности DFS-R переходит между состояниями. Вспомните, что служба DFS-R на каждом DC запрашивает у Active Directory
текущее глобальное состояние миграции. Если глобальное состояние отличается от локального состояния на контроллере домена, то DFS-R предпринимает шаги (пе­реходные состояния) для достижения соответствия глобальному состоянию.
Когда вы готовы к миграции контроллеров домена в своем домене на DFS-R,
все они начнут с состояния Start. Вы откроете окно командной строки и воспользу­етесь инструментом dfs rmig для перемещения контроллеров домена и состояния Start в состояние Eliminated. Интересная особенность процесса миграции связана с тем, что по нему можно двигаться не только вперед, но также и при необходимости назад, если пока еще не завершен шаг 3, т.е. устранение. Например, после перевода
DC в состояние Prepared по какой-то причине вы решили возвратиться обратно в
состояние Start. Можно с помощью инструмента dfsrmig изменить состояние на
Start. Важно помнить, что как только достигнуто состояние 3, возврат назад уже не­возможен. В этой точке миграция будет завершена, а исходная папка SYSVOL уда­лена.

миграция в состояние Prepared

Прежде чем действительно начинать процесс миграции, должны быть удовлет­
ворены некоторые требования. Вспомните, что для использования DFS-R домен
необходимо поднять до функционального уровня Windows Server 2008. Это значит,что на всех контроллерах домена должна быть установлена ОС Windows Server 2008,Windows Server 2008 R2 или Windows Server 2012. Если у вас имеются контроллеры домена с Windows 2000 Server или Windows Server 2003, то вы не полностью готовы к переходу на DFS-R. Повторимся еше раз: в Windows Server 201 2 служба FRS по­ прежнему поддерживается, но не исключено, что она исчезнет из будущих версий Windows Server.

Верификация Active Directorv

Перед поднятием функционального уровня домена до Windows Server 2008 вы
должны проверить работоспособность Active Directory и удостовериться в коррект­ной репликации существующей папки SYSVOL. Если репликация Active Directory не работает должным образом, то прежде чем пытаться выполнить миграцию, необхо­димо решить данную проблему. Отказ одного из контроллеров домена повлияет на остальную часть домена. У вас есть возможность исправить существующие пробле­мы с AD. Ниже описаны соответствующие действия.
1. В М icrosoft рекомендуют применять команду net share для проверки того,
что папка SYSVOL совместно используется всеми контроллерами домена, и
что эта открытая папка отображается на папку SYSVOL, реплицируемую служ­
бой FRS. В выводе команды net share будут присутствовать общие имена для
папок NETLOGON и SYSVOL наряду с текущими их местоположениями.
2. Вы должны удостовериться в наличии достаточного объема свободного про­
странства на диске, чтобы можно было создать копию структуры папки
SYSVOL.
3. Используйте инструмент Utrasound для мониторинга службы FRS и про­
верки ее функциональности. Этот инструмент доступен для бесплатной за­
грузки по ссылке http : / /www .microscft . com/en-us/download/details .
aspx?id=3660.
4. На одном из контроллеров домена откройте окно командной строки и вве­
дите repadmin /replsum. Эта команда позволит удостовериться в корректной
работе репликации Active Directory. В выводе не должны присутствовать сооб­
щения об ошибках. Если же они есть, устраните проблемы, прежде чем про­
должить.
5. Откройте окно командной строки и введите DCDIAG. Эта утилита выпол­
нит несколько проверок в системе. Вывод не должен содержать сообщения
об ошибках. Если это не так, устраните проблемы, прежде чем продолжить.
Чтобы запустить DCDIAG на удаленном сервере, введите DCDIAG /s : DC02 .
bigfirm. com. В результате утилита DCDIAG запустится на контроллере домена
DC02 .Ьigfirm. сот.
6. В редакторе реестра на каждом контроллере домена перейдите в раздел
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogon
Parameters и удостоверьтесь в том, что значением параметра SYSVOL яв­
ляется диск : 1 windows folderSYSVOL SYSVOL, а значением параметра
SYSVOLReady — число 1.
7. На каждом контроллере домена с помощью окна служб удостоверьтесь, что
служба DFS Repication запущена, а тип ее запуска установлен в Automatic
(Автоматически).

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

Теперь, когда проверено функционирование Active Directory, FRS и SYSVOL, а
также корректность значений упомянутых выше параметров реестра, все готово к
поднятию функционального уровня домена до Windows Server 2008. Для этого вы­
полните следующие шаги.
1 . Откройте Active Directory Administrative Center.
2. Щелкните правой кнопкой мыши на имени домена и выберите в контекстном
меню пункт Raise Domain Functional Level (Поднять функциональный уровень
домена).
3. В окне Domain Functional Level (Функциональный уровень домена) выберите
вариант Windows Server 2008.
4. Щелкните на кнопке ОК.
5. В открывшемся окне предупреждения щелкните на кнопке ОК.
6. В открывшемся окне подтверждения щелкните на кнопке ОК.
При каждом переходе из одного состояния в другое вы будете выполнять после­
довательность действий по верификации. После завершения этих действий происхо­дит переход в следующее состояние. В данном случае вы удостоверились в коррект­ном функционировании Active Directory и SYSVOL. Затем вы проверили параметры реестра и подняли функциональный уровень домена. Перед миграцией в состояние Prepared осталась еще одна деталь — создать резервную копию. Самое время убе­диться в наличии правильной текущей резервной копии данных состояния системы.
Если что-то пойдет совершенно неподходящим образом, у вас будет возможность
возвратиться в эту точку. Итак, уделите несколько минут на создание и последую­щую проверку резервной копии состояния системы. После этого вы будете готовы кмиграции в состояние Prepared.

выполнение миграции

Процесс миграции из состояния Start в состояние Prepared является коротким.
Понадобится открыть окно командной строки и ввести следующую команду (рис. 7.33):
dfsrrnig /setglobalstate 1
Рис. 7.33. DFS-R устанавливает глобальное состояние миграции в 1
В этот момент вы должны проверить, что глобальное состояние миграции было
обновлено. Для этого снова откройте окно командной строки и введите следующую
команду:
dfsrmig /getglobalstate
Эта команда возвратит текущее глобальное состояние с сообщением, указываю­
щим на успешный переход (рис. 7.34).
Рис. 7 .34. DFS-R получает глобальное состояние
Есть еще одна, последняя команда, позволяющая проверить, что все контролле­
ры домена перешли в состояние Prepared:
dfsrmig /getmigrationstate
Учтите, что эта команда может требовать некоторого времени на выяснение
того, что все контроллеры домена благополучно мигрировали в состояние Prepared,
после чего выдаст соответствующее сообщение (рис. 7.35). Будьте терпеливы, т.к.
Active Directory нужно время, чтобы провести репликацию. Теперь, когда вы дове­ли процесс до состояния Prepared, имеет смысл проверить корректность перехода в это состояние, прежде чем переходить к следующей фазе процесса миграции. Ниже приведены очень простые шаги, которые позволят удостовериться в успешности пе­рехода в состояние Prepared.
Рис. 7.35. Вывод команды dfsrmig /getmigrationstate

7. На каждом контроллере домена откройте окно командной строки и введите
команду net share, чтобы проверить, используется ли папка SYSVOL совмес­
тно всеми контроллерами домена, и отображается ли эта открытая папка на
папку SYSVOL, которая реплицируется службой FRS.
8. Воспользуйтесь инструментом Ultrasound для проверки того, что служба
FRS остается работоспособной на исходной папке.
9. Проверьте файловую систему, создана ли папка SYSVOL_DFSR в каталоге
с : windowsSYSVOL_dfsr, и что в нее скопировано содержимое исходной
папки SYSVOL (рис. 7.36).
10. Сгенерируйте с помощью инструментов управления DFS диагностический отчет.
Если инструменты управления DFS у вас еще не установлены, можете доба­
вить его как компонент в диспетчере серверов, ДJIЯ чего выберите в меню пункт Manage9Add Roles and Features (Управлениеq Добавить роли и компонен­
ты) и затем в открывщемся мастере отметьте флажок возле компонента DFS
Management Tools (Инструменты управления DFS), последовательно развернув
узлы Remote Server Administration Tools (Инструменты дистанционного адми­
нистрирования серверов) и File Services Tools (Инструменты файловых служб).
Когда применяется оснастка DFS Manager (Диспетчер DFS), возможно сгенери­
ровать два типа диагностических отчетов, которые называются Health report (Отчет о работоспособности) и Propagation report (Отчет о распространении). Для провер­ки на предмет наличия проблем вы должны сформировать оба эти отчета (рис. 7.37).
Чтобы сгенерировать указанные отчеты, выполните следующие шаги.
1 . Откройте диспетчер DFS.
2. В дереве консоли внутри узла Replication (Репликация) щелкните на элементе
Domain System Volume (Системный том домена).
3. Щелкните на вкладке Membership (Членство).
4. Щелкните на Membership Status (Состояние членства).
5. Удостоверьтесь, что для локального пути с : windowsSYSVOL_dfsrвaш домен
отмечен флажок EnaЫed (Включен).
6. Щелкните правой кнопкой мыши на элементе Domain System Volume.
7. Щелкните на Create Diagnostic Report (Создать диагностический отчет).
8. Когда откроется мастер создания диагностического отчета (Diagnostic Report
Wizard), выберите тип генерируемого отчета и следуйте дальнейшим шагам
мастера.
После проверки, успешно ли контроллеры домена перешли в состояние Prepared,
вы готовы переходить в состояние Redirected. В этом состоянии DFS-R возьмет насебя ответственность за репликацию папки SYSVOL для домена. Данная порция
процесса миграции состоит из двух частей. Сначала вы выполните переход в состо­яние Redirected, а затем проверите успешность этого перехода.

Рис. 7.37. Соэдание отчета с помощью диспетчера DFS

миграция в состояние Redirected

Чтобы перевести домен в состояние Redirected, понадобится выполнить перечис­
ленные ниже шаги.
1 . В окне командной строки введите команду dfsrmig /setglobalstate 2.
Вывод команды показан на рис. 7 .38.
2. В окне командной строки введите команду dfsrmig /getglobalstate.
Вывод команды показан на рис. 7.39.
3. Введите команду dfsrrnig /getrnigrationstate, чтобы удостовериться в том,
что все контроллеры домена достигли состояния Redirected (рис. 7.40).

1
Рис. 7.38. Вывод команды dfsrmig /setglobalstate 2
Рис. 7.39. Вывод команды dfsrmig /getglobalstate
Рис. 7.40. Вывод команды dfs rmig /getmigrationstate

К этому моменту вы успешно завершили шаги, необходимые для миграции до­
мена в состояние Redirected; тем не менее, перед переходом в состояние Elimiпated
необходимо удостовериться, что домен был успешно перемещен в состояние
Redirected. Для этого выполните следующие шаги.
1 . Откройте окно командной строки и введите команду net share.
В выводе этой команды вы увидите новую общую папку SYSVOL_DFSR в пол­
номочном состоянии (рис. 7.41 ).
Рис. 7.41 . Новое местоположение папки SYSVOL
2. Воспользуйтесь диспетчером DFS для создания еше одного диагностического
отчета, как это делалось при верификации перехода в состояние Prepared.
3. С помощью инструмента Ultrasouпd проверьте работоспособность репликации
FRS исходной папки SYSVOL.
Вы хорошо помните, что DFS-R отвечает за репликацию новой общей папки
SYSYOL в домене; тем не менее, важно проверить функционирование процесса
репликации FRS, если потребуется возвратиться обратно в состояние Prepared.
Когда контроллеры домена ус h ешно прошли миграцию в состояние Redirected,
можно сделать финальное перемещение в состояние Eliminated.

миграция в состояние Eliminated

Итак, вами пройден долгий путь. Наступило время сделать последний шаг миг­
рации из FRS на DFS-R. К этому моменту все контроллеры домена должны фун­
кционировать в состоянии Redirected. Механизм DFS-R успешно реплицирует об­
щие папки SYSVOL, а служба FRS сохранена со старыми общими папками SYSVOL.
Теперь можно вывести из эксплуатации, или в данном случае устранить, службу
FRS. Прежде чем действительно переходить в состояние Eliminated, необходимо
предпринять несколько действий. Не забывайте, что после этого шага возврата на­зад уже не будет. Таким образом, еще раз проверьте состояние Redirected, чтобы вы­яснить, корректно ли работают все компоненты.
1 . Введите команду dfsrmig /getmigrationstate и удостоверьтесь, что все
контроллеры домена находятся в состоянии Redirected.
2. Введите команду repadmin /replsum, чтобы проверить правильность работы
репликации Active Directory. Удостоверьтесь в отсутствии ошибок.
3. Сохраните состояние Active Directory на случай, если потребуется восстановле­ние из резервной копии.
Если домен функционирует в состоянии Redirected, как ожидалось, самое время
провести миграцию в состояние Eliminated. Выполните описанные ниже действия
на контроллере домена.
1 . Введите команду dfsrmig /setglobalstate 3 (рис. 7.42).
Рис. 7.42. Вывод команды dfsrrnig /setglobal state 3
2. Введите команду dfsrmig /getglobalstate, чтобы удостовериться в том, что
глобальным состоянием является Eliminated (рис. 7.43) .
Рис. 7.43. Вывод команды dfsrrnig /getglobalstate
3. Введите команду dfsrmig /getmigrationstate для проверки того, что все
контроллеры домена успешно про11U1и миграцию (рис. 7.44).
4. На каждом контроллере домена откройте окно командной строки и введите net
share, чтобы проверить местоположение открытой папки SYSVOL (рис. 7.45).
5. Сгенерируйте в диспетчере DFS те же самые отчеты Health report и Propagation report, которые вы создавали при проверке состояний Prepared и Redirected.

6. На каждом контроллере домена откройте окно проводника Windows и удосто­
верьтесь в удалении открытой папки с : windowsSYSVOL.
Вполне нормально, если некоторые папки остаются постоянными; тем не ме­
нее, вы должны проверить, что они пусты. В итоге должна остаться только но­
вая инфраструктура SYSVOL_DFSR, как показано на рис. 7.46.
Рис. 7.44. Вывод команды dfsrmig /getmigrationstate
Рис. 7.45. Финальный вывод команды net share
Рис. 7.47. После миграции служба FRS отключена
Благодаря выполненным действиям, вы успешно провели миграцию инфраструк­
туры репликации SYSVOL из FRS на DFS-R и получили все преимущества удален­
ного разностного сжатия. Действительно старая репликация папки SYSYOL посредс­твом службы FRS теперь заменена новой репликацией DFS папки SYSYOL_DFSR.

Модернизация Active Directorv

Стала доступной версия Active Directory Server 2012, и вы озабочены тем, чтобы
обновить текущую инфраструктуру до последнего выпуска, поскольку хотите удер­живать ее в актуальном состоянии.
Раньше мы предполагали, что никакой изначальной сети не существует, поэто­
му строили новую сеть с нуля. В большинстве ситуаций это не так. Служба Active Directory появилась более десяти лет тому назад, и многие компании располагают той или иной версией Active Directory. В этом разделе мы собираемся сосредоточить внимание на модернизации домена до Windows Server Active Directory 2012. Но пре­жде чем начать это приключение, необходимо понять путь следования и возможные
предварительные условия.
Готовы ли ВАШИ СЕРВЕРЫ?
СЕРВЕРЫ WINDOWS NT НА ВЕЧЕРИНКУ НЕ ПРИГЛАШАЮТСЯ!
Нет никакой возможности обеспечить сосуществование контроллера домена Windows NT 4.0 и контроллера домена Windows Seiver 2012. После выхода Windows Seiver 2008 R2 доверительные отношения для домена NT 4.0 больше не поддерживаются, и ус­танавливать сервер Windows NT 4.0 Server внутри домена Windows Server 2012 нельзя.
Кроме того, поддержка Wiпdows NT 4.0 Server со стороны Microsoft давно закончи­лась. Следовательно, Wiпdows NT 4.0 Seiver является, пожалуй, самой незащищен­ной системой во всем мире.

модернизация схемы до Windows Server 2012

nри планировании модернизаuии домена в ранних версиях Windows Serveг не­
обходимо было запускать инструмент под названием adprep . е х е . Этот инстру­мент подготавливает и расширяет схему леса для поддержки новых функuий, атакже подготавливает домен к созданию новых групп и контейнеров. С помошью дополнительной опции /gpprep домен можно подготовить к установке объектоn групповой политики для репликации контроллера домена Windows Serveг, а опции/ rodcprep — для добавления поддержки учетных записей контроллера доменатолько для чтения (Read-only Domain Controlleг — RODC).
Хорошая новость состоит в том, что в Windows Sегvег 201 2 инструмент
adprep . ехе по-прежнему существует в папке support adprep установочной
копии Windows Serveг 201 2. Однако 32-разрядной версии adprep . ехе больше нет, есть только 64-разрядная версия, которую можно запускать под управлением 64- разрядной ОС Windows Serveг 2008 и выше. Запускать инструмент adprep . ехе не обязательно на контроллере домена; его можно запустить дистанционно на серве­ре Windows, который является сервером-членом домена или даже сервером рабочей
группы. Чтобы просмотреть все доступные опции, запустите adprep . ехе /?.
Если нужно расширить схему из сервера с 64-разрядной ОС Windows Serveг 2008,
введите следующую команду:
adprep /forestprep /forest w2k3domain . com /user admini st rator
/userdomai n w2k3domain . com /password P@sswOrd
После успешного расширения схемы введите показанную ниже команду, чтобы
расширить домен:
adprep /domai nprep /gpprep /domain w2k3domai n . com /user administrator
/userdomain w2k3domain . com /password P@sswOrd
Для расширения поддержки RODC понадобится выполнить следуюшую команду:
adprep /rodcprep /domain w2 k3domain . com /user adminis t rator
/userdomain w2k3domain . com /password P@sswOrd
Еще лучшая новость заключается в том, что вы не обязаны запускать adprep .
ехе вообще. В Windows Serveг 2012 имеется новый мастер конфигурирования служ­бы домена Active Diгectory (ADDSCW), который применялся ранее в этой главе для повышения первого контроллера домена. Этот мастер становится доступным после установки роли Active Directory Domain Services. Мастер позаботится обо всех ша­гах, необходимых для успешного повышения сервера-члена Windows Serveг 2012 до контроллера домена. Инструмент adprep . ехе был интегрирован в данный мастер, чтобы обеспечить максимально комфортную процедуру повышения.
Если вы собираетесь повысить сервер и предоставили всю нужную информацию,
после щелчка на кнопке lnstall (Установить) мастер проверит среду и подготовит лес, схему и домен (рис. 7.48).
На рис. 7.49 показано окно мастера ADDSCW, модернизирующее лес через
adprep /forestprep. Затем мастер модернизирует домен, используя adprep . ехе/domainprep (рис. 7.50).
Но почему в Microsoft решили предоставлять инструмент adprep . ехе и также
реализовали его в мастере ADDSCW? nричина в том, что есть компании, в которых необходимо документировать каждый шаг, выполняемый над их инфраструктурой,в системе управления службами или системе управления изменениями, т.к. это тре­буется принятым у них процессом управления изменениями. В этом случае запуск
adprep . ехе из командной строки дает возможность отслеживать, что в точности изменяется.
Если процесс управления изменениями отсутствует, можете использовать комфортный способ расширения леса или домена, выполняя всю работу в мастере

В Wmdows Server 2012 Active Directory доступны новые группы, которые создаются в течение процесса модернизации.
Следующие группы находятся в контейнере BUILTIN внутри ADAC или ADUC:
• Access CoпtroJ Assista11ce Operators (Операторы поддержки управления доступом)
• Hyper-Y Admiпistrators (Администраторы Hyper-V)
• RDS Eлdpoint Servers (Серверы конечных точек RDS)
• RDS Maпagement Servers (Серверы управления RDS)
• RDS Remote Access Servers (Серверы удаленного доступа RDS)
• Remote Management Users (Пользователи дистанционного управления)
Следующая группа находится_ в контейнере Users внутри ADAC или ADUC:
• CloneaЫe Domain Controllers (Клонируемые контроллеры домена)

модернизация домена до Windows Server 2012

Перед тем, как начать обсуждение миграции, мы хотим дать небольшой совет, не
последовать которому было бы крайне неразумно. Если вы производите миграцию,
значит, у вас, вероятно, уже есть домен, функционирующий в текущий момент. Вы намерены преобразовать этот домен в работоспособный домен Windows Server 201 2, интегрированный с AD. Самая сложная часть заключается в успешном прохождении из состояния «до» в состояние «после». Если вы запутаетесь на этом пути, то поль­зователи вряд ли будут в восторге, потому что работающий домен, хоть он и старой версии, все же лучше, чем полное отсутствие какого-либо домена, а путаница может привести к разрушению существующего домена. Итак, вот совет: даже и не думайте начинать миграцию до тех пор, пока не опробуете сам процесс в лабораторной сети.
Наличие технологии виртуализации делает процесс тестирования быстрым и безбо­лезненным.

Существуют три философских подхода к миграции на домен Windows
Server 2012.
• Модернизация на месте. Предусматривает прохождение через процесс установ­
ки ОС Windows Server 2012 поверх имеющегося 64-разрядного контроллера до­
мена Windows.
• Постепенная миграция. Сервер-член Windows Server 2012 повышается до кон­
троллера домена в существующем домене. Такой подход также называют мо­
дернизацией Active Directory или миграцией домена.
• Чистая изначальная миграция. Создается «чистый как первый снег» домен
Windows Server 2012 Active Directory. Пользовательские учетные записи, группы и компьютеры переносятся в этот новый домен с помощью инструментов
вроде Active Directory Migration Tool (ADMT), последней версией которого является 3.2.
Все указанные подходы подробно рассматриваются в последующих разделах.

Миграция путем модернизации на месте

Модернизация на месте означает установку Windows Server 2012 на существую­
щем контроллере домена. Процесс модернизации более или менее сводится к мно­
гократным щелчкам на кнопках Next (Далее) и в конце на кнопке Finish (Готово).
Однако вы должны быть осведомлены о некоторых последствия. Все в домене оста­нется почти тем же самым. Это означает, что пользователи, компьютеры и группы не затрагиваются, и все счастливы оттого, что немногое изменилось. Но недостаток такого подхода в том, что вместе с хорошим в новый домен перешло и все то пло­хое, что присутствовало в старом домене, или же приложения, устаноаленные в сис­теме, оказываются несовместимыми с новой ОС.
Если что-то идет не так, вы можете попасть в действительно трудную ситуацию,
поскольку модернизация, по большому счету, выполняется по принципу «все или
ничего». Следовательно, удостоверьтесь в наличии проверенной резервной копии.
Несмотря на что в Microsoft уверяют, что ничего плохого не должно произойти, за­кш1ы Мерфи никто не отменял.
Важно знать, что все роли, устанонленные на контроллере домена, также бу­
дут модернизированы. Это значит, что если в системе есть, например, роли DNS и DHCP, они модернизируются до версий Windows Server 2012.
Если вы решили проводить модернизацию на месте своего контроллера домена,
то должны знать, какие версии Windows Server в действительности можно модерни­зировать.
КонтроJUJеры домена, на которых функционируют 64-разрядные версии Windows
Server 2008 или Windows Server 2008 R2, могут быть модернизированы до Windows
Server 2012 (как показано в табл. 7.2). Нет никакого способа модернизировать конт­роллеры домена с Windows Server 2003 или 32-разрядными версиями Windows Server
2008. Чтобы заменить их, вы должны установить в домене контроллеры домена с
Windows Server 2012 и затем удалить контроJUJеры домена с Windows Server 2003.
Прежде чем планировать модернизацию на месте, проверьте, удоwтетворены ли
требования к установке Windows Server 2012.

Таблица 7.2. Пути модернизации
Существующая ОС
Windows Server 2008 Standard с пакетом обновлений SP2 или
Windows Server 2008 Enterprise с пакетом обновлений SP2
Windows Server 2008 Datacenter с пакетом обновлений SP2
Windows Web Server 2008
Windows Server 2008 R2 Standard с пакетом обновлений SP1 или
Windows Server 2008 R2 Enterprise с пакетом обновлений SP1
Windows Server 2008 R2 Datacenter с пакетом обновлений SP1
Windows Web Server 2008
375
Поддерживаемая модернизация
Windows Server 2012 Standard или
Windows Server 201 2 Datacenter
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 Standard или
Windows Server 201 2 Datacenter
Windows Server 2012 Datacenter
Windows Server 2012 Standard
• Удостоверьтесь, что оборудование сервера поддерживает 64-разрядные операционные системы.
• Поскольку ОС Windows Server 2012 доступна только в виде 64-разрядных версий, использовать 32-разрядное оборудование нельзя.
+ Минимальные требования к оборудованию для Windows Server 2012: 64-раз­
рядный процессор с тактовой частотой 1 ,4 ГГц, ОЗУ объемом 512 Мбайт, свободное пространство на диске размером 32 Гбайт и монитор с экранным разрешением 800х600. Удовлетворить эти требования в наши дни довольно леrко.
+ Проводить модернизацию на месте имеет смысл только на сервере, предпола­
гаемый добавочный срок эксплуатации которого составляет три-четыре года.
Также удостоверьтесь, что в течение всего этого срока вы будете получать под­держку со стороны поставщика оборудования.
• Проверьте, что все программное обеспечение, установленное на сервере, под­
держивается в Windows Server 2012, особенно антивирусное ПО, драйверы обо­
рудования и прикладные приложения. Если вы попытаетесь устранить про­
блемы несовместимости во время процесса модернизации, может возникнуть
серьезное затруднение. Если вы не уверены, мы рекомендуем удалить антиви­
русное ПО перед модернизацией и установить его повторно после успешного
завершения модернизации.
• Создайте резервную копию контроллера домена и состояния системы.
Пvть модЕРниздции для WINDOWS SERVER 201 2 R2
Важно отметить, что Wmdows Seiver 201 2 R2 больше не разрешает модернизацию от Wiпdows Seiver 2008 с пакетом обновлений SP2. Чтобы модернизация была возможна, потребуется иметь, по крайней мере, Windows Server 2008 R2 с пакетом обномений SPl.
Если необходимо провести модернизацию от Windows Server 201 2 Datacenter, вы можете модернизировать до Windows Server 201 2 R2 Datacenter. При наличии уста­новленной версии Windows Server 201 2 Standard можно модернизировать до Windows
Seiver 201 2 R2 Standard или Windows Server R2 Datacenter.
Минимальные требования к оборудованию для установки Windows Server 2012 R2 та­кие же, как для Windows Server 2012.

В качестве установившейся практики мы рекомендуем создать резервную копию
всего раздела С: и состояния системы. Также настоятельно рекомендуем создавать
резервные копии с помощью двух разных инструментов резервного копирования.
В первую копию поместите раздел С: и состояние системы с применением инстру­мента резервного копирования, принятого в компании. В вторую копию поместите
раздел С: и состояние системы с использованием внутреннего инструмента резерв­ного копирования Windows. Причина создания двух копий связана с тем, что в слу­чае возникновения проблем в Microsoft принимают при предоставлении поддержки только резервные копии, созданные с помощью собственной утилиты.
На этой стадии вы убедились, что система готова для модернизации и имеют­
ся достоверные резервные копии. Следующие шаги направлены на выяснение того,
что на контроллере домена отсутствуют ошибки или проблемы с репликацией.
Дllя проверки, находится ли контроллер домена в работоспособном состоянии,
запустите утилиту repadmin, которая протестирует репликацию:
repadmin /replsum /bysrc /bydest /sort : delta
Эта команда выдаст перечень ошибок репликации в домене, отсортированный
по источнику, цели и наибольшей разницы репликации. Если в выводе сообщается
о каких-либо ошибках, постарайтесь исправить проблемы заблаговременно.
AD RЕРL1сдт1он Sтдтus TooL
В 2012 году Microsoft бьш выпущен инструмент для анализа состояния реплика­
ции Active Directory (AD Replication Status Tool), представляющий собой небольшое средство с графическим пользовательским интерфейсом, которое можно устанав­ливать в среде клиентской или серверной ОС Windows. Этот инструмент позволяет анализировать состояние репликации для контроллера домена в домене или лесе.
Он отображает любые ошибки и позволяет экспортировать результаты в файл CSV
или XPS для дальнейшего анализа. Он доступен для загрузки по ссылке http : / /
www .microsoft . com/en-us/download/details . aspx?id=ЗOOOS.
На контроллере домена запустите команду DCDIAG и удостоверьтесь в прохожде­
нии всех тестов. На контроллере домена Windows Server 2003 утилиту DCDIAG пона­добится устанавливать отдельно. Исходный файл suptools .ms i находится в папке
support tools установочной копии.
Если все тесты проходят, откройте программу просмотра событий Windows (Event
Viewer) на контроллере домена, просмотрите журналы событий на предмет наличия любых ошибок или предупреждений и попробуйте устранить проблемы. Ниже описано, как проводить модернизацию на месте AD версии Windows Server 2008.
1 . Подготовьте схему леса, чтобы она бьUiа совместимой с Windows Server 2012.
2. Подготовьте домен для Windows Server 2012.
3. Запустите программу установки, чтобы модернизировать контроллер домена.

Подготовка леса/ схемы и домена

Во время модернизации на месте не все контроллеры домена должны быть на
уровне Windows Server 2008. Тем не менее, в этой системе должны быть размещены некоторые роли FSMO. Хозяином именования доменов леса, которым по умолчанию является первый контроллер домена в лесе, должен быть сервер Windows Server 2008.
Также сервером Windows Server 2008 должен быть эмулятор РОС каждого домена
внутри леса. По умолчанию им является первый контроллер домена в каждом доме­не. Процесс модернизации рекомендуется начинать на контроллере домена, который не содержит ни одной роли FSMO. Если контроллер домена, подлежащий модер­низации, в настоящий момент содержит какую-то роль FSMO, ее можно передать и затем, после успешной модернизации, возвратить обратно на новый контроллер домена Windows Server 2012. Вдобавок на всех контроллерах домена должна функци­онировать ОС Windows Server 2003 или последующей версии. Кроме того, функцио­нальным уровнем домена должен быть Windows Server 2003 Native или лучше.
Перед тем как модернизировать даже один домен в лесе Windows Server 2003/2008
до Windows Server 201 2, вам потребуется изменить всю схему леса на Windov.•s
Server 201 2. Вы будете делать это на контроллере домена с ролью FSMO хозяина операций схемы леса. Вставьте диск Windows Server 201 2 Setup DVD в привод ком­пьютера, откройте окно командной строки и перейдите в палку support adprep
на этом диске. Таким образом, например, если DVD-привод имеет букву диска D,
вы должны открыть окно командной строки, ввести о : и нажать , после чего ввести cd support adprep и нажать еще раз. Утилита adprep . ехе до­ступна только в виде 64-разрядной версии, но не 32-разрядной.
1. Запустите adprep на сервере с ролью хозяина схемы, введя
adprep /forestprep
и нажав .
Отобразится предупреждение о проверке того, что на всех серверах функцио­
нирует Windows Server 2003 или выше.
2. Подтвердите, введя с и нажав .
3. Далее на сервере с ролью хозяина инфраструктуры в подготавливаемом домене
введите adprep /domainprep /gpprep и нажмите .
4. Наконец, запустите adprep /rodcprep на сервере с ролью хозяина инфра­
структуры.
На шаге 1 при расширении схемы леса вы могли заметить во время выполнения
команды, что в командной строке запускается много связанных друг с другом ко­манд. На этом шаге импортируются все необходимые изменения схемы. Если у вас ранее было установлено приложение Exchange, Lync или какое-то другое, требую­щее расширения схемы, шаг 1 не повлияет на эти изменения.
На шаге 4 производится подготовка домена для Windows Serveг 2012, а также из­менение разрешения для объектов G РО с целью репликации посредством Windows Server 201 2. На этом последнем шаге появляется возможность добавить контроллер домена только для чтения (Read-only Domain Controller). Сейчас имеет смысл за­пустить adprep /rodcprep, поскольку позже в производственной среде это может потребовать больших усилий. Итак, перед тем, как домен AD на основе Windows Serveг 2008 можно будет модернизировать до домена AD на базе Windows Server 2012,
вы должны выполнить перечисленные ниже действия.
1 . Примените пакет обновлений Service Pack 2 ко всем контроллерам домена
Wmdows Server 2008 и пакет обновлений Service Pack 1 ко всем контроллерам до­мена Windows Server 2008 R2, чтобы удовлетворить требования к модернизации.
2. Модернизируйте лес, выполнив команду adprep /forestprep на компьютере
с ролью FSMO хозяина схемы для леса, даже если он не находится в домене,
который вы собираетесь модернизировать.
3. Модернизируйте структуру домена, выполнив команду adprep / domainprep
/gpprep на компьютере с ролью FSMO хозяина инфраструктуры для домена,
который вы собираетесь модернизировать.
4. Дополнительно выполните команду run / rodcprep, чтобы подготовить
контроллеры домена только для чтения.

Запуск программы установки

Теперь вы готовы запустить программу установки. Вставьте установочный DVD­
диск, дважды щелкните на его значке в окне Му Computer (Мой компьютер), если
автозапуск не произошел, и выберите опцию Upgrade (Модернизация). Когда будет предложено получить последние обновления, выберите этот вариант. Мастер будет предупреждать, если что-то изменяется во время модернизации. Он также проверит, подготовлены ли должным образом лес и домен. До запуска собственно процесса установки откроется диалоговое окно, в котором отображаются обнаруженные про­блемы с совместимостью приложений и драйверов. Если вы принимаете результа­ты, программа установки продолжит свою работу безо всякого вмешательства, по завершении которой вы сможете войти в модернизированную систему контроллера
домена с Windows Server 2012.
МОДЕРНИЗАЦИЯ НА МЕСТЕ: ДОВОДЫ ЗА И ПРОТИВ
Подводя итоги, ниже перечислены доводы в пользу проведения модернизации на
месте.
• Она не требует новых компьютеров.
• У пользователей сохраняются старые идентификаторы защиты (security identi­ fier — SID), а у домена — старые доверительные отношения, так что любые сер­веры в других доменах (к примеру, в доменах ресурсов, содержащих файловые серверы, серверы печати или почтовые серверы) будут по-прежнему без проблем опознавать пользователей.
• У пользователей сохраняются их старые пароли.
• Это простая и быстрая модернизация.
• При переходе с Windows Server 2008 AD на Windows Server 2012 АО модерниза­ция проводится без особых проблем.
Тем не менее, во многих случаях мы не рекомендуем делать модернизацию на месте по указанным далее причинам.
• Путь модернизации очень ограничен. ОС Windows Server 2012 является 64-раз­рядной. Многие организации все еще имеют 32-разрядные контроллеры домена,
поэтому модернизация для них невозможна.
• Модернизация производится по принципу «все или ничего». Вы модернизируете
все учетные записи, причем в одном направлении — откат AD невозможен. (Тем
не менее, можно восстановить данные состояния системы из резервной копии.)
Мы предпочитаем более детализированные подходы.
• Любой существовавший ранее мусор остается в базе данных Active Directory.

постепенная миграция

Последовательные и плавные шаги в направлении домена Windows Server 2012
называются постепенной миграцией. Она также широко известна как миграция
Active Directory. По существу вы добавляете в домен сервер-член Windows Server 2012
и затем повышаете этот сервер до контроллера домена. После репликации данных
Active Directory вы получите первый контроллер домена Windows Server 2012. При
таком сценарии все остается без изменений, лишь добавляются дополнительные
серверы. Недостаток этой процедуры в том, что в случае установки физического
сервера необходимо дополнительное оборудование, а при виртуализации потребу­
ется иметь больше памяти и ресурсов UП. Это не означает, что количество конт­роллеров домена увеличится, т.к. вы можете понизить старые контроллеры домена.
Если вы не желаете тратить деньги и ресурсы, можете установить запасной сервер в качестве контроллера домена Windows Server 2012 и понизить старый контроллер домена, а затем после успешного понижения повторно развернуть сервер с Windows Server 2012.
Миграция такого вида является очень безопасным способом модернизации до­
мена; вы не находитесь в ситуации «все или ничего». Хотя вам понадобится расши­рить схему леса, этот шаг не будет критически сложным.
Повторное развертывание контроллера домена может быть отдельным проектом.
В зависимости от того, какой контроллер домена вы собираетесь заменить, вы долж­ны тщательно планировать каждый шаг. Могут существовать зависимые службы, та­кие как DNS, DHCP, роли FSMO, приложения, запрашивающие этот контроллер домена, или открытые файловые ресурсы, которые зависят от данного контроллера домена. Следовательно, потребуется уделить время на проведение внимательных ис­следований имеющейся среды.

Подготовка к повышению сервера-члена

Перед тем как повышать сервер-член Windows Server 2012 до контроллера доме­на, удостоверьтесь в том, что домен имеет функциональный уровень леса не ниже Windows Server 2003. Если вы попытаетесь повысить сервер Windows Server 2012 до
контроллера домена в домене с функциональным уровнем леса Windows 2000 Server, то получите ошибку.
ВЫПОЛНЕНИЕ ПОСТЕПЕННОЙ МИГРАЦИИ
Постепенная миграция предусматривает выполнение следующих базовых шагов.
l . Проверьте домен на предмет наличия ошибок.
2.Добавьте на сервер-член роль Active Directory Domain Services.
3. Запустите мастер ADDSCW с разрешениями Schema Admin (Администратор схе­мы), Enterprise Admin (Администратор предприятия) и Domain Admin (Адми­нистратор домена). Мастер ADDSCW автоматически запустит на сервере хозяина инфраструктуры команды adprep /forestprep и adprep /domainprep.
4. Выполните действия, проводимые после миграции, такие как размещение ролей
FSMO, изменение IР-адреса и другие изменения.
5. При необходимости повторно разверните исходный контроллер домена.

подготовка леса/ схемы и домена

Как и в случае модернизации на месте, существующий лес и целевой домен не­
обходимо подготовить к изменениям Windows Server 201 2 Active Directory. Для этого потребуется запустить утилиты ForestPrep, DomainPrep и GPprep, как было опи­сано в разделе «Миграция путем модернизации на месте» ранее в главе.
Другой способ расширения схемы и домена предполагает запуск мастера
ADDSCW Как упоминалось ранее, инструмент adprep .
ехе интегрирован в этот мастер, и он позаботится обо всех нужных шагах.
Какой бы способ ни был выбран,процедуры отката в этот момент процесса такие же, как при модернизации на месте:восстановление данных состояния системы на контроллере домена хозяина схемы.

Построение сервера-члена Windows Server 2012

Uелевой контроллер домена начинается как сервер-член Windows Server 2012 в
исходном домене. Во время подготовки до запуска мастера ADDSCW должны быть
установлены роли Active Directory Domain Services и DNS.

Верификация DNS

Поскольку новый контроллер домена будет подперживать DNS, он должен быть
добавлен в качестве сервера имен в подходящие зоны прямого и обратного про­смотра. После того как сервер-член будет повышен, зоны DNS начнут реплицироuаться.
Чтобы удостовериться в корректном преобразовании имен контроллерами доме­
на, потребуется верифицировать DNS. Проведите проверки записей SRV с исполь­
зованием утилит NsLookup и DcCiag, описанных ранее в этой главе.

подготовка исходного контроллера домена

До выполнения этой операции вы должны решить, что конкретно будет делаться
на исходном контроллере домена. Если сервер остается в домене как контроллер до­мена, объем работы небольшой. Если же он будет развернут повторно, потребуется
обдумать, каким образом обеспечить на нем подключаемость к сети.
На исходном сервере должны быть собраны перечисленные ниже данные, чтобы
применить похожие настройки к целевому серверу-члену после повышения до кон­троллера домена.
• Имя сервера.
• IР-адрес сервера (1Pv4 и I Pvб).
• Назначенный сайт Active Directory.
• Назначенная организационная единица.
• Примененные объекты G PO и результирующий набор политики (RSOP).
Чтобы поместить эти данные в текстовый файл, воспользуйтесь следующей
командой:
gpresult /scope computer > GPOResult . txt
• Назначенные роли FSMO. Они должны быть переданы, если сервер планиру­
ется вывести из эксплуатации.
• Роль глобального каталога.
• Дополнительные службы, такие как DHCP, общий доступ к файлам и при­
нтерам, а также службы аутентификации Интернета (lnternet Authentication
Seivices) для УРN-подключений.
Наконец, создайте резервные копии данных состояния системы для всех конт­
роллеров домена и резервные копии файловой системы для важных служб с целью
их переноса за пределы Active Diгectory Domain Seivices.

Повышение сервера-члена

Мастер ADDSCW выполняет основные работы. В качестве конфиrураuии раз­
вертывания должен быть выбран переключатель Add а domain controller to an existing domain (Добавить контроллер домена в существующий домен). Кроме того, понадо­бится отметить флажки для ролей DNS и Global Catalog.
После того как мастер завершит работу, необходимо перезагрузить систему и
сконфиrурировать службу DNS на целевом контроллере домена. Несмотря на то что зоны DNS, интегрированные с Active Directory, были реплицированы на контролле­ра домена, служба DNS может их не видеть.
1. Выполните перечисление зон DNS и разделов приложений на исходном сер­
вере:
dnscmd /enumzones
dnscmd /enumdi rectorypartitions
2. Выполните перечисление зон DNS и разделов приложений на целевом сервере
с использованием приведенных выше команд.
3. Сравните результаты, полученные на двух серверах. Если зоны в списках от­сутствуют, с помощью команды dnscmd /enlistdirectorypartitions можно
заставить новый DNS-cepвep открыть свои разделы для совместного использо­
вания. Зоны должны присутствовать в списках сразу после того, как контрол­
лер домена появится в списке как сервер имен для этих зон.
dnscmd /EnlistDirectoryPartition
4. Просмотрите настройки DNS-cepвepa и сконфиrурируйте их согласно стан­
дарту, принятому в вашей компании.

Процедуры, выполняемые после миграции

Вы должны проверить службы домена. Можно прогнать тесты, основанные на
инструментах, и с помощью программы просмотра событий, DcDiag и NetDiag
просмотреть, имеются ли изна•1альные проблемы. Вы также должны провести тес­
ты на приемлемость для пользователя, такие как вход в систему и доступ к сете­вым ресурсам с новым контроллером домена в качестве доступной службы аутентификации.
Учитывая планы для процесса миграции, вы должны выполнить следующие
действия.
• Передачу ролей FSMO и назначение GC.
• Повторное назначение Р-адреса.

• Повторное назначение сетевого имени. Контроллер домена может быть пере­
именован в окне System (Система), или sysdm . cpl, панели управления либо
посредством команды netdom renamecomputer.
• Для DNS может потребоваться повторное назначение стандартных основных
зон.
Полезно знать …
После добавления контроллера домена Wmdows Server 2012 в существующий домен вы должны передать роли FSMO самому новому контроллеру домена.

Переналадка оборудования

Постепенная миграция предоставляет возможность повторно развернуть сущес­
твующий контроллер домена как контроллер домена Windows Server 201 2, хотя для него может быть не доступен корректный путь модернизации. Например, имеющий­ся контроллер домена способен выполнять и 64-, и 32-разрядные версии Windows Server. Как вы должны помнить, Windows Server 201 2 поступает только в 64-разряд­ном виде, поэтому модернизация исходного сервера окажется невозможной.
Эта проuедура требует доступной виртуальной машины или оборудования, под­
держивающего Windows Server 2012. Такая запасная машина обеспечивает промежу­точную фазу между двумя состояниями Active Directory. Выполните перечисленные ниже шаги.
1. Подготовьте лес/схему и домен.
2. Постройте на запасной машине сервер-член Windows Server 201 2.
3. Удостоверьтесь, что DNS адекватно поддерживает Active Directory.
4. Подготовьте исходный сервер.
5. Повысьте запасной сервер-член.
Подобно проuедурам, выполняемым после миграuии, вы должны проверить,
что внутри сети все работает, а пользователи имеют доступ к ресурсам.
6. Запустите DCPromo, чтобы удалить Active Directory из исходного контроллера домена. После этого он станет сервером-членом в домене.
7. Постройте на исходной машине сервер-член Windows Server 201 2.
Можно использовать то же самое имя и IР-адрес, что и на исходном сервере,
при условии удаления учетной записи компьютера из Active Directory.
8. Повысьте сервер-член до контроллера домена.
9. Проведите проuедуры, выполняемые после миграuии, в том числе пере­
смотр размещения ролей FSMO.
Запасной контроллер домена может иметь роли FSMO, назначенные ему из-за
вывода из эксплуатации исходного контроллера домена.
10. После проверки домена и служб контроллера домена запасной сер­
вер можно вывести из эксплуатации, удалив роль Active Directory Domain
Services или запустив командлет PowerShell под названием Uninstall­
ADDSDomainController.
ПОСТЕПЕННАЯ МИГРАЦИЯ: ДОВОДЫ ЗА И ПРОТИВ
Подводя итоги, ниже перечислены доводы в пользу проведения постепенной мигра­ции.
• Постепенная миграция последовательна в реализации. После ввода в строй кон­троллера домена Windows Server 2012 оставшиеся контроллеры домена при необ­
можно модернизировать или заменить.
• У пользователей сохраняются старые идентификаторы SID, а у домена — старые
доверительные отношения, так что любые серверы в других доменах (к примеру,
в доменах ресурсов, содержаших файловые серверы, серверы печати или почто­
вые серверы) будут по-прежнему без проблем опознавать пользователей.
• У пользователей сохраняются их старые пароли.
• Постепенная миграция предлагает возможность повторного развертывания
Wmdows Server 2012 на исходном сервере.
С этим подходом связаны также и недостатки.
• Для обеспечения гладких результатов требуется больший объем подготовки и
планирования.
• Любой существовавший ранее мусор остается в базе данных Active Dii-ectory.

Чистая изначальная миграция

Подход с чистой изначальной миграцией существующие домены оставляются без
изменений, и создается новый пустой домен AD. Затем можно воспользоваться инс­трументом миграции для копирования учетных записей пользователей и компьюте­ров из старого домена (или доменов) в новый домен AD.
Преимущество этого метода в том, что он является постепенным.
Миграция мо­жет охватывать период времени, когда еще возможно тестирование и решение про­блем. На протяжении этого периода пользователям по-прежнему будет нужен до­ступ к своим данным. Доступ может поддерживаться путем повторного назначения разрешений или зависимости от возможности хронологии SID.

чистая изначальная миграция является постепенной

Подход с чистой изначальной миграцией необходим в особых случаях. Прежде
всего, она последовательна, когда требуется реструктуризация леса. Модернизация на месте является односторонней. Если позже выяснится, что Active Directory вер­сии Windows Server 2012 не подходит, придется все восстанавливать с нуля. Но если есть новый домен, то в него можно скопировать какое-то подмножество пользова­телей, сообщив им о необходимости входа в этот новый домен. Если спустя неделю или две обнаружится, что данная версия AD является неприемлемой, учетные запи­си пользователей всегда можно вернуть обратно в старый домен.
Хотя постепенная миграция также последовательна, после ее проведения сушествовавший ранее мусор остается, приводя к ухудшению производительности
и проблемам. В какой-то момент плохо информированные администраторы могут
сконфигурировать Active Directory способом, который нарушает рекомендации, при­водимые в этой книге. И такие изменения останутся в домене после его миграции на последующую версию.

Чистая изначальная миграция также предоставляет промежуточную фазу, отсутс­
твующую в двух других подходах. В течение этой фазы у вас имеется возможность протестировать процесс, выясняя, могут ли пользователи обращаться к своим ре­сурсам, а также вскрывая общие проблемы, которые могут возникать при более поз­днем продвижении процесса миграции в производственной среде. Это уменьшаетсложности, присущие односторонней модернизации на месте.
МИГРАЦИЯ ВНУТРИ ЛЕСА
Имейте в виду, что те же самые процессы применимы также к миграции внутри леса.
Как вам известно, лес — это группа доменов, связанных друг с другом.
Пользователи, компьютеры и группы может понадобиться перенести на другой до­мен внутри леса.
Миграция таких объектов из одного домена в другой в лесе осу­ществляется с помощью описанных выше процедур.
Основное отличие в том, что объекты, подобные пользователям и группам, должны перемещаться, а не копиро­ваться.
После создания целевой учетной записи пользователя его исходная учетная запись удаляется. В случае отката учетные записи возвращаются обратно в исходный домен с использованием инструмента ADMT Новые учетные записи компьютеров создаются в новом домене, но старые учетные записи не удаляются, а отключаются в целях возможного отката.
Существуют две комбинации объектов, которые необходимо мигрировать вместе.
Они называются замкнутыми множествами.
•
Пользователи и глобальные группы.
Глобальные группы разрешают быть своими
членами пользователям и другим глобальным группам только из одного и того
же домена. Когда пользователь изменяет домен, он не может быть членом гло­
бальной группы, в которой он находился первоначально. При перемещении
глобальной группы члены из исходного домена также удаляются. Они должны
мигрировать вместе, чтобы поддерживать доступ в пределах ограничений, уста­
навливаемых правилами членства в глобальных группах.
• Компьютеры ресурсов и ло к а льные группы домена . Ресурсы не могут назначать разрешения локальным группам домена из других доменов. Если компьютер перемещен без назначенных локальных групп домена, он не сможет «увидеть» идентификатор SID группы в маркере безопасности пользователя, чтобы предо­ставить ему доступ. В качестве альтернативы вы можете изменить область дейс­твия локальной группы домена на универсальную, но это повлияет на размер глобального каталога.

Обработка разрешений в новом домене

Предположим, что вы избрали путь чистой изначальной миграции. Поскольку
в нем предусмотрена промежуточная фаза, можно ожидать, что пользователи орга­низации будут членами старого домена или созданного нового домена. Это требует, чтобы пользователи в новом домене имели возможность доступа к файлам и другим ресурсам в старом домене. Разнесенная по двум доменам организация будет сильно
зависеть от доверительных отношений между контроллерами доменов до тех пор, пока все серверы, содержащие ресурсы, не окажутся на той же самой стороне, что и пользователи.
Как сохранить пользователям из нового домена доступ к тем же ресурсам, который они имели в старом домене? Непрерывность бизнеса — это важный управленческий аспект; пользователям необходимо гарантировать возможность доступа к своим данным. Плавная миграция минимизирует перебои с доступом.
Существуют два подхода к поддержанию доступа к ресурсам: списки ACL и хро­
нологии SID. Аббревиатура ACL расшифровывается как «access contro list» (список управления доступом) — технический термин дЛЯ обозначения вкладки Security (Безопасность) диалогового окна свойств ресурса, подобного открытой папке. Аббревиатура SID означает «security identifier» (идентификатор безопасности), кото­рый представляет собой уникальный номер, назначаемый учетным записям с целью
их опознавания в рамках структуры разрешений. Если вы не моргнете после откры­тия вкладки Security диалогового окна свойств файла, то можете заметить SID, при­сутствующий в ACL, прежде чем компьютер преобразует этот SI D в дружественное
отображаемое имя.
СЛУЧАЙНОЕ СКОПЛЕНИЕ И РАЗНЫЙ ХЛАМ
Группа венчурного капитала приобрела две частные IТ-фирмы. Руководство вновь
сформированной корпорации захотело слить леса Active Directory двух фирм в один, чтобы получить единую систему сообщений на базе Excba11ge и сократить издержки. Казалось, что сетевая среда одной фирмы удерживалась в относительно целостном состоянии только за счет постоянного «склеивания». Неожиданные простои систе­мы были общим явлением, а производительность снижалась по прошествии всего нескольких дней работы после очередНой перезагрузки.
Вы могли подумать, что IТ-фирма могла бы воспользоваться собственным опытом
по управлению своей средой. Действительно, они владели технологией доставки вы­сококачественных служб. Однако располагали ли они временем и деньгами, чтобы заняться своей средой? К сожалению, нет.
Как объяснил один сотрудник, среда была результатом случайного скопления. Чтобы решить проблемы в стареющей и собранной по частям среде, администраторы и П­специалисты, занятые неполный рабочий день, обеспечивали временные решения, которые впоследствии становwrись постоянными. Похожие решения бьши и в Active Directory. Количество учетных записей пользователей втрое превышало фактическое число сотрудников. Количество учетных записей компьютеров также было больше реального числа компьютеров. Недокументированное решение VPN, которое опи­ралось на исходный контроллер домена, нельзя бьmо nереконфиrурировать. (Пароль администратора был утерян.) Таким образом, модернизация на месте или постепен­
ная миграция потенциально могли бы привести к уничтожению туннеля в сеть для удаленных пользователей. qистая изначальная миграция стала необходимостью.
Списки ACL на сервере
Один из подходов вполне очевиден (и довольно утомителен): нужно просто
пройтись по всем старым серверам и добавить новую учетную запись дпя пользо­
вателя Joe в списки разрешений на этих серверах. Такая работа может доставить действительно много хлопот, но некоторые инструменты миграции помогают ее ав­томатизировать.
Не принимая во внимание общее «удовольствие» от этого процесса, особен­но когда его нужно делать дпя более сотни общих ресурсов и свыше ста групп или пользователей, весьма высока вероятность допустить ошибку. Возможное нечаянное удаление разрешений на доступ для одной группы, добавление разрешений на до­ступ для не той группы или упущение из виду разрешений на доступ для требуемой группы гарантированно обеспечит насыщенное приключение всем участникам!
Использование хронологий SID
Вы знаете, что каждый пользователь имеет идентификатор SIO. Это было вер­
но со времен NT 3. 1 . Но на функциональных уровнях домена Windows 2000 Native
и Windows Serveг 2003 среда Active Oirectory позволяет пользователям поддерживать более одного SIO. Поскольку инструменты миграции создают новые учетные за­писи АО, эти учетные записи, конечно же, получают новые SIO. Но инструменты миграции могут также дополнять старые SIO пользователя новой учетной записью пользователя, эксплуатируя функцию, которая называется хронологией SIO. Затем, когда пользователь пытается получить доступ к ресурсам, к которым он имел доступ под своей старой учетной записью, его рабочая станция войти на ресурсы с приме­нением новой учетной записи Active Oirectory.
Как и со всеми попытками входа в домен, АО строит для пользователя маркер,
который содержит идентификатор SIO пользователя и идентификаторы SIO любых
глобальных и универсальных групп, к которым пользователь принадлежит. Вот как выглядит трюк с использованием хронологии SIO. Среда АО говорит: «Он является членом группы с данным идентификатором SI О», после чего отправляет параллель­но старый SIO пользователя из старого домена. Несмотря на то что это идентифи­катор SIO учетной записи пользователя, контроллер домена АО передает его так, как если бы он был SIO глобальной группы, и, несомненно, это приятно. Ресурс, просматривающий маркер, говорит: «Хм». Знаю я кого-нибудь из этих парней?
Хорошо, вот SIO этого пользователя «. Нет, мне этот парень незнаком». Но стоп, он же является членом группы ‘Joe из старого домена’. Я имею ACL для этой ‘груп­пы’, так что я догадываюсь, кто он такой». Таким образом, хотя пользователь Joe вошел как член новой группы с новым SIO, он притащил с собой старый SIO, поэ­тому получает доступ к своим старым ресурсам.
Подход с хронологиями SIO предпочтительнее метода с ACL, т.к. разрешения для
доступа к ресурсам остаются незатронутыми. Важно обеспечить запись хронологий
SIO во время миграции и удостовериться в том, что доверительные отношения меж­ду доменами не фильтруют их, когда пользователи «пересекают границы доверия»для доступа к ресурсу.
Что НЕОБХОДИМО для СОЗДАНИЙ ХРОНОЛОГИЙ SID
Ниже приведены важные замечания о хронологиях SID.
• Вам необходим инструмент миграции, которому известно, как создавать хроно­
логии SID. Это умеет делать бесплатный инструмент миграции Active DirectoГY
(Active DirectoГY Migratioп Tool — ADMT) от Microsoft, который будет описан
далее в главе. Доступны и другие инструменты миграции, но за них придется
платить. Например, Quest Software премагает комплект инструментов миграции,
утвержденных в отрасли.
• Инструменты миграции создают хронологии SID во время копирования учет­
ных записей пользователей из старого домена в новый домен с функциональным
уровнем Windows Server 2003/2008/20l 2. (Вспомните, что Windows Server 2012 мо­жет существовать с этими функциональными уровнями.) Прежде чем инструмент
миграции сможет работать, вы должны создать доверительное отношение между
старым и новым доменами. Но не имеет значения, каки м инструментом мигра­
ции вы располагаете, он не сможет создавать хронологии SID до тех пор, пока
вы не создадите такое доверительное отношение с помощью уrилиты netdom или
мастера создания доверительного отношения (New Trust Wizard) в ADDT
• Когда вы создаете чистый изначальный домен AD, удостоверьтесь, что он уже
переведен на функциональный уровень Windows Server 2012 (в конце концов, вы
строите совершенно новый домен, и можете извлечь из него максимум), прежде
чем создавать доверительное отношение и запускать инструмент миграции.
Вы можете держать хронологии SID продолжительное время, но на самом деле хро­нологии SID являются просто временными мерами, поскольку старые дцентифика­торы SID нужны лишь на период существования старых доменов.
Вероятно, это про­длится недолго. После вывода всех серверов и рабочих станций из старого доменастарые идентификаторы SID не потеряют свою ценность.
Таким образом, было бы удобно иметь возможность устранить эти старые хронологии SID из учетных запи­сей пользователей. Вы можете сделать это с помощью короткого сценария VВScript,
описанного в статье 295758 базы знаний Mkrosoft по адресу http : / / support . microsoft . com/kЬ/295758.

Использование бесплатного инструмента миграции ADMT от Microsoft

Если вы подумываете о чистой изначальной миграции, то вам нужен инструмент
миграции, а необходимость платить за такой инструмент может привести к отка­
зу от этого подхода к миграции. Тем не менее, компания Microsoft предлагает бес­платный инструмент миграции, который называется Active Directory Migration Tool
(ADMT). Первоначально написанный для Microsoft компанией NetIQ, инструмент
ADMT vЗ.2 поддерживает простоту использования первой версии и также добавляетряд удобных возможностей.

Пример проведения миграции

Чтобы провести базовую демонстрацию применения миграции, мы рассмотрим
следующий пример: фирма Bigfirm приобрела компанию OtherDomaiп. Компания
OtherDomain имеет домен Windows Server 2003 Active Directory. Фирма Bigfinn пост­роила чистый изначальный домен Windows Server 201 2 по имени Bigfirm . com для консолидации своих доменов в один. В Microsoft не выпустили новой версии ADMT для Windows Server 201 2; таким образом, для совместимости в Bigfinn также имеется контроллер домена Windows Server 2008 R2, установленный только мя нацеливания на АDМТ. После миграции этот контроллер домена будет выведен из эксплуатации в OtherDomain. Функциональный уровень леса установлен в Windows Server 2008 R2.
Инструмент ADMT будет также установлен на сервере-члене Windows Server 2008 R2 по имени ADMTOl.

Необходимо провести миграцию административного отдела из домена Windo w s
Serveг 2003 в OtheгDomain. В административном отделе открыт общий доступ к ра­бочей станции (работы у них было немного), а папки пользователей расположены на контроллере домена с именем DC2003.
Во время миграции членам отдела понадобится иметь доступ к своим домашним
папкам и входить на их рабочую станцию для выполнения своей работы, пока они
не переместятся в новый домен.
ЧИСТАЯ ИЗНАЧАЛЬНАЯ МИГРАЦИЯ: ДОВОДЫ ЗА И ПРОТИВ Подводя итоги, ниже перечислены доводы в пользу проведения постепенной мигра­ции.
• Она позволяет делать постепенную модернизацию.
• Чистая изначальная миграция копирует учетные записи пользователей, а не пе­ремещает их. Старые учетные записи остаются на случай, если что-то пойдет
не так.
• Она позволяет создавать контроллеры домена из чистой установки, избегая из­
лишней сложности и потенциальных ошибок, которые присущи модернизации
на месте.
• Чистая изначальная миграция позволяет консолидировать домены, сводя мно­
жество доменов в один или небольшое их число.
Хотя было указано, что чистая изначальная миграция обладает преимуществом обра­тимости, тем самым помогая управлять рисками, достается это не бесматно.
• Вам понадобится иметь больше машин, чем при простой модернизации. В но­
вом домене потребуются машины для функционирования в качестве контролле­
ров домена.
• Большинство инструментов миграции не могут копировать пароли. Инструмент
ADMT предоставляет для этого отдельную службу, которая должна быть установ­лена в исходном домене. В противном случае пользователям придется создавать новые пароли при первом входе в новый домен AD. Это не является проблемой,но при большом количестве удаленной рабочей силы может вызвать изряднуюголовную боль.
• Вам придется приобрести какой-то инструмент миграции. Вам доступен ADM1;
но в действительности он предназначен для миграций малого масштаба, в луч­
шем случае 1000 пользователей. Более развитые инструменты миграции недеше­
вы; расходы начинаются примерно с $10 на пользователя. Да, именно так — на
пользователя, а не на администратора.
• Невозможно создать домен Active Directory с таким же именем NetBIOS или
FQDN, как у исходного домена, поскольку это потребует возможности создания
двух доменов с одним и тем же именем (т.к. вы не вывели из эксплуатации ста­
рые домены, когда проводили чистую изначальную миграцию).
• Чистая изначальная миграция требует большего объема работы. Вам придется
позаботиться о том, когда именно перемещать любое заданное множество поль­
зователей и групп, может понадобиться корректировка ACL или перемещение
локальных профилей и т.д.
НЕСОВМЕСТИМОСТЬ ВЕРСИЙ
На момент написания этих строк последней версией инструмента была ADMT 3.2.
Тем не менее, она совместима только с Windows Server 2008 R2. При попытке уста­новки Active Directory Migration Tool (ADMT) 3.2 на сервере Wшdows Server 2012 вы
получите следующее сообщение об ошибке: «The Active Directory Migration Tool v3.l
must Ье installed on Windows Server 2008» («Инструмент Active Directory Migration Tool
v3.1 должен быть установлен на Windows Server 2008»). ADMT 3.2 и PES 3.1 не под­держивают установку на сервере Windows Server 2012. Программы установки предна­меренно блокируют неподдерживаемые ОС. В базе знаний имеется статья, описыва­ющая эту проблему: http : / /support .rnicrosoft . corn/kЬ/2753560 /en-us.
Как выглядит рекомендуемое решение? Установите ADMT 3.2 на сервере Windows Server 2008 R2 в целевом домене. Чтобы получить поддерживаемый сценарий, пона­добится также установить Windows Server 2008 R2 в качестве целевого контроллера домена в новом домене.
Но что произойдет, если вы уже указали функциональны й уровень леса Windows
Server 2012? К с<rастью, функциональные уровни леса и домена можно понизить доWшdows Server 2008 R2 с применением двух командлетов PowerShell.
Сначала необходимо понизить функциональный уровень леса:
Set-AdForestMode -identity bigfirrn. com
— forestmode Windows2 0 08R2 Forest
Вам придется подтвердить действие и подождать несколько секунд до успешного за­вершения команды. Затем нужно понизить функuиональный уровень домена:
Set-AdDomainMode -identity bigfirm . com
-domainmode Windows2008R2 Domain
Здесь снова придется подтвердить действие и после успешного понижения функцио­нального уровня домена можно установить контроллер домена Windows Server 2008 R2.
Е с ли вы использовали средство Dynamic Access Control (Динамический контроль до­ступа), то больше не сможете это делать, потому что оно требует функционального уровня леса Windows Server 2012.
В этом примере будут раскрыты следующие задачи.
• Как провести миграцию учетных записей пользователей и групп через два
леса.
• Каким образом хронологии SIO позволяют мигрированным пользователям
получать доступ к ресурсам в старом домене, списки ACL которых не изменя­
лись.
• Как инструмент АОМТ может изменить списки ACL на рабочей станции в
старом домене ресурсов. Это также переназначит локальные профили пользо­
вателей их новым учетным записям.
• Каким образом инструмент АОМТ может выполнить миграцию серверов-чле­
нов из старого домена в новый домен АО.
Чтобы все это заработало, мы настроим пять систем — две в OtherDornain. local и три в Bigfirrn. corn. Н иже описаны две системы в OtherDornain . local.
Мы настроим ОС для OtherDornain . local с именем DC2003. На DC2003 будут
созданы указанные далее объекты.
+ Открытая папка по имени Users с правами доступа Full Control (Полный до­ступ), выданными группе Everyone (Все). В оснастке Active Directory Users and
Computers будут сконфигурированы разрешения NTFS для конкретных учет­ных записей пользователей.
Организационная единица под названием Administration (Администрация).
+ Учетные записи пользователей домена для персонала административного раз­
дела.
+ Домашняя папка, отображенная на диск Z, с UNС-путем DC2 О О 3
users %username%.
+ Глобальная группа по имени Administration Group (Группа администрации)
и ее члены.
+ Общая папка под названием Administration с правами доступа Full Control
(Полный доступ), выданными группе Administration Group.
+ Клиент Windows 7 по имени Win7, который должен быть мигрирован в домен
Ьigfirm. com.
Домен Bigfirm. com будет содержать три системы.
Чистый контроллер домена Windows Server 2012 по имени DCOl.
+ Временный контроллер домена Windows Server 2008 R2, который будет исполь­зоваться для нацеливания на АDМТ. Он имеет имя W2KBDC.
• Сервер-член Windows Server 2008 R2 домена, где будет установлен инструмент
АDМТ. Этот сервер называется ADMTOl.
Весь сценарий изображен на рис. 7.51.
OtherDomain.local
DC2003
Win7
Двухстороннее
+— доверительное
____.,
отношение
Bigfirm.com
с
DC01 W2K8DC
ADMT01
Рис. 7. 51. Сценарий миграции

Установка доверительного отношения

Далее мы установим доверительное отношение между двумя доменами. В данном
примере быстрее всего это делается с помощью консоли Active Directory Domains and
Trusts ( domain . msc). Выполните в мастере New Trust Wizard следующие действия.
1 . Укажите тип доверительного отношения. Простым и эффективным здесь будет
внешнее доверительное отношение.
2. Укажите двухстороннее доверительное отношение. Учетным записям из каж­
дого домена нужен будет доступ к ресурсам в другом домене.
3. Создайте доверительное отношение в другом домене. Это требует наличия
полномочий администратора домена в данном домене.
4. Проверьте доверительное отношение, убедившись в том, что все работает кор­ректно.
В этой точке мы предпочитаем остановиться и провести тестирование — работа­ет ли доверительное отношение и корректны ли разрешения на DC2003?
Поскольку пользователи и глобальные группы из любого домена могут быть членами локальных групп домена и членами локальных групп сервера-члена, мы пытаемся добавить пользователя из противоположного домена во встроенную группу на контроллере домена.
Это обязательный шаг на пути движения. Итак, мы находим и добавляем
пользователя BigfirmAdministrator во встроенную группу Administrators до­
мена OtherDomain в оснастке Active Directory Users and Computers.
Но добавление пользователей и групп — это не то, что действительно необходи­мо.
Мы хотим, чтобы мигрированные учетные записи имели возможность доступа к ресурсам в противоположном домене. Именно здесь в игру вступает хронология
SID. Как утверждалось ранее, хронология SID трактуется как друтая группа в мар­кере безопасности, который будет передаваться домену ресурсов для доступа к ре­сурсам мигрированных учетных записей. Если вы не обращали внимания на экраны мастера New Trust Wizard и подобно автомату щелкали на кнопках Next (Далее) и ОК, то вполне могли пропустить диалоговое окно, показанное на рис. 7.52.
Рис. 7 .52. Предупреждение о фильтрации SID
Что это было? Фильтрация SID включена. Хронологией SID может воспользоваться злоумьштенник при атаке с повышением привилегий. Он мог бы сконстру­ировать маркер безопасности с S 1 D администратора домена внутри доверяемого
домена ресурсов. Из-за того, что SID распознается как принадлежащий админист­ратору домена, учетная запись злоумышленника получит такой же уровень доступа.
Фильтрация SID усекает любые идентификаторы SID, которые не происходят из до­веренного домена пользователя. По существу маркер безопасности наших пользова­телей не сможет нормально работать в исходном домене с включенной фильтраци­ей SID, т.к. значение хронологии SID отбрасывается. Проследовав по гиперссылке Securiпg external trusts (Защита внешних доверительных отношений) в этом окне, мы узнали, что с помощью команды netdom можно отключать и включать фильтра­цию SID для миграции, такой как проводимая в настоящее время.

Команда netdom в Windows Server 201 2 устанавливается сразу, но в ранних верси­ях она была доступна в составе инструментов поддержки (Support Tools). В Microsoft выпустили последнюю версию Support Tools после Windows Server 2003 Service Pack 2, поэтому поищите ее на веб-сайте Microsoft.
Для отключения фильтрании SJ D запустите показанную ниже команду. Само от­
ключение делает параметр /quarantine : no. Вы должны быть способны сами дога­даться, как включить фильтрацию.
Rem выполняется на dcO l . Ьigfirm . com
Netdom trust otherdomain /domain :Ыgfirm /quarantine : No
/usero : administrator /passwordo : P@sswOrd
Rem выполняется на DC2 00 3 . 0therDornain. local :
Netdorn trust Ьig firm /dornain : othe rdomain /quarantine : No
/use ro : administrator /passwordo : P@sswOrd

Обеспечение дружественности к ADMT на обеих сторонах

Из-за своих потребностей ADMT может считаться совершенно пугающей про­
rраммой. Эта проrрамма извлекает информацию, которая янляется закрытой и внут­ренней для домена — учетные записи и пароли пользователей — и открывает ее в совершенно друrом домене. Прежде чем ADMT сможет делать это, вам придется от­ крыть несколько запертых дверей. Ниже описано, что понадобится предпринять.

помещение учетной записи администратора домена в группы Administrators в каждом противоположном домене

Утилита ADMT нуждается в учетной записи, которая является членом груп­пы Dornai n Admins в целевом домене B i g f i rт . сот и членом локальных
групп Admir1 i s t rators на серверах и рабочих станциях в исходном домене
OtherDomain . local. Это позволит утилите ADMT вносить изменения в разрешения, права доступа пользователей и другие настройки, на что имеют привилегии все опытные администраторы.
В рассматриваемом примере мы создали учетную запись с незамысловатым
именем ADMT в домене Bigfirm . сот и поместили ее в группу Domain Adnins.
Используя доверительное отношение между двумя доменами, она была также помещена во встроенную группу Administrators внутри домена OtherDomain . local и в локальную группу Administrators на рабочей станции Win7 .Ыgfirт. сот. В исходном домене OtherDoma i n . l oca l необходимо удовлетворить похо­жее требование для службы шифрооания паролей (Password Encryption Service -PES).
Эта дополнительная служба будет читать пароль перемещаемой учетной
записи, шифровать его и затем сохранять в свойствах новой учетной записи. Ее
учетная запись должна быть членом группы Doтain Admins в исходном домене
OtherDomain . local и членом встроенной группы Administrators в целевом до­мене Bigfirm . сот.
Мы создали учетную запись с не менее незамысловатым именем PES в домене
OtherDomain. l ocal. В домене Bigfirm. сот мы открыли оснастку Active Directory Users and Computers и добрались до папки Built-in (Встроенные), чтобы найти там rруп­пу Adrпinistrators. Затем мы сделали учетную запись PES членом этой группы.

включение аудита

Инструмент ADMT имеет некоторые специфичные потребности аудита, по­
видимому потому, чтобы он мог проводить мониторинг того, как и что он де­
лает. В исходном домене — домене, из которого копируются пользователи, т.е.
OtherDomain . local — должен быть включен аудит успехов и отказов для управле­ния пользователями и группами.
На целевой и исходной машинах (W2K8DC . Bigfirm. com и DC2003 . OtherDomain.
local ) мы включаем аудит путем модификации групповой политики, которая называется стандартной политикой контроллеров домена (Default Domain Controllers Policy). В стандартной установке Windows Server 2003 для этого можно применять оснастку Active Directory Users and Computers. Щелкните правой кнопкой мыши на организационной единице Domain Controllers (Контроллеры домена) и выбери­те в контекстном меню пункт Properties (Свойства). В открывшемся диалоговом окне перейдите на вкладку Group Policy (Групповая политика), дважды щелкните на элементе Default Domain Controllers Policy (Стандартная политика контролле­ров домена), в результате чего откроется редактор групповой политики. В версии Windows Server 2008 R2 консоль управления групповыми политиками (Group Policy Management Console) устанавливается автоматически. Открыв эту консоль, добери­тесь до контейнера Group Policy Objects (Объекты группооой политики). Затем щел­кните правой кнопкой мыши на элементе Default Domain Controllers Policy и выбе­рите в контекстном меню пункт Edit (Редактировать).
Чтобы получить искомую политику, последовательно раскройте узлы Computer
Configuration (Конфигурация компьютера), Windows Settings (Настройки Windows),
Security Settings (Настройки безопасности) и Local Policies (Локальные политики); внутри Local Policies вы увидите папку Audit Policy (Политика аудита). В папке Audit Policy дважды щелкните на элементе Audit Account Management (Аудит управления учетными записями) и удостоверьтесь, что флажок Define These Policy Settings
(Определить следующие параметры политики) отмечен и рядом указано Success and Failure (Успех и отказ). Затем щелкните на кнопке Close (Закрыть), но не закрывай­те окно редактора групповой политики; ваша работа лака еще не закончена.

включение криптографических настроек в целевом домене

Для проведения миграции компьютеров с предшествующими версиями Windows
в целевой домен с контроллерами домена, функционирующими под управлением
Windows Server 2008 и выше, в целевом домене требуется еще одна настройка объекта G РО. В разделе параметров безопасности объекта G РО контроллера домена вклю­чите опцию Allow cryptography algorithms compatiЫe with Windows NT 4.0 (Разрешить криптографические алгоритмы, совместимые с Windows NT 4.0).
В узле Computer Configuration последовательно разверните узлы Administrative
Templates (Административные шаблоны), System (Система) и Netlogon (Папка
Netlogon). Щелкните правой кнопкой мыши на элементе Allow cryptography
algorithms compatiЫe with Windows NT 4.0 (Разрешить криптографические алго­
ритмы, совместимые с Windows NT 4.0), выберите в контекстном меню пункт
Edit (Редактировать), в открывшемся окне щелкните на переключателе EnaЫed
(Включено) и щелкните на кнопке ОК.

ПРЕЖДЕ ЧЕМ ЗАПУСКАТЬ ADMT
Как упоминалось ранее, при чистой изначальной миграции вы оставляете все сущес­твующие объекты на своих местах и перемещаетесь в новый лес или домен. Исходя из нашего опыта, хотя вы оставляете все нежелательные объекты позади, стрессо­генный фактор можно ослабить, если перед миграцией приступить к очистке старой среды. Провести уборку в старой квартире, несмотря на то, что вы переезжаете на новую квартиру? Да, правильно! В отношении миграции домена мы рекомендуем вьmолнить несколько шагов по очистке в исходном домене.
Первым делом, выясните, имеют ли объекты какие-то старые хронологии SID. Если вы собираетесь проводить миграцию пользователей, групп и компьютеров, то вам не нужны старые хронологии SID в учетных записях. Далее проверьте актуальность пользователей, групп и компьютеров, которые вы собираетесь переносить. Нет смысла выполнять миграцию старых и зависших пользователей, групп и компьюте­ров. По этой причине перед миграцией устаревшие неиспользуемые объекты потре­буется удалить.
После очистки среды удостоверьтесь, что вложенность групп соответствует принци­пу AGDLP (AGUDLP). Этот принцип означает, что учетная запись вложена в гло­бальную группу, глобальная группа является членом универсальной группы (если необходимо), а универсальная или глобальная группа является членом локальной группы домена. Такой локальной группе домена назначены разрешения на доступ к ресурсам.
Вероятно, это самые важные шаги, которые необходимо выполнить перед миграцией, и они помогают добиться успеха и мигрировать только те объекты, которые действительно нужны.

Установка ADMT и PES

Утилита ADMT доступна в виде загружаемого файла на веб-сайте Microsoft.
Установка этой утилиты в чистой изначальной среде совершенно прямолинейна, т.к. импорт баз данных из предыдущих версий не выполняется. Будет выдан запрос о том, в каком формате должна быть создана база данных — SQL Express или стандар­тный экземпляр SQL Server. В большинстве случаев предпочтение следует отдавать SQL Express.
ПРОБЛЕМЫ с УСТАНОВКОЙ ADMT
Поскольку существует много причин, по которым установка ADMT может завер­
шиться неудачяо, мы рекомендуем почитать следующую статью (на английском язы­ке), посвященную устранению проблем: http : / /Ьlogs . technet . com/Ь/askds/
archive/2010/07/09/admt-3-2-coпunon-installation-issues . aspx.
Создание ключа пароля в целевом домене
Теперь вы хотите, чтобы пароли пользователей передавались вместе с их учет­
ными записями. Утилита ADMT может делать это с помощью службы шифрова­
ния паролей (Password Encryption Service — PES). Перед тем, как будет проводиться
миграция паролей, ADMT требует от вас создания файла шифрования паролей на
сервере-члене ADMTOl и его копирования на контроллер домена DC2003, который будет применять этот файл при отправке паролей по сети в зашифрованном виде.

Для этого потребуется запустить ADMT из командной строки. Ниже приведен
пример синтаксиса команды:
adrnt key /option: create /sourcedomain : otherdomain
/keyfile : c : temppassword. pes /keypassword : P@sswOrd
Команда указывает на необходимость подготовки ключа, который может исполь­
зоваться доменом OtherDomain. local для передачи паролей в домен BigErm. com.
(Домен Bigfirm. сот не был явно упомянут потому, что команда вводится на кон­троллере домена Bigfirm. com.) В параметре /keyfile просто указано, куда поме­щать файл — С: temppassword.pes. Если на вашем сервере имеется флоппи-дис­ковод, то подойдет и А: . Совершенно не имеет значения, где вы разместите этот файл — важно лишь понимать, что вам придется каким-то образом транспортиро­вать его на контроллер домена OtherDomain . local, т.е. DC2003. Если все прошло нормально, утилита ADMT возвратит примерно такое сообщение: The password export server encryption key for domain ‘ otherdomain ‘ was
successfully created and saved to ‘ c : temppassword. pes ‘
Ключ шифрования для сервера экспорта пар о лей для домена o therdomain
успешно со з дан и сохранен в с : temp pa ssword . pes
На данный момент вы завершили работу с ADMTOl . Bigfirm. com. Время перехо­дить на DC2003.
Перемещение файла PES
После входа в систему контроллера домена DC2003 вам нужно поместить файл
PES из ADMTOl . Ьigfirm. com на локальный диск; мы обычно создаем общую папку и копируем в нее этот файл по сети. В качестве альтернативы его можно поместить на флоппи-диск, CD-ROM или любой другой носитель по своем желанию — тем или иным способом файл PES должен попасть на DC2003.
Установка DLL -библиотеки миграции паролей
на исходном контроллере домена
Служба Password Encryption Service была включена только в ранние версии
ADMT. В случае версии ADMT 3.1 она доступна в виде отдельного загружаемогофайла.
Служба PES устанавливается посредством файла MSJ по имени PWMIG . MSI;
дважды щелкните на нем, чтобы запустить мастер установки DLL-библиотеки
миграции паролей ADMT (ADMT Password Migration DLL Installation Wizard).
Ключевыми ингредиентами, требуемыми при установке, являются файл PES и со­
зданная ранее учетная запись службы. После установки вам будет пред11ожено пере­загрузить систему. Не забывайте, что служба сконфигурирована на запуск вручную.
Именно поэтому утилита ADMT не будет работать, пока вы не обеспечите функци­онирование службы PES.

Небольшие работы на рабочей станции

Если компьютеры должны быть перенесены, нам необходимо выполнить допол­
нительные действия. Утилита ADMT устанавливает на компьютере службу агента
для модификации настроек безопасности и запуска изменения членства в домене.
Перед установкой утилита выполнит несколько проверок, чтобы обеспечить успешный результат. Одной из них является проверка службы общего доступа к файлам и принтерам. В Windows ХР, Windows Vista и Windows 7 брандмауэр будет препятство­вать таким тестам.
• Запустите firewall . cpl , щелкните на вкладке Advanced (Дополнительные
параметры) и сконфиrурируйте .lLllЯ настроек ICMP опцию Allow lncoming Echo
Request (Разрешить входящий эхо-запрос). Это делается для вашей же пользы.
• На вкладке Exception (Исключения) выберите File and Printer Sharing (Общий доступ к файлам и принтерам).
Вдобавок мы рекомендуем выполнить следующие действия.
• Добавьте учетную запись ADMT в качестве члена локальной группы
Administrators, как упоминалось ранее.
• Установите ДJIЯ локальной учетной записи Administrator известный пароль.
Если изменения членства в домене даст сбой, то эта учетная запись может
оказаться единственным способом входа в систему рабочей станции с целью
устранения проблем.

запуск ADMT и миграция

При миграции пользователей и компьютеров из одного домена в другой базовая
последовательность действий выглядит так, как описано ниже.
1. Настройте доверительные отношения, параметры реестра и т.д.
2. Проведите миграцию учетных записей служб.
Для краткости здесь это детально не рассматривается. Учетная запись службы
переносится в новый домен, и в настройки серверов исходного домена вно­
сятся изменения, чтобы они использовали уже новую учетную запись.
3. Проведите миграцию глобальных групп из старого домена в новый.
Новые глобальные группы получают хронологии SID от старых таких групп,
поэтому любой член новой группы BIGFIRМAdшinistration будет иметь до­
ступ ко Асем ресурсам, к которым имели доступ члены группы OtherDomain .
local Administration. Это означает, что после миграции пользователей из
OtherDomain . local в Bigfirm. сош они могут быть автоматически помещены
в группу Administration внутри домена Bigfirm. com и будут иметь непос­
редственный доступ к своим старым ресурсам.
4. Проведите миграцию пользователей.
Как только выполнена миграция глобальных групп, можно приступать к миг­
рации пользователей в любом приемлемом ДJIЯ вас рабочем темпе. Пользовате­
ли, перемещенные в новый домен, будут иметь возможность доступа к общим
файлам, принтерам и другим ресурсам из старого домена, т.к. учетные записи
эти пользователей содержат хронологии SID из старого домена.
5. Проведите миграцию рабочих станций и серверов в домен Big f i rm . com.
Поменяйте членство в домене с OtherDomain . local на Bigfirm. com.
6. Переместите объекты безопасности.

Права доступа пользователей, разрешения файлов и общих ресурсов и членс­тво в локальных группах являются теми несколькими объектами, для которых
утилита ADMT может скорректировать списки ACL. Чтобы обеспечить доступ
к ресурсу, к серверам и рабочим станциям должны быть применены идентификаторы SID новых учетных записей и групп. В зависимости от того, как
проводится миграция, операuия такого типа может происходить перед мигра­цией серверов. В рассматриваемом примере локальные профили рабочей стан­ции должны быть отображены на новые учетные записи. Во время длительной миграции пользователи и их рабочие станции могут переноситься не одновре­менно. Таким образом, профили должны быть перемещены перед изменением членства компьютера в домене.
7. Повторите процессы миграции для ликвидации брешей.
Может понадобиться изменение членства в группах, учетные записи пользова­
телей могут требовать включения или отключения, а дополнительные объекты
безопасности могут нуждаться в переносе. Все это требует плановых запусков
утилиты ADMT
8. Проведите миграцию локальных групп домена.
9. После того как все серверы-члены перемешены в домен Bigfirm . сот и вы­
полнена проверка корректности изменения во всех разрешениях ссылок к
OtherDomain . local на ссылки к Bigfirm. com, домен OtherDomain . local
можно выводить из эксплуатации — разорвать доверительное отношение, изо­
лировать контроллеры домена OtherDomain . local и удалить хронологии SID
из перемещенных учетных записей пользователей.
Наступило время провести миграцию глобальных групп и пользователей, так что
давайте приступим к ней. Перейдите на сервер ADMT . Bigfirm. com и запустите ути­литу АDМТ, выбрав в меню Start (Пуск) пункт Administrative Tools�Active Directory Migration Tool (Администрированиеq Инструмент миграции Active Directory). Как показано на рис. 7.53, утилита обладает пользовательским интерфейсом довольно­ таки спартанского вида, в котором есть всего несколько доступных функций:
• миграция групп;
• миграция учетных записей служб;
• миграция пользователей;
• перемещение локальных профилей пользователей;
• миграция рабочих станций и серверов-членов.
Утилита делает очень многое, больше чем можно раскрыть в этой главе. Здесь
приводятся только основы. Мы настоятельно рекомендуем почитать справочный
файл, поступающий с утилитой, поскольку ADMT является мощным и удобным
инструментом, который позволяет проводить миграцию пользователей, групп, ма­
шин и даже настроенных сред Exchange! Кроме того, на веб-сайте Microsoft доступ­но для загрузки руководство по миграции (Migration Guide).
Рис. 7.53. Спартанский пользовательский интерфейс консоли ADMT

Графический пользовательский интерфейс,командная строка или vвscript

Утилита ADMT предлагает три интерфейса для проведения миграции. Каждый
из них обладает своими преимуществами.
• Графический пользовательский интерфейс. Основанная на технологии консоли
управления Microsoft (Microsoft Management Console), оснастка ADMT предо­
ставляет набор мастеров для пошагового выполнения каждой функции. Это
удобно, когда вы не знакомы с вариантами и обязательными параметрами для
миграции определенного объекта. Тем не менее, проход со щелчками в масте­
ре при большом количестве объектов довольно утомителен.
• Командная строка. С использованием инструмента командной строки ADMT
можно создавать пакетные файлы. Они удобны при миграции крупного числа
учетных записей. Каждая команда ограничена перемещением учетных записей
в одну организационную единицу, поэтому она не может охватить все. Ниже
приведен список доступных функций. Некоторые примеры применения будут
продемонстрированы в последующих разделах.
adrnt
Си н так с ис э той кома нды :
ADMT [ USER 1 GROUP 1 COMPUTER 1 SECURITY 1 SERVICE
REPORT 1 КЕУ 1 PASSWORD 1 CONFIG 1 TASK ]
ACTIVE DIRECTORY В WINDOWS SERVER 201 2 399
• VВScript. Сценарии VBScript предлагают логику для уnраnления операциями
АDМТ. Они также предоставляют функциональность чтения входных тексто­
вых файлов и выполнения отдельных операций над каждой записью. Таким
образом, большое количество операций с отличающимися требованиями мо­
гут объединяться в пакетное задание без особого труда. Написание сценариев
предусматривает наличие специальных знаний.
Мы настоятельно рекомендуем nыполнить такие операции в тестовой среде, что­
бы получить представление об утилите и разработать план конкретной миграции.
Смешивание разных методов может оказаться более эффективным, чем применение
только какого-то одного из них.
Информация, необходимая каждому методу и каждой функции, подобна, поэто­
му их описание может выглядеть повторяющимся. Далее мы рассмотрим несколько
примеров выполнения операций с использованием графического пользовательского
интерфейса и командной строки.

миграция пользователей и групп с помощью оснастки ADMT

Миграция групп и миграция пользователей очень похожи. В этом примере мы
будем проходить по экранам мастера миграции учетных записей пользователей ( User
A cc o un t Migration Wizard).
1 . В окне ADMT выберите в меню Action (Действие) пункт User Account Migration
Wizard (Мастер миграции учетных записей пользователей) и щелкните на
кнопке Next (Дarree); откроется знакомый экран приветствия мастера.
Ранние версии ADMT предлагали тестовый запуск операций. Версия 3.1 не
настолько робкая. Следовательно, обязательно выполняйте эти действия сна­
чала в тестовой среде в целях ознакомления, а затем проделайте их для испы­
тательных учетных записей в производственной среде.
2. Щелкните на кнопке Next, чтобы перейти на экран, показанный на рис. 7.54.
На этом экране просто выбирается домен, из которого будет осуществляться
перемещение, и домен, куда это будет делаться. Но на самом деле это действие
очень полезно, т.к. оно служит проверкой подключаемости. Если контроллер
домена DC2003 не функционирует, единственным вариантом в списках Domain
(Домен) внутри разделов Source (Исходный) и Target (Целевой) был бы домен
Bigfirm. com, что вряд ли можно посчитать интересной миграцией.
3. После выбора доменов щелкните на кнопке Next (рис. 7.55) и вы заметите неболь­шую паузу, связанную с подключением контроллеров доменов. Переключатель
Read objects from an include file (Читать объекты из включенного файла) на экра­не User Selection Option (Опция выбора пользователей), показанном на рис. 7.55,
требует импорта в мастере файла со списками пользователей и групп.
4. В данном случае выбран переключатель Select users from domain (Выбрать
пользователей из домена). Выбор этого переключателя приводит к отобра­жению экрана User Selection (Выбор пользователей), представленного на
рис. 7.56, который позволяет выбрать объекты для миграции, в этом случае
пользователей. Щелчок на кнопке Add (Добавить) обеспечивает открытие типового диалогового окна поиска, которое вы видели в оснастке Active Directory
5. Для этого примера щелкните на кнопке Add и выберите одного пользовате­ля stefan . roth, хотя можно было бы выбрать любое количество пользовате­лей и групп.
6. Щелкните на кнопке Next; откроется экран Organizational Unit Selection
(Выбор организационной единицы), показанный на рис. 7.57, который дает
возможность выбрать организационную единицу в целевом домене.
Подобно всем качественным инструментам, осведомленным об АО, утили­
та АОМТ позволяет выбирать организационную единицу, в которую должны
быть помещены перенесенные группы. Но не стоит переживать по поводу
того, что вам придется овладеть этим громоздким протоколом LOAP.
OrganizatIOnal Unit Selection
Рис. 7.57. Экран Organizational Unit Selection мастера
7. Щелкните на кнопке Browse (Обзор), в результате чего АОМТ позволит вы­
полнить навигацию по структуре АО.
8. Щелкните на кнопке Next, чтобы перейти на экран Password Options (Опции
паролей), показанный на рис. 7.58, на котором отображаются опции паролей.
Поскольку пароли присущи только учетным записям пользователей, экран
Password Options открывается только в мастере User Account Migration Wizard.
По существу вы можете перенести пароли или заставить АОМТ предоставить
новые пароли для пользователей. Первый вариант требует наличия сервера
PES. Во втором варианте необходимо указать местоположение для сохранения
текстового файла, содержащего все эти новые пароли. Как вы наверняка дога­
дались, распространение этого файла среди пользователей не должно делаться
в виде почтового вложения для группы рассылки All Users (Все пользова­тели). Следовательно, у вас будет дополнительная задача по передаче новых
паролей пользователям после миграции.
9. Щелкните на кнопке Next.
Появится следующий экран мастера, Account Transition Options (Опции пе­
ремещения учетных записей), показанный на рис. 7.59. На нем определяет­
ся способ обработки целевых и исходных учетных записей после миграции.
В зависимости от сценария, учетные записи может понадобиться отключить на
какой-то период времени. Утилита ADMT может обрабатывать обе стороны.
Обратите внимание на флажок Migrate user SIDs to target domain (Перенести
идентификаторы SID пользователей в целевой домен). Отметка этого флаж­
ка приводит к созданию хронологии SID для пользователя или группы. Таким
способом утилита ADMT говорит: «Создать элемент хронологии SID в домене
Bigfirm. com для учетной записи пользователя stefan. roth».
10. Щелкните на кнопке Next, чтобы получить нечто вроде полезной диагности­ки — если что-то не на месте для нормального функционирования механизма хронологии SID, утилита ADMT выдаст сообщение об ошибке. Или же бу­дет выдано предупреждение, например, о создании вспомогательной группы
OtherDomain$$$ и включении аудита, если вы забыли сделать это.
Всякий раз, когда вы применяете хронологию SID, утилита ADMT сверяет­
ся со старым доменом, в данном случае OtherDomain . local, для выяснения,
приемлемо ли создание вспомогательной группы. Эта группа имеет некоторое
отношение к тому, как ADMT гарантирует, что хронологии SID будут работать
корректно, но мастер в любом случае предпринимает проверку, удостоверяясь
в возможности создания данной группы.

Рис. 7.59. Экран Account Transition Options мастера
1 1. Щелкните на кнопке Yes (Да), и вы увидите экран входа в систему (рис. 7.60),
Рис. 7.60. Учетные данные для хронологии SID
12. Щелкните на кнопке Next, чтобы перейти на экран User Options (Опции поль­зователей), приведенный на рис. 7.61.
Обычно предпочтительной опцией для первой миграции является Fix useгs·
group memberships (Скорректировать членство в группах для пользователей).
Отметка этого флажка приведет к обновлению идентификаторов SID в груп­
пах, к которым принадлежат пользователи. Другие опции можно использовать
позже в повторных миграциях учетной записи дЛЯ содействия в отбрасывании
старой хронологии SID. Флажок Update user rights (Обновить права доступа
пользователей) отвечает за замену идентификаторов SID новыми SID. Флажок
Translate roaming profiles (Перенести блуждающие профили) позволяет перена­
значить разрешения новому идентификатору SID.
Экран Object Property Exclusion (Исключение свойств объектов), показанный
на рис. 7.62, дает возможность исключить из процесса миграции определен­ные свойства. Предположим, что в Bigfinn не хотят, чтобы перемешались поля
учетной записи пользователя с информацией об отделе или компании; посредством этого экрана такие поля можно выделить и исключить.
Вы осуществляете миграцию группы под названием Administration, но что
если группа с таким именем уже имеется? Ответ на этот вопрос дает экран
Conflict Management (Управление конфликтами), представленный на рис. 7.63.
Object Property Excluaion
Рис. 7.63. Экран Conflict Management мастера
13. Вы можете пропустить миграцию этой группы, затереть существующую группу
Administration или добавить в имени группы какой-то префикс.
14. Пройдите по оставшимся экранам мастера до появления кнопки Finish
(Готово), после чего процесс миграции запустится.

В диалоговом окне Migration Progress (Продвижение миграции) будет отображаться статистические данные по процессу миграции (рис. 7.64). В случае возникновения ошибок просмотрите соответствующий журнал, щелкнув на
кнопке View Log (Просмотреть журнал). Кроме того, можно обратиться к жур­
нальным файлам в папке с : windowsadmt. Журнальные файлы именуются с
применением даты/времени.

миграция с помощью командной строки

Как упоминалось ранее, утилита командной строки ADMT . ехе предлагает органи­зацию пакетных операций, что устраняет необходимость в утомительных проходах со щелчками по экранам мастеров консоли.
Ниже приведен пример миграции глобальной группы Administration:
rem миграция глобальной группы
adrnt group /N «adrninistration group» /sd : «otherdomain . local»
/td : «Ьigfirm. com» /to: «adrninistration» /mss : yes /fgrn: yes
/ugr : yes /rnms : no /co :Merge+REMOVEUSERRIGHTS+REMOVEMEMBERS
Хотя в этом примере присутствуют далеко не все параметры дан ной команды,
каждый параметр представляет экран мастера.
• /N. Учетная запись SAM (Security Account Manager — диспетчер учетных запи­сей безопасности) группы. Также могут быть указаны имена дополнительных
групп.
• / sd. Исходный домен.
• /td. Целевой домен.
• /to. Целевая организационная единица.
• /mss. Перемещение идентификаторов SID. Эквивалент флажка Migrate user
SIDs to target domain.
• / fgm. Корректировка членства в группах.
• /ugr. Обновление прав доступа группы.
• /mms. Перемещение членов. Если указано yes (да), все учетные записи пользооателей, являющихся членами, также будут подвергнуты миrрации.
• /со. Опции разрешения конфликтов. В этом случае группа будет сливаться с
rруппой, и меющей совпадающее имя, из этой rруппы будут удалены права до­
ступа пользователей, и любые существующие члены будут удалены.
Следующая команда проводит миграцию оставшихся учетных записей пользова­
телей о орrанизаuиоююй единице Administration:
rem миграция учетных записей пользователей
admt user /N «stefaп . roth» «marcel . zehner» «philipp . witschi» «chris . greuter»
/sd : otherdoma i п . local /td : Ьigfirm . local /to: «administration»
/mss : yes /co : ignore /ро : сору /ps : dc2003 . otherdomain . local
/dot : disaЫesource+enaЫetarget /uur : yes / fgm : yes
Дополнительные параметры являются специфичными для пользователей.
• /ро. Опция паролей.
• /ps. Сервер PES.
• /dot. Опции перемещения, которые управляют состоян ием учетных записей
после миграции.
• /uur. Обновление прав доступа пользователей.

тестирование доступа к ресурсам перемещенной группой

Поскольку перемещенная rруппа Administration в Bigfirm. com имеет иденти­
фикатор SID, совпадающий с SID группы Administration в домене OtherDomain.
local, и старая группа имела доступ к DC2003 Administration, то любой членновой группы Administration должен быть в состоянии обращаться к общему ре­сурсу DC2003Administration. Давайте проверим это.
. В домене B i g f i rm . com войдите в систему от имени учетной записи
Administrator и попытайтесь получить доступ к общему ресурсу Dc2003
Administration.
Это должно привести к выдаче сообщения о запрете доступа, поскольку учет­
ная запись не имеет разрешений на доступ к этому общему ресурсу.
2. Сделайте учетную запись Administrator членом новой перемещенной rруп­
пы Administration в Bigfirm. com.
3. Выйдите из системы и снова войдите как администратор.
Это должно делаться для того, чтобы перестроился маркер безопасности.
4. Попробуйте подключиться к общему ресурсу DC2003Administration еще раз.
Итак, общий ресурс Administration открывается! Значит, хронология SID ра­
ботает.

Перенос локальных профилей

Предполагая, что учетные зап иси пользователей были успешно перемеще­
ны, пользователи будут иметь возможность доступа к ресурсам внутри домена
OtherDomain . local. Однако они по-прежнему вынуждены работать на рабочей
станции, расположенной в этом домене. Если пользователи войдут в систему на
рабочей станции Win7 сейчас, им придется создавать новые профили. Они начнут
ворчать, что не могут найти фотографии своих близких, или, даже хуже, свои люби­мые веб-сайты в Интернете!
Чтобы предотвратить эти сложности, мастер переноса объектов безопасности
(Security Transition Wizard) обеспечивает переназначение идентификаторов SID для существующих профилей на всех платформах Windows.
Мастер Security Translation Wizard используется для выполнения процедур несколь­ких типов. Одной из них является перенос локальных профилей. Мастер может также переназначить разрешения для прав доступа пользователей, файлов и общих ресурсов, принтеров и реестра. Это будет подробно рассмотрено в следующем разделе.

Перенос профилей с помощью оснастки ADMT

Запустить мастер Security Translation Wizard можно через меню Action (Действие)консоли ADMT (см. рис. 7.53). Он запрашивает многие данные, которые также тре­буются мастерам миграции пользователей и групп.
• Исходный домен и контроллер домена.
• Целевой домен и контроллер домена.
• Выбор объектов, на этот раз компьютеров. Они выбираются посредством типового диалогового окна поиска. В нашем примере целевым компьютером является Win 7, локальные профили которого будут переназначены перемещен­ным пользователям.
После этого на экране Translate Objects (Переносимые объекты) мастера необ­ходимо указать объекты безопасности, подлежащие переносу (рис. 7.65). Детальное описание каждого из них можно найти в справочном файле ADMT В данном при­мере просто отметьте флажок User profiles (Профили пользователей).
На экране Security Translation Options (Опции переноса объектов безопасности),
показанном на рис. 7.66, доступны три опции для обращения со старым идентификатором SID — Replace (Заменить), Add (Добавить) и Remove (Удалить).
Рис. 7 .66. Экран Security Translation Options мастера
В справочном файле ADMT указано, какая опция требуется для каждого типа
объекта безопасности. В этом случае для локальных профилей необходимо выбрать Replace. Применение опции Add с локальными профилями имеет тенденцию на­рушать работу пакетов прикладных приложений, развернутых с помощью объектов групповой политики.
Старый идентификатор SID будет заменен новым SID учетной записи пользова­
теля, так что когда пользователь BigfirmStefan . Roth входит в систему на рабо­чей станции, он отождествляет исходный профиль с новой учетной записью.
После завершения работы мастера откроется окно Active Directory Migration Tool Agent Dialog (Диалоговое окно агента ADMT), представленное на рис. 7.67, кото­рое позволит выполнить действительную операцию на рабочей станции. Вы долж­ны запустить операцию, выбрав желаемый переключатель: Run pre-check (Запустить предварительную проверку) или Run pre-check and agent operation (Запустить пред­варительную проверку и операцию агента). (Если вы используете утилиту командной строки ADMT, операция запустится автоматически.) Предварительная проверка, как упоминалось ранее, протестирует службы файлов и печати (File and Print Services),
а более конкретно — проверит, может ли учетная запись ADMT получить доступ к
административному общему ресурсу наподобие Win7 admin$. Операция агента
установит этот агент на рабочей станции Win7 и затем выполнит перенос.
В разделе Agent Summary (Сводка агента) отображается продвижение.
Просмотреть дополнительную информацию можно, щелкнув на кнопках View
Migration Log ( Просмотреть журнал миграции) и Agent Detail (Детали агента).
Щелчок на кнопке Agent Detail вызывает открытие окна с подробными сведениями о событиях установки и запуска агента.
На время выполнения этой операции пользователи должны выйти из системы
рабочей станции, а не блокировать систему. Заблокированная рабочая станция бу­дет также блокировать доступ к профилю. Это приводит к тому, что агент выполнит операцию добавления, но по-прежнему может сообщать об ошибке или реагировать непредсказуемым образом. Исходя из нашего опыта, некоторые пользователи могут не понимать разницу между выходом из системы и ее блокированием.

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

миграция учетных записей компьютеров

Процесс миграции учетных записей компьютеров выглядит похожим на исполь­
зование мастера Security Translation Wizard и окна Active Directory Migration ToolAgent (рис. 7.68).
Раздел Agent Summary включает столбец Post-check (Постпроверка). Операция
агента производит изменение членства в домене, что потребует перезагрузки.
Верификация изменения выполняется в постпроверке. Перезагрузка делает важны­
ми настройки повторения постпроверки, которыми являются количество повторений и интервал между попытками. Через некоторое время операция завершается.

Соображения относительно отката

Наибольшим преимуществом чистой изначальной миграции является ее посте­
пенная природа. Она также приспосабливается к планам постепенного отката. Фазы миграции будут вскрывать любые затруднения и сбои. Вы должны застраховаться от них, проводя эксперименты. Если проблемы или затруднения возникают, их можно избежать за счет выполнения отката.
Рис. 7.68. Окно Active Directory Migration Tool Agent Dialog
для миграции учетных залисей комльютеров

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

Путь к функциональному уровню леса Windows Server 2012

Приняв решение о том, какой метод миграции применять, вы приступите к про­
цессу модернизации или миграции, как было описано в соответствующих разделах.
В лесе с единственным доменом вы модернизируете каждый контроллер домена
до Windows Server 201 2. После установки Windows Server 201 2 на всех контроллерах
домена можно поднять функциональный уровень домена до Windows Server 2012,
после чего также поднять функциональный уровень леса до Windows Server 201 2.
В среде с множеством доменов можно независимо модернизировать каждый до­
мен внутри леса с несколькими доменами. Например, вы можете начать модерни­
зацию контроллеров домена в дочернем домене, а потом заняться модернизацией
контроллеров домена в корневом домене того же самого леса. После модернизации все контроллеров домена до Windows Server 2012 можно поднять функциональныйуровень этого домена. Продолжайте модернизировать каждый домен до Windows Server 201 2 до тех пор, пока все домены внутри леса не будут иметь функциональ­ ный уровень домена Windows Server 201 2. Затем можно поднять функциональный уровень леса до Windows Server 2012.
Детальная процедура по поднятию функциональных уровней домена и леса была
описана н разделе «Поднятие функциональных уровней домена и леса» ранее в этой главе.

введение в Windows Azure Active Directorv

Ранее мы обсуждали среду Active Directory, находящуюся внутри помещений. Это означает, что среда Active Directory внутри компании защищена от внешнего мира.
Давайте кратко повторим, почему используется Active Directory. Эта служба катало­гов необходима для централизованного хранения и управления всеми пользователя­ми и компьютерами с целью контроля над поведением существующей инфраструк­туры Windows. За несколько лет до разработки Active Directory в отрасли 1Т имелась крупная проблема. В отсутствие Active Directory каждое приложение должно было хранить свои учетные данные для доступа локально в хранилище, таком как база данных, или локально на самом сервере. ОС Windows NT располагала довольно строгим спо­собом управления пользователями и компьютерами, но то решение было далеко от потребностей предприятия. Одной из главных причин разработки Active Directory была необходимость в централизованном управлении инфраструктурой. В наши дни та же самая проблема возникает в облаке Windows Azure. Ландшафт приложе­ний снова стал фрагментированным. Некоторые облачные приложения в компа­нии имеют хранилище конфигурации, содержащее в себе имена пользователей и пароли, так что такое приложение может аутентифицировать и авторизовать поль­зователя для работы с этим приложением в Windows Azure. Но теперь в игру всту­пает Windows Azure Active Directory. В настоящем разделе мы называем среду Active Directory, находящуюся внутри помещений, просто Active Directory, а среду Active Directory, размещенную в облаке Azure — Windows Azure Active Directory (WAAD, Windows Azure AD или Azure Active Directory).
Windows Azure Active Directory — это служба, которая предоставляет возможности управления идентичностью и контроля доступа для облачных приложений. Многие онлайновые облачные приложения от Microsoft уже используют Windows Azure AD.
Наиболее распространенным из них является Office 365; среди других можно упомя­нуть Dynamics CRM Online и Windows lntune.
WAAD предстамяет собой службу со множеством мадельцев (tenant), которая способна управлять миллионами компаний, сотней миллионов пользователей и тысяча­ми владельцев на единой платформе. Она оптимизирована для обеспечения высокой доступности и постоянной производительности и для поддержки максимальной мас­штабируемости. Означает ли это, что вы больше не нуждаетесь в среде Active Directory внутри помещений? И да, и нет. Windows Azure Active Directory может применяться сама по себе, но самый распространенный сценарий заключается в том, что компа­нии интегрируют Windows Azure АО со своими Active Directory внутри помещений.
В архитектурном смысле это может рассматриваться как Active Directory в облаке, простирающаяся от текущей среды Active Directory внутри помещений (рис. 7.69).
Благодаря такому расширению из Active Directory внутри помешений D облако, появляется возможность управления пользователями и группами локально с после­дуюшей реruшкацией изменений в WAAD, используя инструмент DirSync, который вскоре будет обсуждаться.

С помощью этого механизма вы сможете создать для своих облачных приложе­ний механизм единого входа (single sign-on — SSO). Учтите, что с применением толь­ко DirSync вы не получите возможность единого входа. Для SSO в Active Directory,находящейся внутри помещений, необходимо также развернуть службы федерации Active Directory (Active Directory Federation Services — AD FS). За дополнительной информацией обратитесь в раздел «Разновидности входа в Active Directory» далее в главе.

начало работы с Windows Azure Active Directory

Как получить учетную запись для владельца AD в Windows Azure Active Directory?
Простейший способ предусматривает подписку на учетную запись Office 365, вмес­те с которой вы немедленно обретете Windows Azure Active Directory. Причина в том, что Office 365 использует Windows Azure Active Directory. Другой способ по­лучения WAAD предполагает онлайновую подписку на Windows Azure (http : / /
www . windowsazure . corn/). Независимо от выбранного метода, вы будете иметь возможность управлять своей учетной записью из обоих порталов.
После подписки на Windows Azure вы можете приступать к управлению своим
каталогом (рис. 7.70).
Портал Windows Azure Management (Управление Windows Azure), портал Windows
Azure AD, портал Office 365 Account (Учетная запись Office 365), портал Windows
Intune Account (Учетная запись Windows lntune) и командлеты PowerShell для Windows Azure читают и записывают в единственный общий экземпляр Windows Azure AD,
который ассоциирован с владельцем вашей организации, как показано на рис. 7.71.

взаимодействие с Windows Azure Active Directorv

Если вы уже знакомы с Active Directory, то, скорее всего, применяли протокол
LDAP (Lightweight Directory Access Protocol — облегченный протокол доступа к ка­талогам) для запрашивания объектов из каталога. LDAP — это протокол уровня
приложений, предназначенный для доступа и обслуживания информации каталога.
Тем не менее, вы не можете использовать LDAP для доступа в WAAD, поскольку
LDAP не был предназначен для сценария с множеством владельцев. Еще одна про­
блема связана с тем, что протокол должен быть пригодным к эксплуатации на мно­гих платформах с разнообразными технологиями. По этой причине для доступа в WAAD разработчики из M icrosoft построили интерфейс REST (Representational State Transfer — передача репрезентативного состояния). REST является архитектурой, ко­ торая использует протокол НТТР для выполнения действий по созданию, чтению, обновлению и удалению (create, read, update, delete — CRUD) с применением ме­тодов GET, POST, РАТСН и DELETE. в Microsoft ссылаются на этот интерфейс REST как на АРl-интерфейс Windows Azure Active Directory Graph.
С использованием интерфейса такого вида связано несколько преимуществ.
• Независимость от платформы. Любое устройство способно применять НТТР и
вызывать НТТР-методы.
• Независимость от языка программирования. Код на любом языке программи­
рования может использовать архитектуру REST для взаимодействия с кодом
на других языках программирования; например, код С# может взаимодейство­
вать с кодом Java.
• Базирование на стандартах. Поскольку он выполняется поверх НТТР и осно­
ван на стандарте НТТР, АРl-интерфейс Windows Azure АО Graph может при­
меняться на любой платформе.
• Легкая управляемость. Брандмауэры можно легко сконфигурировать на про­
пуск трафика НТТР.
ТЕСТИРОВАНИЕ WINDOWS AZURE ACTIVE DIRECTORY CiRAPH
Чтобы получить представление о том, как работает Graph APl, можете опробовать его. В Windows Azнre предлагается тестовое приложение под названием GraphExpJorer (Проводник по Graph), которое позволяет запускать запросы от имени вла­дельца. Перейдите по ссылке http : / / graphexplorer . cloudapp . net/ и зарегист­рируйтесь с использованием своей учетной записи Microsoft, после чего щелкните на
ссылке Use Demo Company (Использовать демонстрационную компанию) в правом
верхнем углу. Ссылка отправит вам тестового владельца (GraphDirl) на https : / /graph . windows . net/GraphDirl . OnMicrosoft . сот, где вы можете оценить, как выглядит данная технология.
Например, если вы хотите запустить запрос для получения всех пользователей из это­го владельца, то просто добавьте выражение users в конец URL: h t tps : / / graph .
windows . net/GraphDirl . OnМicrosoft . com/users. Или же если необходимо воз­вратить атрибуты пользователя по имени Daniel@GraphDirl . onmicrosoft . сот, запустите https : / /graph. windows . net/GraphDirl . OnMicrosoft . com/users/Daniel@GraphDirl . onmicrosoft . com.
В верхнем правом углу находится также ссылка Oocumentation (Документация), ко­торая позволяет перейти к документации тто Windows Azure Active Directory Graph.Аст1vе D1Recт0Rv в W1NDows SERVER 201 2 415
В Windows Azure Active Directory имеются дополнительные протоколы. REST/
НТТР является лишь одним из четырех протоколов, необходимых для доступа и
работы с WMD. В табл. 7.3 приведен краткий обзор стека протоколов и указано
назначение каждого из них. В цели этой главы не входит погружение в данные тех­нологии, поэтому мы ограничимся только кратким описанием.
Таблица 7.3. Протоколы Windows Azure Actlve Directorv
Протокол
Доступ к каталогу RЕSТ/НТТР
OAuth 2.0
SAML 2.0
WS-Federation 1.3
Назначение
Создание, чтение, обновление и удаление объектов
и отношений в каталоге
Аутентификация между службами
Делегированный доступ
Аутентификация веб -приложений
Механизм единого входа
Аутентификация веб-приложений
Механизм единого входа

Синхронизация Windows Azure Active Directory

К этому моменту вы уже имеете определенное представление о том, что такое
WMD, где можно управлять пользователями WAAD и как взаимодействовать с
Windows Azure Active Directory. Реальное преимущество WAAD начинает проявлять­ся, когда вы интегрируете WMD с Active Directory внутри помешений. На показан­ном ранее рис. 7.69 демонстрировалось высокоуровневая концепция интеграции.
Основная uель — заставить каталог внутри помешений действовать в качестве
авторитетного источника данных, чтобы каталог Azure получил всех пользовате­
лей, группы и объекты контактов. «Авторитетный источник данных» означает, чтовы управляете только своим каталогом внутри помещений, а все внесенные в неrо изменения переопределяют настройки в Windows Azure AD. Обновления Windows Azure AD выполняются с помощью инструмента под названием DirSync, который позволяет синхронизировать ваши объекты с WMD и удерживать их в актуальном состоянии с каталогом внутри помешений. После установки инструмент DirSync запускается в фоновом режиме и синхронизирует WAAD раз в несколько часов.
Последняя версия DirSync таюке способна синхронизировать пароли пользователей в облаке. Инструмент DirSync синхронизирует не точные пароли, что создавало бы проблему в плане безопасности, а хеш-значения паролей. Только подумайте. какие преимушества это сулит вашей компании.
Ваши пользователи могут получать доступ к облачным приложениям с примене­
нием тех же самых учетных данных, которые они используют в корпоративной сети, развернутой внутри помешений.

Разновидности входа в Active Directorv

Мы обсудили два каталога и указали на возможность синхронизации объектов
(пользователей, групп и контактов) между каталогом внутри помещений и облаком,
включая синхронизацию паролей пользователей с применением DirSync. После
синхронизации двух каталогов и развертывания в них приложений вы можете пред­положить, что механизм единого входа стал доступным, но это не так.
ИНСТРУМЕНТ DIRSYNC
Инструмент DirSync относительно прост в настройке. Он представляет собой 64-
разрядное средство, которое требует наличия SQL Server 2008 R2 Express Editioп или полной версии SQL Server. После его установки обычно никаких дополнительных действий предпринимать не придется.
Важно понимать, что если вы собираетесь включить синхронизацию Active Directory, то ваша среда Active Directory внуrри помещений станет авторитетным источником данных, и будет перезаписывать изменения, сделанные синхронизированными поль­зователями в облаке. Существует одно исключение: если вы планируете разверты­вание Exchange Server в гибридном сценарии, то некоторые атрибуты должны быть записаны в Active Directory внутри помещений. Эти атрибуты описаны в статье базы знаний по адресу http: / /support .microsoft . com/kЬ/2256198/en-us.
Если вам нужна дополнительная информация по конфигурированию синхрониза­
ции каталогов, хорошей отправной точкой послужит следующая статья в TechNet:
http: //technet.microsoft . com/ru-ru/library/hh967642 . aspx.
Windows Azure Active Directory
Active Directory внутри помещений
К настоящему времени пользователи могут
входить в корпоративную сеть и использовать
приложения. При попытке доступа к облачному
приложению у них снова будут запрошены учет­
ные данные. Да, учетные данные те же самые, но
они не передаются облачному приложению. Такое
поведение называется одинаковым входом (same
sign-on).
Чтобы получить механизм единого входа, по­надобится развернуть службы федерации Active Directory (Active Directory Federation Services —
AD FS). Развертывание инфраструктуры AD FS внутри корпоративной сети позволяет установить отношение доверия проверяющей стороны между ва­
шей фермой серверов AD FS и Windows Azure
Active Directory. Такое отношение доверия проверяю­
щей стороны делает возможной передачу маркеров
аутентификации между корпоративной сетью и
Windows Azure AD. На рис. 7.72 показано, как это
работает на высоком уровне.
Рис. 7. 72. Единый вход в
Windows Azure Active Directory
Если вы развернете AD FS в Active Directory, то
не только получите действительный единый вход
для облачных приложений, но также сможете раз­
вернуть механизм двухфакторной аутентификации. Метод двухфакторной аутенти­
фикации вынуждает пользователей помимо предоставления своих учетных данных
добавлять еще один защитный код, чтобы пройти аутентификацию для приложений
Windows Azure. Этот дополнительный код формирует добавочный уровень защиты
внутри инфраструктуры.
Чтобы вы получили лучшее представление о доводах за ( +) и против (-) каждого уровня развертывания, в табл. 7.4 приведена краткая сводка.

Таблица 7.4. Ин теграция с Windows Azure Active Directorv
Учетная запись Windows
Azure Active Directory
+Дополнительное конфигу­
рирование не требуется
— Пользователь имеет две
пары учетных данных
— Отсутствует механиз м еди­ного входа для облачных приложений
— Двухфакторная аутентифи­кация не может быть реа­лизована
Учетная запись Windows Azure
Active Directory + DirSync
+ Среда Active Directory внутри
помещений является авторитет­
ным источником данных
+ Пользователь имеет одну пару
учетных данных
— Отсутствует механ и зм единого
входа для облачных приложений
— Двухфакторная аутентификация
не может быть реализована
— Инструмент DirSyпc должен быть
установлен на выделенном сер­
вере внутри помещений
Учетная запись Windows Azure
Active Directory + DirSync + ADFS
+ Среда Active Directory внутри
помещений является авторитет­
ным источ ником данн ых
+ Механизм единого входа
+ Двухфакторная аутентификация
— Инструмент DirSyпc должен
быть установлен на выделенном
сервере внутри помещений
— Ферма серверов AD FS должна
быть развернута внутри поме­щений
В этом разделе был представлен каталог Windows Azure Active Directory и пока­зано, как управлять и интегрировать его в свою среду. Теперь вы должны обладать базовым пониманием большинства важных терминов, необходимых для того, чтобы приступить к работе с WAAD.

Обзор технологии Workplace Join

Современные компании сталкиваются с крупными проблемами, связанными со
всем многообразием устройств в своих сетях. Представьте себе консультанта, кото­рый привлечен к работе над IТ-проектом. Генеральный директор этой компании использует в своей работе iPad. Сотрудникам из отдела маркетинга необходимо пре­зентовать товары на другом устройстве, таком как проектор. Все эти люди применя­ют свои устройства дома и в офисе, и для всех них не сушествует устройства, кото­рое можно было бы считать стандартным. Одной обшей характеристикой является потребность доступа к определенным ресурсам в сети.
Поскольку все эти устройства требуют доступа к корпоративной сети и приложениям, предоставление безопасного и согласованного способа для обеспечения доступа к нужным ресурсам, а также для управления устройствами и данными было сложной задачей. До сих пор выбирать можно было один из двух вариантов: либо присоединять устройство к Active Directory (если это возможно), либо не присоеди­нять. Оба подхода обладают достоинствами или недостатками для пользователя, по­лучающего доступ к данным и приложениям, а также для управления устройствами.
Технология Workplace Join (Подключение к рабочему месту) родилась из политики BYOD (bring-your-own-device — принеси свое собственное устройство), которая раз­решает сотрудникам приносить свои персональные устройства на рабочие места и пользоваться ими.

что собой представляет технология Workplace Join

Технология Workplace Join поставляется в составе Windows Server 20 12 R2IO, а также интегрирована в Windows 8. 1 ; она позволяет своим пользователям получать доступ к приложениям и данным, где бы они ни были, без присоединения к домену
из любого устройства. Вдобавок Workplace Join предлагает пользователям механизм единого входа для корпоративных приложений, и администратор компании по-пре­жнему может контролировать, кто имеет доступ к ресурсам компании. Конечно, та­кая тесная интеграция устройств привносит определенные риски, но по этой причи­не в Microsoft предоставили многофакторную аутентификацию и также добавили к Active Directory Federation Services в Windows Server R2 функциональность для управ­ления этими рисками.
Регистрация очень проста. В зависимости от устройства вы либо регистрируете
устройство через URL, либо конфиrурируете настройки компьютера. В обоих сцена­риях для регистрации устройства предоставляется основное имя пользователя (user
principal name — UPN), которое во многих компаниях соответствует адресу элект­ронной почты пользователя. После этого клиентское устройство подключается либо изнутри сети компании, либо снаружи (по Интернет) через службу Web Application Proxy компании и выполняется аутентификация пользователя. Служба Web Application Proxy, появившаяся в Windows Server 201 2, является час­тью службы роли Remote Access, которая позволяет предоставить пользователям вне организации доступ к приложениям, функционирующим на серверах внутри организации. Мощь �Ь Application Proxy заключается в опубликованных приложениях, которые доступны на любом устройстве. Если учетные данные соответствуют, но­вая служба в Windows Server 2012 R2 AD FS под названием DRS (Device Registration Service — служба регистрации устройств) зарегистрирует устройство пользователя в
Active Directory. Для такой цели в Active Directory бьm создан новый класс объектов.
Этот новый объект устройства может применяться для предоставления условного и детализированного доступа к данным и ресурсам в корпоративной среде. Вы можете считать Workplace Join облегченной версией присоединения к домену (рис. 7.73).
Пользователи, подписавшиеся на это новое средство, не передают полный кон­
троль над устройством администратору, но администратор контроллеров домена
Windows Server 2012 R2 может применять набор политик безопасности и проводить
ограниченную очистку классифицированных корпоративных данных.
Аутентификация в Windows Azure Active Directory

Пользователь регистрирует
устройство (BYOD)Служба Web Application
Ргоху публикует
корпоративные ресурсы и может использоваться многофакторная аутентификация
AD FS регистрирует устройство в Active Directory
Рис. 7. 73. Технология Workplace Join Active Directory создает новый
объект для устройства

Это дает администратору хороший контроль над тем, что происходит с корпоративными данными и как к ним производится доступ. С другой стороны, пользова­тели по-прежнему эксплуатируют свои устройства так, как хотят, а также получают простой и комфортный доступ к сетевым ресурсам.
НАЧАЛО РАБОТЫ С WORKPLACE JOIN
Технология .Ьrkplace Join является частью Windows Server 2012 R2 и Wmdows 8.1,
поэтому м ы предоставили вам краткое введение о том, что собой представляет
.Ьrkplace Join. Об этой технологии можно рассказать еше многое, но это сильно бы увеличило объем данной книги.
Если вы желаете опробовать .ЬrkpJace Joil1 в испытательной среде, по следующейссылке доступно удобное пошаговое руководство (на английском языке) о присо­единении устройства iOS и устройства Windows с использованием Workplace Join:
http : //technet .microsoft . com/en-us/liЬrary/dn452410 . aspx.