1. проблема
2. теорія
3. Теза 2. А хто ж, власне, може змінювати ці атрибути?
4. Теза 3. Звідки PDC Emulator бере значення, щоб прописати їх в якості атрибутів контейнера "домен"?
5. Практика
6. висновки

Працюючи недавно у великого клієнта по впровадженню 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 У ній дається додаткова інформація, як застосовуються розглянуті нами політики на контролерах домену.