Настройка детальных параметров пароля в Windows Server 2008, часть 2

Эта последняя из двух статей содержит некоторую полезную справочную информацию о детальных настройках пароля в Windows Server 2008. Теперь мы рассмотрим новые атрибуты групп и пользовательских объектов, объекты настроек пароля ( PSO ), результирующий PSO, рекомендации по дизайну, Shadow Groups ( SG ) и многое другое…

Зачем мне это делать?

Теперь мы увидели, как создавать PSO и назначать их пользователям и/или группам, но зачем нам несколько политик блокировки паролей и учетных записей, спросите вы? Что ж, для этого есть много причин — одной из них может быть сценарий «хостинга», когда несколько компаний присутствуют в одном домене AD, другой более распространенной причиной является то, что нам нужны более строгие настройки для применения к определенной группе людей с привилегированными учетными записями ( например, администраторы домена, персонал службы поддержки и т. д.).

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

Кто что может поразить?

Рискуя повториться, я должен сказать это, чтобы убедиться, что это на 100% ясно. Новая функциональность «политики множественных паролей» в Windows Server 2008 (кодовое имя «Longhorn») позволяет нам устанавливать индивидуальные политики паролей и политики блокировки учетных записей для пользовательских объектов, объектов interOrgPerson и глобальных групп безопасности.

Детализированные политики паролей нельзя применять напрямую к OU — теперь мы должны применять эти политики вместо этого к группам. Не любая группа — это должны быть группы безопасности, настроенные на глобальную область. Можно установить параметры/атрибуты для других групп; однако это не будет работать должным образом (настройки игнорируются).

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

По умолчанию только члены группы «Администраторы домена» могут устанавливать, создавать и удалять подробные политики паролей, более известные как объекты настройки паролей ( PSO ). Однако при необходимости эти разрешения можно делегировать и настроить, но настройки по умолчанию должны подойти для большинства сред. Чтобы быть более конкретным, только члены группы «Администраторы домена» имеют необходимые разрешения «Создать дочерний элемент» и «Удалить дочерний элемент» для объекта «Контейнер параметров пароля» ( PSC ).

Чтобы применить PSO к пользователю или групповому объекту, у вас должны быть разрешения «Запись» для объекта PSO — по умолчанию это разрешение есть только у членов группы «Администраторы домена». «Забавно» то, что вам не нужно иметь разрешения на сам объект пользователя или группы, так как они устанавливаются фоновым процессом каталога.

Взгляните на эти атрибуты

Я просто должен упомянуть некоторые атрибуты, которые делают все это возможным.

msDS-PSOAppliesTo

Каждый PSO имеет многозначный атрибут с именем msDS-PSOAppliesTo, который известен как «прямая ссылка», связанная с объектами пользователя или группы. Он может быть связан с одним пользователем, одной группой, несколькими пользователями, несколькими группами или несколькими пользователями и группами. Эти ссылки на самом деле являются просто различающимися именами (например, «CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local») связанных объектов.

Вы можете спросить: что, если мы переименуем или переместим объект пользователя или группы (в другое подразделение или контейнер), будут ли PSO «следовать» за объектами? Да — атрибут PSOs msDS — PSOAppliesTo автоматически обновляется службой каталогов в фоновом режиме, чтобы указать на новое местоположение (отличительное имя) измененного объекта.

msDS-PSOApplied

Только что упомянутый атрибут msDS-PSOAppliesTo в PSO можно редактировать, в отличие от атрибута «обратная ссылка» msDS-PSOApplied, который присутствует в объектах пользователя и группы. Последний атрибут «только для просмотра» обрабатывается службой каталогов в фоновом режиме.

Атрибут msDS-PSOApplied содержит «обратную ссылку» на PSO/PSO, указывающую на его родительский объект — поскольку к пользователям и группам может быть применено несколько PSO, этот атрибут также является многозначным.

msDS-результантPSO

Атрибут msDS-ResultantPSO присутствует только в пользовательских объектах. Он содержит вычисляемое значение, также называемое «Результирующий набор политик» ( RSoP ). Это ссылка на единственный «счастливый» PSO, который активен на конкретном пользовательском объекте. Это значение вычисляется процессом службы каталогов в фоновом режиме по правилам, упомянутым в следующем разделе этой статьи (« Дизайн »).

Вы можете спросить: когда политика паролей активна для пользователя, добавленного в группу? Как только пользователь добавляется в группу, результирующий PSO также рассчитывается для объекта пользователя службой каталогов. Та же история, если вы удаляете учетную запись пользователя из группы — изменение вступает в силу немедленно.

msDS-PasswordSettingsPrecedence

Атрибут msDS-PasswordSettingsPrecedence присутствует в объектах PSO. Более низкое значение этого атрибута указывает, что PSO имеет более высокий приоритет. Этот атрибут используется, когда к пользовательскому объекту применяется несколько PSO, т. е. выбирается самая низкая «стоимость». Если вы назначите уникальное значение приоритета для каждого из ваших PSO в домене, всегда будет легко определить эффективную политику паролей для определенного пользовательского объекта.

Дизайн

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

У вас может быть несколько политик, назначенных одному пользователю, напрямую или через членство в группах (обращаются даже вложенные группы безопасности), но только один PSO может быть эффективным для определенного пользовательского объекта в любой момент времени, а параметры пароля или блокировки не могут быть « объединены», как и в случае с групповыми политиками — вступает в силу та или иная политика.

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

Простые правила…
Результирующий PSO определяется следующим образом:

1. PSO, напрямую связанный с объектом пользователя, вступит в силу, если несколько PSO не связаны напрямую с объектом пользователя. Если связано более одного PSO, результирующим PSO является PSO с наименьшим значением приоритета ( msDS-PasswordSettingsPrecedence ). Если система обнаруживает два или более PSO, примененных непосредственно к данному пользователю, все с одинаковым значением msDS-PasswordSettingsPrecedence, применяется PSO с наименьшим глобальным уникальным идентификатором ( GUID ).
2. Если с объектом пользователя не связаны никакие объекты PSO, учитывается членство пользователя в глобальной группе безопасности. Если пользователь является членом нескольких групп безопасности с разными PSO, результирующим PSO является PSO с наименьшим значением приоритета. Если система обнаружит два или более PSO, примененных к данному пользователю в зависимости от членства в группе, все с одинаковым значением msDS-PasswordSettingsPrecedence, будет применен PSO с наименьшим идентификатором GUID.

Если PSO не получен из условий 1 и 2, применяются настройки пароля и блокировки из «Политики домена по умолчанию», как это было в более ранних версиях сред Active Directory ( AD ).
Итак, вкратце: PSO, установленные на пользовательских объектах, будут иметь преимущество над PSO, установленными на групповых объектах, и более низкое значение приоритета будет иметь преимущество перед более высоким — если это «не сработает», результат будет основан на числах GUID — и если ничего не применимо мы вернулись к тому, с чего начали: «Политика домена по умолчанию»!

В качестве более общих рекомендаций упомяну следующие:

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

Создайте соглашение об именах для PSO, как у вас для других объектов AD и т. д.

Назначайте PSO группам, а не непосредственно объектам пользователей, для лучшего обзора и упрощения управления.

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

Правило по умолчанию «Запретить все»

Что ж, я знаю, что это может быть непопулярно, но я бы порекомендовал вам установить параметры пароля, содержащиеся в «Политике домена по умолчанию», на очень высокий (почти «раздражающий») уровень безопасности. Это связано с тем, что вы или кто-то другой может «забыть» включить пользователя в одну из групп безопасности паролей. В этом случае политика паролей учетных записей пользователей будет «возвратной» к той, которая определена в этой политике по умолчанию, установленной на уровне домена.

Посмотрите на политику безопасности в Default Domain Policy как на правило «Default Deny All» в брандмауэре — если для пользователя (или одной из групп, членом которой он является) нет конкретного правила/политики, то мы должны разместить очень строгая политика в отношении «головы» пользователя. Пользователь, вероятно, позвонит в службу поддержки, чтобы получить это исправление как можно скорее — если мы предоставим пользователю очень мягкую политику паролей, вместо этого он / она в большинстве случаев никогда не будет жаловаться.

Еще один способ сделать это — установить детализированную политику паролей для группы «Пользователи домена» с самым низким приоритетом — но опять же, в какой-то момент учетная запись может «выскользнуть» из этой группы по какой-то причине… Мой выбор определенно правило «Запретить все по умолчанию» — как всегда!

Теневые группы и как их заскриптовать

Если вы никогда не слышали о «Shadow Groups», не беспокойтесь — я тоже два месяца назад. Теневая группа ( SG ) — это группа безопасности (в данном случае глобальная группа безопасности), которая содержит объекты внутри данной OU в качестве членов. SG — это группа безопасности, которая, можно сказать, «логически» сопоставлена с OU.

Например, у вас может быть подразделение «OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local» с учетными записями пользователей для всего отдела продаж — SG будет группой, которая на 100% соответствует этому содержимому. Для политик паролей это может быть очень полезно, если мы хотим, чтобы политики паролей «виртуально следовали» структуре OU, а не следовали структуре группы безопасности.

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

Сценарий собирает учетные записи пользователей из определенной организационной единицы, указанной в качестве аргумента сценария, и помещает их в объект словаря. Затем сценарий собирает пользователей в определенной группе, указанной в качестве аргумента сценария, и помещает их в другой объект словаря. Сравнивая эти словари, скрипт добавляет или удаляет пользователей из «теневой группы». Сценарий «предназначен» для планирования как задачи и должен использоваться со следующим синтаксисом: ShadowGroup.vbs «Целевое подразделение» «Shadow Group»

Пример :
ShadowGroup.vbs «OU = Test, DC = Contoso, DC = Local» «CN = Shadow, OU = Test, DC = Contoso, DC = Local»

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

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

Мы можем использовать старый добрый инструмент LDIFDE и, конечно же, нового шерифа в городе, мистера PowerShell. Windows PowerShell включена в Windows Server 2008 и должна быть добавлена как «Функция» — выберите « Добавить функцию » в новом и блестящем диспетчере серверов, выберите Windows PowerShell, и через несколько секунд вы будете «PowerShell Ready».

Я рекомендую вам попробовать командлеты Quest AD и проверить PowerGui.org.

Бесплатная утилита командной строки PSOMgr уже существует у Joeware. С помощью этого инструмента вы можете очень легко управлять объектами настроек пароля в Windows Server 2008, например. отображать примененные политики и действующую политику данного пользователя, отображать PSO в домене/лесу, добавлять или удалять пользователя из PSO, создавать/переименовывать/удалять/изменять PSO и многое другое…

Вывод

Понимание того, как работают детализированные настройки паролей, а также как, когда и зачем их использовать, очень важно. Надеемся, что эти две статьи о «Настройка выборочного пароля в Windows Server 2008» помогли вам разобраться в этом вопросе.

«Проект политики паролей» сам по себе, вероятно, является самой сложной и важной частью настройки нескольких политик паролей в одном домене AD, и после создания необходимых политик все остальное — это просто «управление как обычно» — наслаждайтесь!

Настройка детальных параметров пароля в Windows Server 2008, часть 1».

внешние ссылки
AD DS: подробные политики паролей
Пошаговое руководство по детальной настройке политик паролей и блокировки учетных записей