Главная > Active Directory > Microsoft University Online 2011 – Active Directory (Обслуживание Active Directory Domain Services)

Microsoft University Online 2011 – Active Directory (Обслуживание Active Directory Domain Services)

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена Microsoft University Online. В этой прошлой статье мы говори о использовании Group Policy Preference, а также затронули вопрос моделирования, применяя групповых политик, и использования оснастки Group Policy Results. В данной статье мы поговорим об обслуживание Active Directory Domain Services и об обслуживание Group Policy.

Когда мы говорим об обслуживании групповых политик, как правило, мы подразумеваем управления их жизненным циклом. Так как в компании ИТ всегда развивается, появляются новые требования к безопасности, к настройке клиентских компьютеров и серверов, групповые политики постоянно обновляются. По этой причине необходимо всегда с осторожностью вводить изменения, оптимальным вариантом является проведения таких действий в тестовой лаборатории. Когда ведется работа с групповыми политиками важно помнить о том, что необходимо систематически проводит резервное копирование политик. Впрочем, когда мы говорим о резервном копировании Active Directory, мы должны понимать о том, что если мы делаем резервное копирование с помощью Windows Server backup, то мы делаем резервное копирование состояния системы. В резервное копирование состояния системы входит резервное копирование следующих объектов: реестр, COM+ база данных, загрузочные файлы, база Active Directory Certificate Services (AD CS), база Active Directory Domain Services (Ntds.dit), папка SYSVOL, информация о кластере, мета каталог Microsoft Internet Information Services (IIS). Разумеется, это можно производить с помощью создания резервных копий только папки SYSVOL, но этот метод не всегда является удобным, а в некоторых ситуациях восстановление из такой резервной копии весьма трудоёмкое или не возможным в силу тех или иных обстоятельств. По этой причине существует более удобный метод создания архива групповых политик, а именно использование возможностей оснастки Group Policy Management Console. Конечно же, у этого способа есть один большой недостаток, такое резервное копирование проходит в ручном режиме. Но если рассматривать идеальный вариант, когда политики вначале разрабатываются в тестовой среде, а в рабочей среде применяется только после проведения тестирования, то тогда данный недостаток не значителен. Давайте разберемся, как работает данная система.

В оснастке Group Policy Management Console мы должны выбрать домен, с которым мы будем работать. В нем мы должны выбрать раздел Group Policy Objects, который существует в каждом домене. В данном разделе находятся все групповые политики, которые присутствуют в домене, хочу заметить, что не все из этих политик обязательно должны быть закреплены за каким-то организационным подразделением или корнем домена. Из данного раздела мы и будем управлять резервным архивом наших политик, создавать резервные копии наших политик, и импортировать наши групповые политики. Нажав на сам раздел Group Policy Management Console, мы увидим основное меню, в этом меню мы можем создать политику, сделать резервное копирование всех политики, управлять резвыми копиями политик, создание таблицы миграции. Если мы нажмем правой кнопкой мишки на политике, то в меню мы увидим что можно сделать резервную копию политику, импортировать настройки политики, восстановить её из резервной копии, а также основные действия для работы с политикой. Раздел «создание таблицы миграции» используется при миграции политик из тестовой среды в рабочую среду, если необходимо в политиках менять внутренние переменные. Примером использования этого функционала очень простой. У вас есть тестовая среда, в которой вы разворачиваете политики. Вероятнее всего в ней название групп отличаются, а также UNC адреса, или любые другие переменные, например в тестовой среде адрес WSUS сервера wsus.test.company.com, а в рабочей среде wsus.company.com. Или UNC адрес порешаемой папки в тестовой среде у вас \\share.test.company.com\test, а в рабочей среде \\share.company.com\Users. Для того чтобы при импорте политик из тестовой среды, в рабочую, автоматически поменялись переменные, которые используются в тестовой среде на переменные которые используются в рабочей среде. Для проведения такой миграции, необходимо сделать резервную копию политики которую мы планируем импортировать с изменение переменных. После того как резервная копия готова, необходимо открыть редактор миграционной таблицы, и в меню этой таблицы в разделе Tools выбрать “Populate from Backup”, после чего выбираем резервную копию, и в этой резервной копии выбираем необходимую нам политику. После чего программа сама выберет все переменные и вставит их в таблицу, которую необходимо будет до редактировать, указав переменные на которые необходимо менять. После создания таблицы миграции, её необходимо сохранить и переместить в рабочую среду вместе с политикой. Для окончательной миграции групповой политики из тестовой среды в рабочую среду, необходимо в рабочей среде создать политику, после чего импортировать настройки из резервной копии, которую мы перенесли. Во время импорта политики, на первом шаге мастер предложит нам сделать резервную копию данной политики, но это не нужно, потому что политика была только создана и не содержит никаких настроек. После шага с резервным копированием мастер проверит политику на наличия переменных, которые можно изменить, используя таблицу миграции, и если такие существуют, он предложит выбор способа импорта. По умолчанию он будет перемешать существующие настройки, которые зашиты в резервной копии политики, но мы можем выбрать миграционный файл, на основе которого при импорте переменные будут заменены. Хотелось бы еще раз напомнить, что когда вы задаёте какие-то права, то желательно задавать их группе, а не пользователю. Также хочу обратить внимание, что перед импортом или восстановлением политики из резервной копии всегда можно посмотреть настройки политики, что очень полезно.

Также важной частью обслуживания Microsoft Active Directory Domain Services, является обслуживание файла с базой Microsoft Active Directory Domain Services. Основной утилитой для обслуживания Microsoft Active Directory Domain Services является утилита, которая называется NTDSUtil. Как вам наверно известно, файл базы данных Microsoft Active Directory Domain Services называется NTDS.Dit. При установке по умолчанию он находиться в папке Windows\NTDS. Но это не рекомендуемое разрешение для базы данных. Лучшей практикой является хранение файла базы данных Microsoft Active Directory Domain Services на отдельном диске. Но что же делать если на вашем домен контроллере используются настройки по умолчанию? Его можно просто перенести на другой диск с помощью утилиты NTDSUtil. Для этого необходимо остановить роль Microsoft Active Directory Domain Services это делается с помощью команды «NET stop NTDS», но данный способ возможен только в Microsoft Windows Server 2008 и Microsoft Windows Server 2008 R2. Если же у вас Microsoft Windows Server 2003 или Microsoft Windows Server 2003 R2 то вам необходимо перезагрузить ваш контролер домена и запустить его в режиме восстановления каталога. Чтобы войти в режим восстановления каталога этого необходимо перезагрузить ваш домен контролер и при начале загрузки нажать F8, в появившемся меню необходимо выбрать Directory Service Recovery Mode. Когда ваш домен контролер загрузится вам необходимо зайти под учетными данными администратора. Для этого в поле имя пользователя вводим .\Administrator, а пароль тот который был указан во время установки домен контролера. После этого вы можете работать с файлом базы Microsoft Active Directory Domain Services. Для этого необходимо запустить утилиту NTDSUtil. Когда вы запустите NTDSUtil, откроется командная строка управления этой утилиты. В начале необходимо подключиться инстансу, который называется NTDS, для этого необходимо написать в командной строке NTDSUtil «Ac In NTDS», что означает активировать инстанс NTDS. После того как мы активировали инстанс необходимо перейти в систему управления файлами, для этого пишем «files». Если вы работаете с Microsoft Windows Server 2008 и Microsoft Windows Server 2008 R2 и забыли остановить роль Microsoft Active Directory Domain Services, то появиться сообщение о том, что нет доступа к файлу и необходимо остановить сервис. Если никаких ошибок не было, то можно преступать к перемещению файла базы данных, также таким способом мы можем переместить лог файлы роль Microsoft Active Directory Domain Services. Для этого необходимо ввести следующую команду «move db to %path%», где %path% путь к новому размещению нашего файла базы данных Microsoft Active Directory Domain Services. Для перемещения логов необходимо ввести «move logs to %path%», где %path% путь к новому размещению логов Microsoft Active Directory Domain Services. После чего необходимо проверить права на доступ к новому размещению нашей базы данных и логов. Главное чтобы система и пользователи из группы Administrators имели полные права, и все дочерние объекты наследовали это правило, а также запретить наследование правил для этого объекта от его родителя. После этого необходимо в командной строке NTDSUtil ввести команду «integrity», для проверки целостности. После этого можно выходить из NTDSUtil для этого необходимо выполнить команду «quit».

Также с помощью этой оснастки можно перемешать, или захватывать роли Flexible Single Master Operation. Существует несколько действий, при которых недопустимы конфликты. Например создание нового домена в лесу. Допустим, два администратора решили в одно время создать по домену test в лесу corp.com, то система сама никогда не сможет определить какой из них нужно оставить. Поэтому и существуют роли, которые называются FSMO. Их задача не допускать конфликтов в Microsoft Active Directory Domain Services. Существует всего пять FSMO ролей, это Хозяин именования домена (Domain naming master), Хозяин схемы (Schema master), Хозяин инфраструктуры (Infrastructure Master),Эмулятор PDC (PDC emulator), Хозяин RID (RID Master). Две первые из них в лесу уникальны и существуют в одном экземпляре, и соответственно три присутствуют в каждом домене.

Роль хозяин именования домена (Domain naming master) — отвечает за изменение пространства доменных имен каталога в рамках леса. Только контроллер с этой ролью имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

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

Хозяин инфраструктуры (Infrastructure Master). Контроллер домена, выполняющий роль хозяина инфраструктуры, отвечает за обновление идентификаторов защиты (GUID и SID для участников безопасности) и различие имен объектов.

Эмулятор PDC (PDC emulator). Эмулятор основного контроллера домена необходим для синхронизации времени в рамках компании. В состав Windows входит служба времени W32Time, используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows в рамках одной компании должны иметь одинаково настроенные часы. Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

Хозяин RID (RID Master). Контроллер домена, выполняющий роль хозяина RID, отвечает за обработку запросов пула RID от остальных контроллеров в рамках определенного домена, а также удаление объектов из домена и помещение их в другой домен. Идентификатор SID участника безопасности должен быть уникальным для всего домена, поэтому каждому участнику безопасности присваивается уникальный идентификатор безопасности SID, который содержит идентификатор домена и относительный идентификатор RID, который является уникальным для каждого принципала безопасности. Во всех идентификаторах SID присутствуют четыре различных элемента.

Для передачи роли необходимо выполни следующие команды. Вначале запустить утилиту NTDSUtil. После чего выполнить подключение к серверу, которому вы хотите передать одну из ролей FSMO. Для этого в командной строке NTDSUtil пишем «connections», этой командой мы переходим в меню управления соединениями. После выполнить команду подключения к серверу, для этого выполняем «connect to server <имя конечного сервера>». Теперь необходимо перейти в основное меню, для этого пишем «quit». И теперь можно передавать роль, для этого пишем «Transfer <имя роли>». По окончанию передачи ролей, выполняем команду выхода, выполнив «quit». Таким же образом происходит и захват роли, только вместо «Transfer <имя роли>», выполняем «SEIZ <имя роли>». Захват ролей необходим для тех случаев когда домен контроллер, которому принадлежала роль вышел из строя, и по этой причине нельзя её перенести.

  1. Комментариев нет.
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: