Плохо документированные особенности настройки парольных политик домена через 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.

image

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

  • 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 рассмотрены более детально). Окно свойств домена приведено ниже.

image

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

Тезис 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.В ней дается дополнительная информация, как применяются рассмотренные нами политики на контроллерах домена.

3 комментария:

  1. Действительно интересная ситуация. Но не пойму одного-кому нужен был такой геморрой с политиками?Если нужно было отменить наследование на уровне контроллеров домена,но сохранить Default Domain Policy, не легче было просто поставить одну галочку "не перекрывать" на уровне домена???

    ОтветитьУдалить
  2. Думается месные админы сразу до этого додумались, но ведь и правда интересно было разобраться почему же когда не действует ни одна политика, все же чем-то регламентируется настройка блокировки.
    Алексей, низкий поклон! Учтем в работе :)

    ОтветитьУдалить
  3. Сегодня столкнулся с это траблой!
    Как вариант выключил блокирование OU DC. Хочу применять low security password policy на весь домен. Теперь вопрос:

    С учетом этого:
    The following settings are applied to Windows Server 2003-based domain controllers only when the group policy is linked to the domain container. (The settings are located in Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options.)

    Accounts: Administrator account status
    Accounts: Guest account status
    Accounts: Rename administrator account
    Accounts: Rename guest account
    Network security: Force logoff when logon hours expire

    Можно понимать что, все отличное применяться к DC не будет?

    ОтветитьУдалить