Плохо документированные особенности настройки парольных политик домена через Group Policy

Работая недавно у крупного клиента по внедрению SCOM/SCCM, столкнулся на практике с одной плохо документированной особенностью Active Directory,  а именно настройкой парольных политик в домене.

---

Проблема

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

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

Давайте теперь рассмотрим конфигурацию домена заказчика. Домен Windows Server 2003. Для простоты я оставлю только имеющие к нам отношение Group Policy:

• встроенная политика Default Domain Policy привязана к домену;
• встроенная политика Default Domain Controllers Policy привязана к контейнеру Domain Controllers.

Пока все стандартно.

Дальше начинается немного нестандартная конфигурация: контейнер Domain Controllers настроен на блокировку наследования Group Policy. Видимо, чтобы компенсировать блокировку, политика Default Domain Policy привязана также и к контейнеру Domain Controllers. Политика Default Domain Controllers Policy имеет более высокий приоритет, чем политика Default Domain Policy для контейнера Domain Controllers.

Теперь значения блокировок паролей:

• Default Domain Policy: блокировка отсутствует;
• Default Domain Controllers Policy: блокировка после пяти неудачных логонов.

Ну и теперь вопрос к специалистам: какая же в итоге политика блокировок применяется к доменным учетным записям?

Ответ первый, навскидку (оказывающийся неправильным):

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

Ответ второй, после некоторого раздумья (и тоже неверный!):

Действует Default Domain Policy c отсутствием блокировок.

Ответ третий, парадоксальный (и верный!):

Не действует ни одна доменная политика!

Вот тут уже становится интересно. Особенно, если учесть, что контроллеров домена у заказчика десять и блокировка учетных записей срабатывает после пяти неудачных логонов, несмотря на практически любые (!!) манипуляции с любыми локальными и доменными Group Policy. Чудеса? Не-а, на самом  деле будете дико удивлены, что такое поведение, оказывается, by design!

---

Теория

Тезис 1. Где в домене хранятся настройки блокировок паролей пользователей?

Оказывается, что параметры парольных политик и политик блокировок учетных записей есть ни что иное, как атрибуты самого объекта "домен". Открыв в консоли ADSI Editor или Active Directory Users and Computers свойства домена, мы можем найти эти самые атрибуты. Ни у каких других объектов в домене Windows Server 2003 подобных атрибутов больше нет (тут немного за скобками полезно будет вспомнить мою прежнюю статью про Fine Grained Password Policies, в ней эти атрибуты, а также и новые возможности Windows Server 2008 рассмотрены более детально). Окно свойств домена приведено ниже.

Теперь более-менее понятно: чтобы изменить блокировки учетных записей в домене мы должны изменить эти атрибуты. Из данного вывода вытекает

Тезис 2. А кто же, собственно, может менять эти атрибуты?

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

Тезис 3. Откуда PDC Emulator берет значения, чтобы прописать их в качестве атрибутов контейнера "домен"?

Либо из доменной политики, либо из локальной политики. Но тут у Group Policy начинается самое интересное и слабодокументированное поведение. Оказывается, что PDC Emulator берет значения атрибутов настроек пароля и блокировок ТОЛЬКО из Group Policy Objects (GPO), прилинкованных на УРОВНЕ ДОМЕНА. Любые GPO, прилинкованные ниже, попросту игнорируются (точнее две их части под названием Account Policies и Security Options).

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

---

Практика

Возвращаемся теперь к заказчику и начинаем повторный анализ настроек с высот нового знания :-)

1. Оба GPO, привязанные к контейнеру Domain Controllers, благополучно игнорируются в части политик пароля и блокировок (см. Тезис 3 выше).

2. Политика Default Domain Policy примениться не может, ибо на контейнере Domain Controllers стоит блокировка наследования политик.

3. Все контроллеры домена, кроме одного единственного, в локальных политиках имеют абсолютно чистые настройки этих самых политик (Not defined).

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

В итоге я просто-напросто сбросил локальную политику на PDC Emulator, и все мгновенно заработало как и хотелось заказчику: никаких больше блокировок. Вопрос корректности настроек групповых политик в целом мы оставили на потом. В общем, обладая определенными знаниями, у меня на все ушло 5 минут; заказчик потратил на поиск проблемы времени вагон, так и не решив ее.

---

Выводы

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

Обратите также внимание на статью KB259576: Group Policy application rules for domain controllers.В ней дается дополнительная информация, как применяются рассмотренные нами политики на контроллерах домена.