Как настроить время на контроллере домена

Как настроить время на контроллере домена

Как настроить синхронизацию времени во всём домене сразу? И так, чтобы работало дальше само? А когда контроллер домена с ролью PDC изменится, что делать? А если уже синхронизация времени в домене настроена, но работает плохо, как починить?
Обо всём этом читайте в этой статье.

Немного теории

Синхронизация времени в домене может (теоретически) работать сама, безо всяких настроек. Выглядит это обычно так:

1. Компьютеры домена и серверы синхронизируют свое время с контроллерами домена (с ближайшими к ним).
2. Контроллеры домена синхронизируют свое время с контроллером домена, которому назначена FSMO роль PDC (в терминах windows 2000 — «первичный контроллер домена»).
3. Контроллер домена (КД) с ролью PDC синхронизирует время с внешним источником.

Настройка времени для виртуальных … Настройка синхронизации времени по NTP … Установка доменных служб active … Как указать сервер точного времени для …

А дальше — начинаются ньюансы:

• Если контроллер домена виртуальный, в настройках виртуальной машины должна быть выключена синхронизация времени [с хостом]. Иначе (если, к примеру, хост с виртуальными машинами — в домене): виртуальный контроллер домена будет (автоматически) синхронизировать время с хостом, а хост — с ближайшим контроллером домена, т.е. со своей виртуалкой.
• Если синхронизация времени уже настроена (вручную или через групповые политики) то задаваемые Вами новые настройки могуть не примениться (несмотря на сообщение successful во всех командах) и тогда потребуется полный сброс настроек синхронизации времени на проблемных компьютерах или контроллерах домена.

Настройка контроллера домена

Для синхронизации времени с контроллером домена на сервере, выполняющем роль эмулятора PDC, с использованием командной строки должны быть выполнены следующие действия:

1. Проверьте, что контроллер домена, на котором вы работаете, является эмулятором PDC, выполнив команду

netdom query fsmo

2. На сервере-эмуляторе PDC запустите следующие команды синхронизации времени в указанном порядке:

net stop w32time

w32tm /configure /syncfromflags:manual /manualpeerlist:",0×1 , 0×1 , 0×1 , 0×1"

Внешним источником времени по умолчанию для Windows Server является сервер Наилучшим вариантом является синхронизация с несколькими серверами времени. В приведенной выше команде мы используем серверы времени, поддерживаемые NTP Pool Project.

net start w32time

w32tm /configure /reliable:yes /update

3. Если в Active Directory имеется несколько контроллеров домена, выполните в командной строке следующую команду:

w32tm /config /syncfromflags:domhier /update

4. Проверьте правильность настроек времени на сервере-эмуляторе PDC:

w32tm /query /status:

5. Проверьте правильность настройки времени на всех остальных контроллерах домена:

w32tm /query /status:

Синхронизация времени в Active Directory

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

• Контроллер корневого домена в лесу AD, которому принадлежит FSMО-роль эмулятора PDC (назовем его корневым PDC), является источником времени для всех остальных контроллеров этого домена.
• Контроллеры дочерних доменов синхронизируют время с вышестоящих по топологии AD контроллеров домена.
• Рядовые члены домена (сервера и рабочие станции) синхронизируют свое время с ближайшим к ним доступным контроллером домена, соблюдая топологию AD.

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

Синхронизация клиентов корневого PDC может осуществятся как с его внутренних часов, так и с внешнего источника. В первом случае сервер времени корневого PDC объявляет себя как «надежный» (reliable).

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

Вводим netdom query fsmo. В моем примере, роль PDC и NTP сервера, принадлежит контроллеру dc7

Настройка групповых политик

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

Чтобы установить новую групповую политику, откройте средство управления политиками на контроллере домена или на компьютере, на котором установлены средства администрирования удаленного сервера. Разверните свой домен. Щелкните правой кнопкой мыши по пункту Group Policy Objects и нажмите New. Дайте новой политике имя и нажмите ОК.

Кликните правой кнопкой по новой политике и нажмите Edit. Это запустит окно редактора политики группы.

Перейдите в Computer Configuration > Policies > Administrative Templates > System -> Windows Time Service > Time Providers. На правой панели дважды щелкните Enable Windows NTP Client. Установите опцию в положение Enabled и нажмите ОК.

Затем дважды щелкните Configure Windows NTP Client. Настройте параметры, как на рисунке ниже, добавив 0×1 в поле NtpServer, чтобы получилось , 0×1.

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

Если в вашем домене имеется большое количество политик, щелкните правой кнопкой по новой политике и перейдите в GPO Status > User Configuration Settings Disabled. Это ускорит обработку каждой политики.

Теперь нажмите правой кнопкой мыши по объекту Active Directory, к которому вы хотите применить эту политику, и нажмите Link an Existing GPO. Выделите новую политику и нажмите ОК. При необходимости повторите действия для других объектов.

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

Настройка синхронизации времени по NTP с помощью групповых политик

Служба времени Windows, несмотря на кажущуюся простоту, является одной из основ, необходимых для нормального функционирования домена Active Directory. В правильно настроенной среде AD служба времени работает следующим образом: компьютеры пользователей получают точное время от ближайшего контроллера домена, на котором они зарегистрировались. Все контроллеры домена в свою очередь получают точное время от DC с FSMO ролью «Эмулятор PDC», а контролер PDC синхронизирует свое время с неким внешним источником времени. В качестве внешнего источника времени может выступать один или несколько NTP серверов, например или NTP сервер вашего Интернет-провайдера. Также нужно отметить, что по умолчанию клиенты в домене синхронизируют время с помощью службы времени Windows (Windows Time), а не с помощью протокола NTP.

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

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

Изменить время на доменном компьютере … Как настроить NTP сервер и … Установка Active Directory Domain … PC360 — Настройка контроллера домена на …

Настройка синхронизации времени в домене с помощью групповых политик состоит из двух шагов:

1) Создание GPO для контроллера домена с ролью PDC2) Создание GPO для клиентов (опционально)

Ввод компьютера в домен Windows

Зачастую возникает необходимость ввести Linux-машину в существующий домен Windows. Например, чтобы сделать файловый сервер с помощью Samba. Сделать это очень просто, для этого вам понадобятся клиент Kerberos, Samba и Winbind.

Перед установкой желательно обновиться:

Установить всё это добро можно командой:

Также может понадобиться установить следующие библиотеки:

Либо, если вы используете Ubuntu Desktop, те же пакеты можно поставить через менеджер пакетов Synaptic.

Далее вам потребуется настроить все вышеперечисленные инструменты для работы с вашим доменом. Допустим, вы хотите войти в домен DOMAIN.COM, доменконтроллером которого является сервер dc.domain.com с IP адресом 192.168.0.1. Этот же сервер является и первичным DNS сервером домена. Кроме того допустим у вас есть второй доменконтроллер 1) , он же DNS — dc2.domain.com с IP 192.168.0.2. Ваш же компьютер будет называться smbsrv01.

Настройка DNS

Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS сервера доменконтроллер 2) и в качестве домена поиска — нужный домен.

Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf на примерно такое:

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно. Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf

Чтобы добавить еще один nameserver нужно убрать комментарий перед prepend domain-name-servers и указать ip сервера:

Для применения изменений остается перезапустить службу:

Теперь убедитесь, что вы задали нужное имя компьютера в файле /etc/hostname :

Кроме того необходимо отредактировать файл /etc/hosts так, чтобы в нём была запись с полным доменным именем компьютера и обязательно коротким именем хоста, ссылающаяся на один из внутренних IP:

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

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

Настройка синхронизации времени

Далее необходимо настроить синхронизацию времени с доменконтроллером. Если разница будет более 5 минут мы не сможем получить лист от Kerberos. Для единовременной синхронизации можно воспользоваться командой:

Если в сети существует сервер точного времени, то можно воспользоваться им или любым публичным:

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

Теперь исправьте файл /etc/ntp.conf , добавив в него информацию о вашем сервере времени:

После чего перезапустите демон ntpd :

Теперь пора настраивать непосредственно взаимодействие с доменом.

Настройка авторизации через Kerberos

Начнём с настройки авторизации в домене через протокол Kerberos. Вам потребуется изменить файл /etc/krb5.conf . В общем случае он выглядит так:

Вам, конечно, нужно изменить domain.com на ваш домен и dc и dc2 на ваши доменконтроллеры. Кстати, возможно вам понадобится написать полные имена доменконтроллеров dc.domain.com и dc2.domain.com . Поскольку у меня прописан домен поиска в DNS , то мне это делать не нужно.

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

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

Вместо username естественно стоит вписать имя существующего пользователя домена.

Если вы не получили никаких ошибок — значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Кстати, некоторые распространённые ошибки перечислены чуть ниже.

Убедиться в том, что билет получен, можно выполнив команду

Удалить все билеты (они вам вообще говоря не нужны) можно командой

Итак, будем считать, что авторизацию вы настроили, пора настроить непосредственно вход в домен, об этом после списка распространённых ошибок kinit .

Распространённые ошибки kinit

Это значит, что у вашего компьютера не синхронизировано время с доменконтроллером (см. выше).

Вы ввели неверный пароль.

Самая странная ошибка. Убедитесь, что имя realm в krb5.conf , а так же домен в команде kinit введены большими буквами:

Указанного пользователя не существует в домене.

Настройка Samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf . На данном этапе вас должны интересовать только некоторые опции из секции [global] . Ниже — пример части файла конфигурации Samba с комментариями по поводу значения важных параметров:

После того, как вы отредактируете smb.conf выполните команду

Она проверит вашу конфигурацию на ошибки и выдаст суммарную сводку о нём:

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

И в случае успеха вы увидите что-то похожее на:

Используемые параметры команды net

-U username%password : Обязательный параметр, вместо username необходимо подставить имя пользователя с правами администратора домена, и указать пароль.

-D DOMAIN : DOMAIN — собственно сам домен, домен можно и не указывать, но лучше всё же это всегда делать — хуже не будет.

-S win_domain_controller : win_domain_controller , можно не указывать, но бывают случаи когда автоматически сервер не находит контроллер домена.

createcomputer=«OU/OU/…» : В AD часто используется OU (Organizational Unit), есть в корне домена OU = Office, в нем OU = Cabinet, чтобы сразу добавить в нужный можно указать так: sudo net ads join -U username createcomputer=«Office/Cabinet».

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

Так же можно набрать команду:

Если все хорошо, можно увидеть:

Но иногда после сообщения о присоединении к домену выдаётся ошибка наподобие 3) :

Если всё прошло без ошибок, то поздравляем, вы успешно вошли в домен! Можете заглянуть в AD и убедиться в этом. Кроме того хорошо бы проверить, что вы можете видеть ресурсы в домене. Для этого установите smbclient :

Теперь можно просматривать ресурсы компьютеров домена. Но для этого нужно иметь билет kerberos, т.е. если мы их удалили, то получаем опять через kinit (см. выше). Посмотрим какие ресурсы предоставлены в сеть компьютером workstation :

Вы должны увидеть список общих ресурсов на этом компьютере.

Настройка Winbind

Если вам необходимо как-либо работать с пользователями домена, например, настраивать SMB-шары с разграничением доступа, то вам понадобится кроме самой Samba ещё и Winbind — специальный демон, служащий для связи локальной системы управления пользователями и группами Linux с сервером Active Directory. Проще говоря Winbind нужен, если вы хотите видеть пользователей домена на своём компьютере с Ubuntu.

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

Для настройки Winbind используется всё тот же файл /etc/samba/smb.conf . Добавьте в секцию [global] следующие строки:

idmap uid = 10000 — 40000

idmap gid = 10000 — 40000

в новых версиях Samba уже устарели и при проверке конфига самбы с помощью testparm будет выдваться предупреждение:

WARNING: The «idmap uid» option is deprecated

WARNING: The «idmap gid» option is deprecated

Чтобы убрать предупреждения нужно заменить эти строки на новые:

idmap config * : range = 10000-20000

idmap config * : backend = tdb

Теперь перезапустите демон Winbind и Samba в следующем порядке:

Смотрим есть ли ошибки или предупреждения, если появится:

«rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)»

Без перезагрузки можно устранить так:

Для сохранения после перезагрузки отредактировать файл /etc/security/limits.conf

После перезапуска проверьте, что Winbind установил доверительные отношения с AD командой:

А так же, что Winbind увидел пользователей и группы из AD командами 4) :

Эти две команды должны выдать список пользователей и групп из домена соответственно. Либо с префиксом DOMAIN , либо без него — в зависимости от того, какое значение вы указали параметру «winbind use default domain» в smb.conf .

Итак, Winbind работает, однако в систему он ещё не интегрирован.

Добавление Winbind в качестве источника пользователей и групп

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

Для этого измените две строчки в файле /etc/nsswitch.conf :

добавив к ним в конец winbind :

также рекомендую привести строку files в файле /etc/nsswitch.conf к виду:

Теперь проверьте, что Ubuntu запрашивает у Winbind информацию о пользователях и группах, выполнив

Первая команда должна вам вернуть всё содержимое вашего файла /etc/passwd , то есть ваших локальных пользователей, плюс пользователей домена с ID из заданного вами в smb.conf диапазона. Вторая должна сделать тоже самое для групп.

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

Авторизация в Ubuntu через пользователей домена

Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind.

Он-лайн авторизация

Для Ubuntu 10.04 и выше добавьте всего одну строку в файле /etc/pam.d/common-session , т.к. PAM и так неплохо справляется с авторизацией:

Для Ubuntu 13.10 чтобы появилось поле ручного ввода логина необходимо в любой файл из папки /etc/lightdm/lightdm.conf/ снизу добавить строку:

Для Ubuntu 9.10 и ниже придется редактировать несколько файлов (но никто не запрещает использовать этот способ и в 10.04 — он тоже работает):

И, наконец, необходимо перенести запуск Winbind при загрузке системы после всех остальных служб (по умолчанию он запускается с индексом 20). Для этого в терминале выполните следующую команду:

Что эквивалентно запуску для каждого уровня (в примере — 4) команды:

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

Настройка Active Directory Domain Services

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

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге. Также рекомендую ознакомиться с основной статье по Active Directory — Active Directory Domain Services

Подготовка окружения

Разворачивать роль AD я планирую на двух виртуальных серверах (будущих контроллерах домена) по очереди.

1. Первым делом нужно задать подходящие имена серверов, у меня это будут DC01 и DC02;
2. Далее прописать статические настройки сети (подробно этот момент я рассмотрю ниже);
3. Установите все обновления системы, особенно обновления безопасности (для КД это важно как ни для какой другой роли).

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

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

Вообще сам подход к администрированию виртуализованных контроллеров домена отличается в виду некоторых особенностей функционирования AD DS 4 5 :

Виртуальные среды представляют особую трудность для распределенных рабочих потоков, зависящих от логической схемы репликации по времени. Например, репликация AD DS использует равномерно увеличивающееся значение (которое называется USN, или номер последовательного обновления), назначенное транзакциям в каждом контроллере домена. Каждый экземпляр базы данных контроллера домена также получает идентификатор под названием InvocationID. InvocationID контроллера домена и его номер последовательного обновления вместе служат уникальным идентификатором, который связан с каждой транзакцией записи, выполняемой на каждом контроллере домена, и должны быть уникальны в пределах леса.

На этом основные шаги по подготовке окружения завершены, переходим к этапу установки.

Установка Active Directory

Установка производится через Server Manager и в ней нет ничего сложного, подробно все этапы установки вы можете увидеть ниже:

Сам процесс установки претерпел некоторые изменения 6 по сравнению с предыдущими версиями ОС:

Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.

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

Настройка Active Directory

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

Далее весь процесс будет проходить в мастере настройки.

Повышение роли сервера до контроллера домена

Этапы работы мастера подробно описаны в документации 7 . Тем не менее, пройдемся по основным шагам.

Поскольку мы разворачиваем AD с нуля, то нужно добавлять новый лес. Не забудьте надежно сохранить пароль для режима восстановления служб каталогов (DSRM). Расположение базы данных AD DS можно оставить по умолчанию (именно так и рекомендуют. Однако для разнообразия в своей тестовой среде я указал другой каталог).

После этого сервер самостоятельно перезагрузится.

Создание учетных записей администраторов домена/предприятия

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

Сразу же рекомендую настроить и иерархию организации (только не используйте русские символы!).

Настройка DNS на единственном DC в домене

Во время установки AD также была установлена роль AD DNS, поскольку других серверов DNS у меня в инфраструктуре не было. Для правильно работы сервиса необходимо изменить некоторые настройки. Для начала нужно проверить предпочитаемые серверы DNS в настройках сетевого адаптера. Необходимо использовать только один DNS-сервер с адресом 127.0.0.1. Да, именно localhost. По умолчанию он должен прописаться самостоятельно.

Убедившись в корректности настроек, открываем оснастку DNS. Правой кнопкой нажимаем на имени сервера и открываем его свойства, переходим на вкладку «Сервер пересылки». Адрес DNS-сервера, который был указан в настройках сети до установки роли AD DS, автоматически прописался в качестве единственного сервера пересылки:

Необходимо его удалить и создать новый и крайне желательно, чтобы это был сервер провайдера, но никак не публичный адрес типа общеизвестных 8.8.8.8 и 8.8.4.4. Для отказоустойчивости пропишите минимум два сервера. Не снимайте галочку для использования корневых ссылок, если нет доступных серверов пересылки. Корневые ссылки — это общеизвестный пул DNS-серверов высшего уровня.

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

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

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

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

Настройка DNS на нескольких DC в домене

Для предупреждения проблем с репликацией нужно снова изменить настройки сети и делать это необходимо на каждом контроллере домена (и на существовавших ранее тоже) и каждый раз при добавлении нового DC:

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

Настройка времени

Этот этап нужно выполнить обязательно, особенно если вы настраиваете реальное окружение в продакшене. Как вы помните, ранее я отключил синхронизацию времени через гипервизор и теперь нужно её настроить должным образом. За распространение правильного время на весь домен отвечает контроллер с ролью FSMO PDC эмулятор (Не знаете что это такая за роль? Читайте статью PDC emulator — Эмулятор первичного контроллера домена). В моем случае это конечно же первый контроллер домена, который и является носителем всех ролей FSMO изначально.

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

Назовите её как считаете нужным и как объект будет создан, нажмите правой кнопкой — Изменить. Переходим в Конфигурация компьютераПолитикиАдминистративные шаблоныСистемаСлужба времени WindowsПоставщики времени. Активируем политики Включить NTP-клиент Windows и Включить NTP-сервер Windows, заходим в свойства политики Настроить NTP-клиент Windows и выставляем тип протокола — NTP, остальные настройки не трогаем:

Дожидаемся применения политик (у меня это заняло примерно 5-8 минут, несмотря на выполнение gpupdate /force и пару перезагрузок), после чего получаем:

Вообще надо сделать так, чтобы время с внешних источников синхронизировал только PDC эмулятор, а не все контроллеры домена под ряд, а будет именно так, поскольку групповая политика применяется ко всем объектам в контейнере. Нужно её перенацелить на конкретный объект учетной записи компьютера-владельца роли PDC-эмулятор. Делается это также через групповые политики — в консоли gpmc.msc нажимаем левой кнопкой нужную политику и справа у вас появятся её настройки. В фильтрах безопасности нужно добавить учетную запись нужного контроллера домена:

Подробнее о принципе работы и настройке службы времени читайте в официальной документации 8 .

На этом настройка времени, а вместе с ней и начальная настройка Active Directory, завершена.

Контроллеры доменов

Хозяин именования доменов — это роль на уровне леса, и она используется для добавления или удаления доменов в лесу. У вас может быть только один хозяин именования доменов в лесу. Вы можете создавать и удалять домены с любого DC, но «хранителем данных» является DC, исполняющий роль хозяина именования доменов , и он разрешает или отклоняет ваши действия. Это препятствует тому, чтобы администраторы, работающие на различных DC, могли создать новый домен с тем же именем, но с другими настройками конфигурации. Остается только первый из доменов.

Способ передачи роли хозяина именования доменов другому DC зависит от того, где вы работаете: на текущем хозяине именования доменов или на DC, который вы хотите сделать хозяином именования доменов. Но в любом случае вы должны быть членом группы Domain Admins (если у вас имеется только один домен в лесу) или группы Enterprise Admins (если у вас несколько доменов в лесу).

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

1. Откройте оснастку Active Directory Domains and Trusts из меню Administrative Tools.
2. В дереве консоли щелкните правой кнопкой на Active Directory Domains and Trusts и выберите Connect to Domain Controller (Подсоединиться к контроллеру домена), чтобы открыть диалоговое окно Connect to Domain Controller (рис. 9.1).
3. Чтобы выбрать другой домен для этой задачи, щелкните на кнопке Browse и выберите этот домен.
4. Введите имя нужного DC или выберите это имя из списка контроллеров домена.
5. Щелкните на кнопке OK.
6. В дереве консоли снова щелкните правой кнопкой на Active Directory Domains and Trusts и выберите Operations Master, чтобы открыть диалоговое окно Change Operations Master (Сменить хозяина операций).

После этого произойдет передача роли хозяина именования доменов указанному компьютеру.

Если вы работаете на контроллере домена, которому хотите передать эту роль, то выполните следующие несколько шагов.

1. Откройте оснастку Active Directory Domains and Trusts из меню Administrative
2. Щелкните правой кнопкой на Active Directory Domains and Trusts и выберите Operations Master.
3. В диалоговом окне Change Operations Manager (Изменение хозяина операций) будет представлено имя текущего хозяина именования доменов , и система будет предполагать, что вы хотите передать эту роль текущему DC.

После этого произойдет передача роли хозяина именования доменов этому локальному компьютеру.

Хозяин относительных идентификаторов (RID)

Это роль на уровне домена, и в каждом домене может быть только по одному хозяину относительных идентификаторов (relative ID — RID). Хозяин RID — это «хранитель» пула уникальных идентификаторов безопасности (SID). Как уже говорилось выше в этой лекции, администраторы могут создавать новые объекты (пользователи и компьютеры) на любом DC. При создании этих новых объектов каждому из них присваивается свой идентификатор SID, который создается из нескольких частей.

• Набор идентификаторов, привязанный к домену (все объекты в этом домене имеют одинаковые доменные идентификаторы).
• Набор идентификаторов, привязанный к новому объекту, который называется относительным идентификатором (RID) и генерируется случайным образом.

Чтобы все объекты имели идентификаторы SID с уникальными RID, нужно, чтобы у вас был один источник для идентификаторов RID, и эту роль исполняет хозяин RID .

Обращение к хозяину RID происходит не при каждом создании нового объекта; вместо этого он предоставляет пул идентификаторов RID (500 RID за один раз) каждому DC Непосредственно перед тем, как DC исчерпает свой запас идентификаторов RID, он запрашивает у хозяина RID еще 500 RID. Поскольку хозяин RID не запрашивается все время, его работа не влияет на пропускную способность сети. И, конечно, из этого следует, что передача роли хозяина RID другому, более занятому DC, маловероятна. Но если у вас все же есть причина передать эту роль другому DC

в том же домене, то вы можете выполнить эту задачу с текущего хозяина RID и с DC, которому хотите передать эту роль.

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

1. Откройте оснастку Active Directory Users and Computers.
2. В дереве консоли щелкните правой кнопкой на Active Directory Users and Computers и выберите Connect to Domain Controller.
3. Введите имя нужного DC или выберите его из списка имеющихся контроллеров домена.
4. Щелкните на кнопке OK.
5. В дереве консоли снова щелкните правой кнопкой на Active Directory Users and Computers и выберите All Tasks/Operations Masters (Хозяева операций).
6. В диалоговом окне Operations Masters щелкните на вкладке RID.
7. Щелкните на кнопке Change.
8. Подтвердите изменение, щелкните на кнопке OK, чтобы убрать сообщение об успешном окончании, и щелкните на кнопке Close.

После этого произойдет передача роли хозяина RID указанному компьютеру.

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

1. Откройте Active Directory Users and Computers.
2. В дереве консоли щелкните правой кнопкой на Active Directory Users and Computers и выберите All Tasks/Operations Masters.
3. В диалоговом окне Operations Masters щелкните на вкладке RID.
4. Щелкните на кнопке Change.
5. Подтвердите изменение, щелкните на кнопке OK, чтобы убрать сообщение об успешном окончании, и щелкните на кнопке Close.

После этого произойдет передача роли хозяина RID локальному компьютеру.

Хозяин эмулятора главного контроллера домена (PDC)

Это роль на уровне домена, и в каждом домене леса может быть только один хозяин этой роли. Чтобы управлять хозяином эмулятора PDC, вы должны быть членом группы Domain Admins. Это довольно интересная роль, поскольку она предусматривает несколько различные функции в зависимости от функционального уровня домена, в котором она действует.

Пока в вашей сети не останется компьютеров с версиями Windows, которым не требуется PDC, роль PDC будет исполнять DC, который назначен как хозяин эмулятора PDC, и он будет использоваться для части сети, где еще остались резервные контроллеры домена. Если вы модернизировали не все DC NT 4 в своей сети, то оставшиеся DC NT 4 (то есть BDC ) не будут допускать изменений учетных записей и будут искать PDC для внесения этих изменений. Кроме того, BDC будет выполнять доступ к этому эмулируемому PDC, когда ему требуются изменения в SAM. Если вам потребуется установить доверительное отношение с сетью NT 4, то эта сеть NT 4 не будет «контактировать» с любым компьютером, который не является главным контроллером домена (PDC). NT 4 действует только таким образом, и вы не можете «научить» ее действовать по-новому.

Но роль эмулятора PDC требуется также для других функций, и она остается востребованной даже после того, как вы удалили все DC NT 4 из своей системы. Услуги PDC могут требоваться клиентским компьютерам. Например, Network Neighborhood и My Network используют функции «обзора» и требуют выбора «главного обозревателя» (компьютер, который отслеживает имена всех компьютеров данной сети, чтобы представить их в сетевых папках). Поскольку таким главным обозревателем является по умолчанию PDC, то поддерживать эмулятор PDC в предположении этой задачи намного проще, чем выполнять все шаги, которые требуются, чтобы изменить способ выбора этого главного обозревателя.

Даже если ваша сеть состоит исключительно из компьютеров, работающих под управлением Windows 2000/XP/2003 Server, эмулятор PDC продолжает использоваться для одной полезной функции. Кроме услуг главного обозревателя он также обеспечивает важную функцию «срочной репликации». Хотя большинство изменений Active Directory реплицируются по всему предприятию через регулярные запланированные промежутки времени, одно изменение, внесенное вами в Active Directory, помечается как «срочная доставка» (urgent delivery) и реплицируется сразу. Это изменение пароля пользователя. Как только произошло изменение любого пароля на каком-либо DC предприятия, этот DC обращается к хозяину эмулятора PDC и записывает это изменение. Следующая запланированная репликация для этого не используется.

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

Преимущества эмулятора PDC могут по-настоящему оценить администраторы, которые поддерживают пользователей в нескольких сайтах. Например, предположим, что у вас имеется пользователь, которого нет на работе, когда истек срок действия его пароля, а домен сконфигурирован таким образом, что пользователь должен выполнять вход для изменения паролей. Или, предположим, что у вас есть забывчивый пользователь, который несколько раз ввел неверный пароль, что вызвало блокировку его учетной записи. Этот пользователь находится в филиале East Overcoat, (штат Айова), а администраторы находятся в офисе Denver, штат Колорадо. Если бы не было эмулятора PDC, то после ввода нового пароля для этого пользователя (с помощью оснастки Active Directory Users and Computers) в офисе Denver вам пришлось бы ждать следующей репликации, чтобы новый пароль был передан аутентифицирующему DC в East Overcoat. Даже если прибегнуть к ручной репликации, ее выполнение через глобальную сеть может оказаться долгим процессом и ваш пользователь не сможет выполнять свою работу некоторое время. Кроме того, если имеются перемещающиеся (блуждающие) пользователи в системе, где требуется регулярная смена пароля, вы легко увидите преимущества использования эмулятора PDC.

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

Хотя очевидно, что синхронизация таймеров нужна для поддержания точности меток времени документов и записей баз данных, имеется намного более важная причина для синхронизации времени в сети Windows Server 2003 или Windows 2000, поскольку это связано с безопасностью вашего предприятия. Kerberos использует синхронизированное время как одну из контрольных точек, прежде чем разрешить пользователям доступ к сетевым ресурсам. Kerberos действует, исходя из принципа, что если время на вашем компьютере отличается от времени сетевого компьютера, к которому выполняется доступ, значит, вы «злоумышленник».

Информацию по временным службам, которые требуются на вашем предприятии, см. ниже в разделе «W32Time». Если вы осознали важность временных служб, то после передачи роли эмулятора PDC другому DC, вы сконфигурируете также этот новый DC для синхронизации времени с каким-либо внешним уполномоченным источником времени.

Чтобы передать роль эмулятора PDC, когда вы работаете на компьютере, который является текущим обладателем этой роли, выполните следующие шаги.

1. Откройте оснастку Active Directory Users and Computers.
2. В дереве консоли щелкните правой кнопкой на Active Directory Users and Computers и выберите Connect to Domain Controller.
3. Введите имя нужного DC или выберите его из списка имеющихся контроллеров домена.
4. Щелкните на кнопке OK.
5. В дереве консоли снова щелкните правой кнопкой на Active Directory Users and Computers и выберите All Tasks/Operations Masters.
6. В диалоговом окне Operations Masters щелкните на вкладке PDC.
7. Щелкните на кнопке Change.
8. Подтвердите изменение, щелкните на кнопке OK, чтобы убрать сообщение об успешном окончании, и щелкните на кнопке Close.

После этого произойдет передача роли эмулятора PDC указанному компьютеру.

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

1. Откройте Active Directory Users and Computers.
2. В дереве консоли щелкните правой кнопкой на Active Directory Users and Computers и выберите All Tasks/Operations Masters.
3. В диалоговом окне Operations Masters щелкните на вкладке PDC.
4. Щелкните на кнопке Change.
5. Подтвердите изменение, щелкните на кнопке OK, чтобы убрать сообщение об успешном окончании, и щелкните на кнопке Close.

После этого произойдет передача роли эмулятора PDC локальному компьютеру.