Active Directory Ubuntu в домене Windows AD

[Active Directory] Ubuntu в домене Windows AD

Некоторое время назад на работе достался мне для работы ноутбук HP ProBook 6460b. Ну и пришла в голову идея поставить на него вместо надоевшей Windows 7 Pro давно понравившуюся мне Ubuntu 14.04 Trusty LTS. Выбор операционной системы связан с тем, что Ubuntu я использую на домашнем ноутбуке и мне захотелось иметь такую же систему на рабочем компьютере. Потому, что постоянное переключение между ОСями дома и на работе быстро надоело мне и я решился на установку Ubuntu на рабочем ноуте.

Начну по порядку#

Процесс установки Убунты на ноутбук не буду пересказывать потому, что не вижу в этом смысла из-за большого количества таких мануалов на просторах интернета. Скажу только то, что устанавливал с флешки, а образ на флешку писал на рабочем ноутбуке под Windows 7 Pro с помощью программы Rufus. Хватит про установку, перейдем к процессу введения в домен.
При вводе в домен Windows я пользовался стандартной инструкцией по вводу в домен. В процессе ввода в домен возникали проблемы самого разного характера (в основном связанные с моей невнимательностью и легкой кривизной рук 🙂 ). Да инструкция на русском языке есть и она довольно хороша, но я все же пользовался не только этой инструкцией, но и другими подсказками с прочих сайтов и форумов. Поэтому я решил собрать из всех одну свою.

Первое что необходимо сделать это — правильно и вполне логично! — обновиться:

Далее нас потребуется установить клиенты Kerberos , Samba и Winbind для нормальной и адекватной работы в домене Windows . Сделать это можно одной командой:

Лично я пробовал два варианта установки: первый — как указано выше — установка всех необходимых пакетов одной строкой, и второй — установка каждого паке в отдельности. Честно признаюсь, что меня больше устроил и больше понравился вариант отдельной установки каждого пакета. Поясню это тем, что при комплексной установке у меня начальная настройка пакета Kerberos не происходила, и я решил (точнее не решил, а мне пришлось из-за кривизны рук и невнимательности переустанавливать полностью Ubuntu и соответственно все необходимые пакеты) ставить все пакеты по отдельности в вышеуказанном порядке. Это дало свои плоды. На этапе установки пакеты Kerberos произошла его полная настройка где указывались все необходимые параметры для работы в домене (собственно сам домен, необходимые для авторизации DC , рабочие группы или зоны). Далее я поставил Самбу и Винбинд с которыми каких-либо заморочек не было. Так же я установил указанные желательными библиотеки libpam-krb5 , libpam-winbind и libnss-winbind . Их я устанавливал одной командой, т.к. они не требуют никаких ручных настроек и просто желательно их присутствие в системе.

Для простоты и дальнейшей ясности процесса будем считать нашим доменом по умолчанию DOMAIN.RU , доменконтроллером которого будет first.domain.ru с ip-адресом 192.168.1.2 . Он же будет нашим первичным DNS сервером домена. Коме того представим в нашем домене еще один доменконтроллер second.domain.ru с ip-адресом 192.168.1.3 . Ну и компьютер наш будет называться work-ubuntu .

Настройка DNS#

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

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно. Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head . Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf . Если IP-адрес динамический и присваивается DHCP сервером то после перезагрузки resolv.conf может формироваться “неправильный” resolv.conf , например присутствует только один nameserver 192.168.1.1 и не указаны domain и search . Нужно отредактировать /etc/dhcp/dhclient.conf . Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name , и вписать свой домен:

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

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

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

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

Не обязательно конечно, но как говорится в инструкции “желательно” при внесении каких-либо изменений делать перезагрузку. Лично я так и делал.

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

Тут собственно говоря ничего сложного! Я просто единожды выполнил команду:

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

Собственно переходим к самому основному: настройка авторизации через Kerberos

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

Вы естественно указываете вместо DOMAIN.RU и first свои домен и контроллер домена. Особое внимание обращаю на соблюдение регистра — все что написано в верхнем регистре пишется в верхнем регистре!

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

Вместо vasya и DOMAIN.RU вы так же указываете свои имя пользователя и домен. Команда так же регистрозависима! Если вы после выполнения данной команды получаете завпрос на ввод пароля от указанного пользователя и не получаете никаких ошибок, значит у вас все прекрасно. В противном случае еще раз перепроверьте все измененные вами файлы на правильность (внимательно изменяйте все ваши файлы).

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

Будем считать, что авторизация вы настроили и билет получен. Теперь настроим вход в домен.

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

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

Теперь необходимо проверить внесенные изменения на правильность (точнее себя на внимательность и руки на кривость 🙂 ) следующей командой:

В случае правильного изменения файла /etc/samba/smb.conf вы увидите примерно следующее:

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

В случае успешного входа вы увидите на экране примерно следующее:

Я снова не стану описывать все возможные ошибки, потому что и ежу понятно, что если появились ошибки значит ты сделал что-то не так. Поэтому скажу только одно: RTFM friend!

На данном этапе вы можете установить себе smbclient :

и проверить доступность ресурсов, хотя бы, на доменконтроллере:

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

Переходим к настройке Winbin#

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

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

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

Строки с параметрами idmap config указаны с новыми параметрами не характерными для старых версий Samba, поэтому на данном этапе будьте внимательнее. Старый формат этих строк можно посмотреть в официальной инструкции по вводу в домен.

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

Смотрим есть ли ошибки или предупреждения, если появится: rlimit_max: rlimit_max (1024) below minimum Windows limit (16384) , то отредактировать файл /etc/security/limits.conf :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для он-лайн авторизации я лично подредактировал парочку файлов. Первый файл, который я редактировал это /etc/pam.d/common-session и добавил в него всего одну строчку:

Вторым был файлик /etc/lightdm/user.conf . В него необходимо добавить строчку в самый конец файла:

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

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

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

Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf со следующим содержанием:

Файл /etc/pam.d/gnome-screensaver в таком случае принимает вид:

А также изменяется файл /etc/pam.d/common-auth :

На этом вроде бы все 🙂

Вместо заключения#

После всех проделанных операций наша машина на Ubuntu стала полноценным членом домена Windows и теперь с ней могу работать пользователи AD .

Было мягко говоря не легко. Тяжело было собрать информацию, относящуюся именно к моей Ubuntu 14.04 Trusty LTS .

Роли FSMO службы Active Directory

Служба каталогов Microsoft Windows Active Directory — центральное хранилище для всех объектов предприятия и соответствующих им атрибутов. Эта база данных имеет иерархическую структуру, она способна поддерживать несколько ведущих узлов и вмещать миллионы объектов. Поддержка нескольких ведущих узлов позволяет изменять базу данных с любого контроллера домена в пределах предприятия вне зависимости от состояния его подключения к сети.

Модель поддержки нескольких ведущих узлов в Windows 2000

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

Обработка некоторых типов изменений в Windows 2000 осуществляется методами, которые препятствуют конфликтам обновлений Active Directory.

Модель поддержки одного ведущего узла в Windows 2000

Чтобы предотвратить возникновение конфликтующих обновлений, Active Directory выполняет обновления определенных объектов, используя модель с поддержкой одного ведущего узла. Согласно этой модели только один контроллер домена во всем каталоге имеет право вносить обновления. Данный процесс подобен роли, которая присваивалась основному контроллеру домена (PDC) в ранних версиях Windows (например, в Microsoft Windows NT 3.51 и 4.0), по которой PDC отвечает за обработку всех обновлений в определенном домене.

Windows 2000 Active Directory расширяет модель с одним ведущим узлом, которая использовалась в ранних версиях Windows, для включения поддержки нескольких ролей и возможности передавать роли другим контроллерам в рамках предприятия. Поскольку роль Active Directory не имеет жесткой привязки к одному контроллеру домена, ее называют ролью FSMO (Flexible Single Master Operation, или операции одиночного гибкого хозяина). В Windows 2000 существует пять ролей FSMO:

• хозяин схемы
• хозяин именования доменов
• хозяин RID
• эмулятор PDC
• демон инфраструктуры

Роль FSMO «Хозяин схемы»

Контроллер домена, выполняющий роль хозяина схемы, отвечает за обновление схемы каталога (т. е. контекста присвоения имен схемы или LDAP://cn=schema,cn=configuration,dc=<domain>). Вносить изменения в схему каталога может только этот контроллер домена. После обновления схемы она реплицируется с хозяина схемы на другие контроллеры домена в каталоге. В каталоге может быть только один хозяин схемы.

Роль FSMO «Хозяин именования доменов»

Контроллер домена, выполняющий роль хозяина именования доменов, отвечает за изменение пространства доменных имен каталога в рамках леса (т. е. контекста именования «разделыконфигурация» или LDAP://CN=Partitions, CN=configuration, DC=<domain>). Только этот контроллер имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

Роль FSMO «Хозяин RID»

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

Когда контроллер домена создает основной объект-участник безопасности (например, пользователя или группу), он назначает ему идентификатор защиты (SID). Этот идентификатор состоит из SID домена (единый для всех идентификаторов защиты, созданных в одном домене) и относительного идентификатора (RID) (уникальный для каждого участника безопасности, созданного в одном домене).

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

Роль FSMO «Эмулятор PDC»

Эмулятор основного контроллера домена необходим для синхронизации времени в рамках предприятия. В состав Windows 2000 входит служба времени W32Time (время Windows), используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows 2000 в рамках одного предприятия используют общее время. Для обеспечения корректной синхронизации времени служба времени Windows должна использовать иерархическую структуру отношений, которая контролирует полномочия и не допускает возникновения «циклов» в управлении.

Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

В домене Windows 2000 обладатель роли эмулятора PDC сохраняет следующие функции: Произведенные другими контроллерами домена изменения паролей в первую очередь реплицируются на эмулятор PDC.

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

Случаи блокировки учетных записей обрабатывается на эмуляторе PDC.

Эмулятор PDC выполняет все функции серверного эмулятора PDC для Microsoft Windows NT 4.0, предыдущих версий эмуляторов на основе Windows NT 4.0 или клиентов более ранних версий.

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

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

Случаи блокировки учетных записей обрабатывается на эмуляторе PDC.

Эмулятор PDC выполняет все функции серверного эмулятора PDC для Microsoft Windows NT 4.0, предыдущих версий эмуляторов на основе Windows NT 4.0 или клиентов более ранних версий.

Нет необходимости использовать данную часть роли эмулятора PDC, если все рабочие станции, серверы и контроллеры домена под управлением Windows NT 4.0 или более ранних версий обновляются до уровня Windows 2000. Эмулятор PDC выполняет все те же функции, что и в среде Windows 2000.

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

После обновления до уровня Windows 2000 резервных контроллеров (BDC) в доменах нижнего уровня эмулятор PDC перестает получать запросы на репликацию с нижнего уровня.

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

Роль FSMO «Инфраструктура»

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

Примечание.

Роль хозяина инфраструктуры (IM) не должна выполняться контроллером домена, который является сервером глобального каталога. В противном случае хозяин инфраструктуры не будет обновлять сведения об объектах, так как он не содержит ссылок на объекты, которых не хранит. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу. В результате междоменные объектные ссылки в этом домене обновляться не будут, а в журнале событий данного контроллера домена появится соответствующее предупреждение.

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

Заметки IT Менеджера

Затем следует передать роль PDC Emulator на новый контроллер домена.

На «новом» PDC Emulator запустить

w32tm /config /manualpeerlist:PEERS /syncfromflags:manual /reliable:yes /update

где PEERS — сервера — источники точного времени, причем значение это или DNS имя, или IP адрес. Если источников больше одного, то между ними необходимо ввести пробел, а сам список должен быть в кавычках: «time.domain.com time1.domain.com».

Share this:

Понравилось это:

Похожее

22 комментария »

Спасиб. Очень помог.

комментарий от kaizer — 11.03.2010 @ 07:02 | Ответить

[…] с внешним источником. Я как-то уже делал инструкцию Настройка точного времени в домене Windows 2003 / 2008 / 2008 R2, правда тогда еще для 2003 сервера. Вчера потратил весь […]

Спасибо коллега. Очень помог.

комментарий от NoRLesT — 14.07.2010 @ 00:06 | Ответить

благодарствую. тоже помогло

комментарий от shwarz13 — 22.09.2010 @ 19:28 | Ответить

Спасибо, помогает!
Однако: Если ваш компьютер является контроллером домена то необходимо внести соответствующие изменения в Управление групповой политикой> Default Domain Controllers Policy > Конфигурация компьютера > Административные шаблоны > Cистема > Служба времени Windows > Поставщики времени

Если ваш локальный NTP-сервер работает в условиях рабочей группы, то gpedit.msc
Конфигурация компьютера > Административные шаблоны > Cистема > Служба времени Windows > Поставщики времени

В групповой политике (локальной или доменной) Конфиг. комп — Админ шаблоны — Система — Служба времени Windows — Поставщики времени, значение параметра Включить NTP-клиент Windows, установите «Не задано»
а то не работает нормально

«Эта утилита входит в комплект Support Tools для Windows 2003 Server. К сожалению, на Windows 2008 R2 она не работает.»

комментарий от Volodya — 22.07.2011 @ 18:38 | Ответить

комментарий от itpadla — 22.12.2015 @ 11:19 | Ответить

у меня в компании 2 Домена Windows Server 2003 Service Pack 2

на втором контролере хочу поправить время так как сервер спешит на 3 минуты
1. задал параметры в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParametersNtpServer
ntp.time.in.ua,0x1
2. HKLMSYSTEMCurrentControlSetServicesW32TimeConfigAnnounceFlags
тут должна быть 5

3. Перезапускаем сервис времени:
net stop w32time && net start w32time
4. Теперь перезапускаю синхронизацию:
w32tm /resync /rediscover

5. на этом этапе случилась беда… запускаю
w32tm /unregister

пишет Acces Denied

перезапуск Сервера не помог

запускаю службы служба Windows time пропала ….

комментарий от Stepan — 14.03.2018 @ 11:46 | Ответить

Мне сложно вам помочь, т.к. у меня уже нет ни одного сервера с Windows Server 2003. Вы пробовали сделать w32tm /register ?
Тогда когда писал пост, проверял все на себе

комментарий от itpadla — 14.03.2018 @ 11:51 | Ответить

да написало такую ошибку The following error occurred: Access is denied

комментарий от Stepan — 14.03.2018 @ 11:55 | Ответить

Вы пробовали перезагрузить, а потом ввести w32tm /unregister и снова w32tm /register?

комментарий от itpadla — 14.03.2018 @ 11:56 | Ответить

а что это такое PDC Emulator ?

комментарий от Stepan — 14.03.2018 @ 11:56 | Ответить

Это FSMO роль сервера в домене AD.

ДОМЕН ACTIVE DIRECTORY
Сервер с ролью PDC Emulator служит великой задаче обеспечения совместимости с предыдущими версиями Windows. Но не только, и, в последнее время, не столько. Для начала неплохо бы вспомнить, чем занимался PDC в Windows NT 4.0 и 3.51:

Обработка операции “смена пароля” для пользователей и компьютеров

Репликация обновлений на BDC (Backup Domain Controller)

Обозреватель сети (Domain Master Browser)

В смешанной среде, в которой встречаются клиенты Windows NT4.0, Windows 95 и Windows 98 (без установленного клиента Active Directory) и контроллеры домена pre-Windows2000, всем вышеперечисленным занимается как раз PDC Emulator. Только он и только для них.

Когда же все клиенты обновляются до Windows 2000 и выше (либо когда на Windows NT4/95/98 ставится клиент Active Directory), наступает счастье:
Клиенты меняют пароли при помощи первого попавшегося контроллера домена

Запросы на репликацию от BDC перестают отнимать время в силу полного своего отсутствия
Клиенты ищут сетевые ресурсы в AD, и не зависят более от обозревателя сети (эх, как всё хорошо в technet)
После перехода всей инфраструктуры на Windows 2000 и старше, контроллер домена с ролью PDC Emulator причиняет пользу так:
Пароль, измененный любым другим контроллером домена, отправляется на PDC Emulator высокоприоритетной репликацией
Если аутентификация на любом другом контроллере домена не была успешной с признаком “неверный пароль”, запрос повторяется на эмуляторе PDC. Понятно, что, в случае только что произошедшей смены пароля, уж этот-то запрос будет успешным
При успешной аутентификации учетной записи сразу после неудачной попытки, эмулятор PDC о ней уведомляется и сбрасывает счетчик неудачных попыток в ноль. Сущий позитив для пользователя, часто забывающего свой пароль
Здесь важно заметить, что, даже в случае недоступности эмулятора PDC, информация об изменении пароля всё равно расползется по домену. Да, возможны некоторые сложности, пока идет репликация, но, в принципе, ничего страшного.
WELL KNOWN SECURITY PRINCIPALS
В Active Directory есть такая замечательная штука, как Well Known Security Principals. Это всяческие Local Service, Network Service, Digest Authentication, и т.п. Несложно догадаться, что управление ими всеми (начиная с Windows 2003) осуществляется как раз контроллером домена с ролью PDC Emulator. Конкретно, эмулятор PDC после апгрейда (или переноса данной роли) на более новую версию Windows обновляет содержимое контейнера “CN=WellKnown Security Principals,CN=Configuration,DC=”. В этот же момент происходит создание недостающих well-known и built-in групп, а также обновление членства в них.
ADMINSDHOLDER
Следующая нужная фича – AdminSDHolder, владелец административных дескрипторов безопасности. AdminSDHolder защищает административные группы от изменений. Если дескриптор безопасности в какой-либо административной учетной записи не соответствует представлениям AdminSDHolder’а, этот дескриптор будет обновлен в соответствии с его (AdminSDHolder’а) понятиями. К примеру, если исключить well-known пользователя Administrator из группы BuiltinAdministrators, AdminSDHolder вернет его на место.
Да, AdminSDHolder, как понятно, выполняется именно на контроллере домена с ролью эмулятора PDC.
DNS
Только для PDC Emulator в DNS регистрируется SRV-запись вида _ldap._tcp.pdc._msdcs.DnsDomainName, она позволяет клиентам быстренько найти сервер эмуляции PDC.
DFS
Изменения, вносимые в пространство имен Distributed File System (DFS), вносятся на контроллере домена с ролью PDC Emulator. Корневые серверы DFS периодически запрашивают с эмулятора PDC обновленные метаданные, сохраняя их у себя в памяти. Очевидно, что недоступность эмулятора PDC влечет за собой неверную работу DFS.
ГРУППОВЫЕ ПОЛИТИКИ
Редактор групповых политик по умолчанию соединяется с сервером PDC Emulator, и изменения политик происходят на нем же. Если PDC Emulator недоступен, тогда редактор ГП не постесняется спросить у администратора, к какому контроллеру домена подключиться.
ВРЕМЯ
Да, по умолчанию именно сервер PDC Emulator является для клиентов сервером точного времени в домене. А эмулятор PDC корневого домена в лесу является по умолчанию сервером точного времени для эмуляторов PDC в дочерних доменах.

комментарий от itpadla — 14.03.2018 @ 12:00 | Ответить

В любом случае, я вам настоятельно не рекомендую в 2018 году использовать серверную ОС старше чем 2012R2 и держать домен на ней.

комментарий от itpadla — 14.03.2018 @ 12:02 | Ответить

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

потом запустил w32tm /unregister и снова w32tm /register : и на первой же команде Acces Denied

я бы с радостью поставил новый контроллер Windows Server 2012 но надо как то настроить я не знаю как )

комментарий от Stepan — 14.03.2018 @ 12:23 | Ответить

net stop w32time делаете перед w32tm /unregister?

комментарий от itpadla — 14.03.2018 @ 12:33 | Ответить

ок, такой вопрос

первый DC у меня Windows 2003 Service Pack 2

второй DC у меня Windows 2003 Service Pack 2 живет на Hyper-V вот и хочу с него начать upgrade ОС )

комментарий от Stepan — 14.03.2018 @ 12:24 | Ответить

Вам не нужно делать upgrade. Да и не выйдет
Вам нужно установить с нуля парочку Windows Server 2012R2, обновить, ввести в домен, повысить до контроллера домена, перенести на них все нужные системные сервисы (DNS, DHCP и т.д.) и FSMO, а затем корректно понизить уровень 2003 до обычных серверов, а затем и из домена вовсе. Убедиться, что все ок, повысить уровень домена и леса до 2012R2. Как-то так.

комментарий от itpadla — 14.03.2018 @ 12:37 | Ответить

я хотел сказать установить новый Win 2012 (обновить с 2003 до 2008 R2 даже не получится это я понимаю )
так вот по процедуре…
1. установить новый сервер win 2012
2. добавить в домен
2.повысить его до уровня AD slave ( master у меня остается Win 2003 (пока) это как сделать ??

комментарий от Stepan — 14.03.2018 @ 12:47

Windows Server 2012R2. R2 — важно, просто 2012 тоже уже «старенький». Ну или сразу 2016 ставить.

У AD нет уровня slave, как и у контроллеров домена. Вам нужно почитать побольше по AD, а еще лучше послушать курсы от MS по этому поводу.

PDC emulator — Эмулятор первичного контроллера домена

FSMO-роль эмулятор первичного контроллера домена (PDC emulator) является второй ролью (из трех) уровня домена. То есть в одном домене должен быть один PDC emulator , но во всем лесу AD их может быть несколько, в зависимости от количества доменов.

Основная статья по Active Directory — Active Directory Domain Services. Читайте также другие статьи по ролям хозяев операций — FSMO — Fexible Single Master Operations.

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике Windows Server на моем блоге.

PDC emulator — Эмулятор первичного контроллера домена

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

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

Роль эмулятора PDC необходима прежде всего для обеспечения совместимости с версиями Windows ниже 2000. В смешанной среде с клиентами Windows NT, 95, 98 PDC emulator выполняет следующие задачи 1 :

1. Участвует в процессе смены паролей учетных записей пользователей и компьютеров;
2. Реплицирует обновления на резервные контроллеры домена (backup domain controllers);
3. Выполняет задачи хозяина обозревателя сети домена (Domain Master Browser).

Для доменов Windows NT 3.51, 4 эмулятор первичного контроллера домена выполнял очень важную функцию 2 и при его отказе весь домен фактически переходил в режим «только чтение» 3 :

• Пользователи не смогли бы изменить пароли (выдавалась бы ошибка «Unable to change password on this account. Please contact your system administrator»);
• При создании учетной записи вы получили бы ошибку («could not find domain controller for this domain»);
• На резервных контроллерах домена были бы ошибки репликации (связано с тем, что резервные контроллеры домена реплицировали изменения только с PDC. Чтобы можно было вносить изменения в базу BDC, его необходимо сделать первичным контроллером домена).

С развитием технологии упор делался на взаимозаменяемость и равноправность всех контроллеров домена и таким образом домен Windows 2003 уже представлял из себя совершенно другую структуру, основу которой составляла репликация с несколькими хозяевами. Хоть и «вторичные» (некоторое подобие BDC) контроллеры домена остались, первичные контроллеры как таковые перестали существовать 4 .

Современное назначение

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

1) Репликация паролей идет на PDC emulator в приоритетном режиме. То есть, если пользователь изменил пароль (а сделать это он может на любом DC), то контроллер домена первым делом обращается к эмулятору PDC, чтобы сообщить о факте смены пароля. В свою очередь другие DC, если авторизация с измененным паролем идет через них, не отказывают пользователю, а обращаются к эмулятору первичного контроллера домена, чтобы просмотреть возможные изменения и получив их, авторизуют пользователя с новым паролем.

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

То же касается и блокировок учетных записей — первым делом они реплицируются на эмулятор PDC 5 .

2) Для предупреждения конфликтов изменения групповых политик, все изменения GPO в реальности происходят именно на эмуляторе PDC и не важно где конкретно вы работаете с оснасткой;

3) В Windows Server 2003 включены некоторые дополнительные объекты безопасности по умолчанию. При обновлении инфраструктуры с версии Windows Server 2000 сам процесс обновления вы должны начать непосредственно с эмулятора PDC, чтобы эти группы и учетные записи первым делом появились на нем и уже потом реплицировались на другие контроллеры. Сами объекты хранятся в контейнере CN=WellKnown Security Principals,CN=Configuration,DC=<YourDomain>;

4) Механизм SDProp (Security Descriptor propagator) запускается именно на PDC эмуляторе. Этот механизм «приводит в порядок» списки контроля доступа (ACL’s) у объектов Active Directory. У критически важных объектов безопасности домена (эти объекты имеют выставленное в 1 значение атрибута adminCount) образцовые ACL хранятся в специальном контейнере, который называется AdminSDHolder 6 7 .

Кстати, вот полный список наиболее важных объектов безопасности для только что созданного домена:

Разумеется учетная запись bissquit создана мной вручную, у вас она будет отличаться;

5) Во время установки первого контроллера домена служба NetLogon создает SRV-запись DNS _ldap._tcp.pdc._msdcs.DnsDomainName. Эта запись позволяет клиентам обнаруживать эмулятор PDC. Только владелец этой роли может изменять эту запись;

6) На эмуляторе первичного контроллера домена выполняются изменения пространства имен DFS (Distributed File System). Если PDC emulator не будет найден, то DFS будет работать некорректно 8 ;

7) Процесс повышения функционального уровня домена или леса выполняется на эмуляторе PDC 9 .

8) Пожалуй одной из самых важных функций является распространение времени по всему домену 10 . Подробнее про настройку времени в домене вы можете прочитать в моей статье Настройка Active Directory Domain Services.

Лучшие практики

Многие лучшие практики администрирования эмулятора первичного домена соответствуют другим ролям хозяев операций:

1. Располагайте PDC emulator и RID master на одном контроллере домена 11;
2. Обязательно настройте PDC эмулятор на синхронизацию времени с корректного внешнего источника времени 12;
3. Если вы используете виртуализованные контроллеры домена, позаботьтесь о том, чтобы гостевые ОС виртуальных машин не синхронизировали время с хоста виртуализации, а делали это с контроллеров домена, а те, в свою очередь, с PDC эмулятора;
4. Не испытывайте судьбу и не вносите изменения в механизм SDProp.

Администрирование

Специальная оснастка для управления работой эмулятора PDC отсутствует.

Изменить владельца роли вы можете с помощью оснастки Active Directory — Пользователи и компьютеры. Для этого:

1. Открываем оснастку на DC01, правой кнопкой нажимаем на Active Directory — Пользователи и компьютеры и выбираем Сменить контроллер домена Active Directory;
2. Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
3. Снова правой кнопкой на Active Directory — Пользователи и компьютеры, но уже выбираем Хозяин операций…;
4. Нажимаем кнопку Изменить….

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.