Советы и лайфхаки

Тонкая настройка политики управления паролями в среде windows – Такие разные пароли… — Корпоративный блог КИВИТ Информационные технологии

Содержание

Такие разные пароли… — Корпоративный блог КИВИТ Информационные технологии

Одно из многочисленных нововведений, появившихся в операционной системе Microsoft Windows Server 2008, позволяет более гибко конфигурировать требования к доменным паролям предприятия. Имя ему – Password Settings Objects.

Как известно, доменные среды Windows Server 2000 и 2003 позволяли иметь одну политику паролей на домен, которая устанавливает требования к его минимальной длине, сложности и прочим атрибутам. В случае необходимости использования нескольких политик, зачастую приходилось создавать дочерний домен и перемещать в него учетные записи, которым необходима более сложная или, напротив, упрощенная политика. В Windows Server 2008 появилась возможность создания неограниченного количества политик для разных групп и пользователей домена, позволяющих обеспечить необходимые требования безопасности к паролям.

Например, для соответствия политикам безопасности, рекомендуемым компанией Microsoft, мы можем создать три разных политики паролей для различных групп пользователей – для администраторов домена установить требования использования пароля, имеющего минимальную длину в 10 символов и обязательно содержащего символы нижнего, верхнего регистра, цифры и спецсимволы, для группы интернет-пользователей, не имеющим доступа к внутренним ресурсам компании – 4 символа и возможность использовать «простой» пароль. Для всех остальных пользователей будем использовать политику домена по умолчанию – минимальная длина в 6 символов и необходимость использования «сложного» пароля.

Каждая политика пароля (Fine-Grained Password) представляет собой объект службы каталогов (Password Settings objects, PSO) и может применяться только к глобальным группам безопасности либо пользователям, причем, если политик несколько, применяется та, которая имеет высший приоритет. Помимо этого, всегда имеет более высокий приоритет политика, назначенная напрямую пользователю, чем политика, назначенная группе. В случае, если группе назначены несколько PSO с одинаковым приоритетом, ни одна из них применена не будет и применить политика домена по умолчанию. Для работоспособности PSO требуется уровень домена не ниже Windows Server 2008 и уровень леса не ниже Windows Server 2000.

При создании политики используются следующие атрибуты:

  • Enforce password history (msDS-PasswordHistoryLength) – количество запоминаемых паролей, т.е. какое количество ранее введенных паролей не может повторяться;
  • Maximum password age (msDS-MaximumPasswordAge) – максимальное время жизни пароля, после которого необходимо его сменить;
  • Minimum password age (msDS-MinimumPasswordAge) – минимальное время жизни пароля, т.е. время, в течение которого невозможно его повторное изменение;
  • Minimum password length (msDS-MinimumPasswordLength) – минимальное количество символов в пароле;
  • Passwords must meet complexity requirements (msDS-Password-ComplexityEnabled) – требование сложности, обязывает использовать в пароле символы верхнего и нижнего регистров, числа, а также специальные символы;
  • Store passwords using reversible encryption (msDS-PasswordReversibleEncryptionEnabled) – хранение паролей в AD в открытом виде, рекомендуется отключать в целях безопасности;
  • Account lockout duration (msDS-LockoutDuration) – время до разблокирования учетной записи в случае ввода неправильного пароля;
  • Account lockout threshold (msDS-LockoutThreshold) – количество попыток ввода пароля, после которых учетная запись блокируется;
  • Reset account lockout counter after (msDS-LockoutObservationWindow) – время, за которое подсчитывается количество неправильных попыток ввода пароля
  • PSO link (msDS-PSOAppliesTo) – список групп или пользователей, к которым должна применяться данная политика
  • Precedence (msDS-PasswordSettingsPrecedence) – приоритет политики, чем значение меньше, тем приоритет выше

Политику паролей можно создать различными способами:

  • С помощью ADSI Edit
  • C использованием файла ответов и команды ldifde
  • С помощью программ сторонних производителей, например PSOMgr или Specops Password Policy

Создание политики паролей с помощью ADSI-Edit

На компьютере под управлением Windows Server 2008 либо Windows Vista запустите оснастку «Редактирование ADSI» (ADSI-Edit) и подключитесь к домену в контексте именования по умолчанию. Раскройте контекст домена, затем CN=System и выберите CN=Password Settings Container. В меню консоли «Действия» выберите «Создать», а затем «Объект». C помощью запущенного мастера введите все необходимые атрибуты, при этом обращаю ваше внимание, что пункты

Passwords must meet complexity requirements и Store passwords using reversible encryption могут иметь значения только TRUE (верно) или FALSE (неверно). Значения пунктов Maximum password age, Minimum password age, Account lockout duration и Reset account lockout counter after должны вводиться в формате [дни]:[часы]:[минуты]:[секунды],
например 0:0:40:0 – 40 минут. При использовании мастера необходим ввод всех используемых атрибутов, однако после создания политики вы можете вручную очистить ненужные значения в свойствах PSO на закладке «Редактор атрибутов». После окончания работы мастера вам необходимо вручную изменить атрибут PSO link для добавления учетных записей, к которым будет применяться политика. Для этого выберите «Свойства» созданной политики и на закладке «Редактор атрибутов» найдите атрибут
msDS-PSOAppliesTo. Нажмите «Изменить»
и в открывшемся окне добавьте необходимые учетные записи (рис.2).

Создание политики с помощью ldifde

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

dn: “CN=Domain Admins PSO, CN=Password Settings Container,CN=System,DC=dc01,DC=domain,DC=corp”

changetype: add

objectClass: msDS-PasswordSettings

msDS-MaximumPasswordAge:-1728000000000

msDS-MinimumPasswordAge:-864000000000

msDS-MinimumPasswordLength:8

msDS-PasswordHistoryLength:24

msDS-PasswordComplexityEnabled:TRUE

msDS-PasswordReversibleEncryptionEnabled:FALSE

msDS-LockoutObservationWindow:-18000000000

msDS-LockoutDuration:-18000000000

msDS-LockoutThreshold:0

msDS-PasswordSettingsPrecedence:20

msDS-PSOAppliesTo:”CN=Domain Admins,CN=Users,DC=dc01,DC=domain,DC=corp”

Откройте блокнот и введите вышеприведенные строки, отредактируйте в соответствии со своими потребностями и сохраните с именем pso.ldf. Необходимо иметь в виду, что временные значения вводятся в формате –[наносекунд], то есть для значения, равному одному часу нужно ввести по формуле –60*60* (10^7) = 36000000000

Далее, для создания политики, в командной строке введите:

ldifde –i –f pso.ldf

Политика создана в соответствии с заданными значениями атрибутов.

Просмотр результатов применения политик

После создания нескольких политик возникает необходимость удостовериться, что к тому или иному пользователю применяется необходимая политика. Сделать это можно с помощью команды dsget user “CN=Administrator,CN=Users,DC=domain,DC=corp” –effectivepso

Заключение

Помимо приведенных в статье способов, можно также использовать для создания политик программы сторонних разработчиков. Так, например, программа Specops Password Policy, использует оснастку MMC и позволяет выполнить базовое создание политики паролей с помощью графического интерфейса.

Возможность использования нескольких политик паролей в среде Windows Server 2008 позволяет более гибко конфигурировать настройки безопасности в зависимости от назначения учетных записей. Я рекомендую в обязательном порядке назначать служебным учетным записям домена более строгие политики паролей, этим вы значительно усложните задачу потенциальным взломщикам, а себе обеспечите спокойствие за сохранность данных.

Получить дополнительную информацию об использовании политик паролей в Windows Server 2008 вы можете на сайтах Microsoft и TechNet по нижеприведенным ссылкам:

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

Вебкаст «Active Directory: политика паролей»

Стаья опубликована в журнале “Системный администратор” за март 2009 г.

 

Поделиться ссылкой:

Похожее

mcp.su

Политики паролей Windows: admin_dm

В предыдущих версиях Active Directory (AD) у нас была лишь одна политика для пароля и блокировки учетной записи (account lockout policy) для всего домена. У некоторых компаний возникает необходимость использования нескольких доменов, чтобы использовать различные политики пароля (password policy) для различных пользователей; другие должны разрабатывать свои собственные фильтры для паролей или покупать решения сторонних производителей. В операционной системе Windows Server 2008 у нас есть возможность указать различные политики паролей для различных пользователей и групп.

Новое в классе

Коротко, новая функциональность, называемая “Granular Password Settings” или “Fine-Grained Password Policy“, основана на введении двух новых классов объектов в схему: контейнер настроек пароля или “Password Settings Container” и настройки пароля “Password Setting”. Эти объекты предоставляют нам возможность введения нескольких политик паролей в одном домене AD. Но давайте посмотрим, что нам еще для этого нужно …

Инструменты и требования

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

ADUC

Прежде всего весь функциональный уровень домена Active Directory должен использовать “Windows Server 2008”. Это можно проверить с помощью инструмента под названием Active Directory Users and Computers (ADUC пользователи и компьютеры AD). Нажимаем правой кнопкой мыши на домене > выбираем “Raise domain functional level (поднять функциональный уровень домена)” – текущий функциональный уровень домена должен быть “Windows Server 2008” (ниже представлен рисунок для версии beta 3 операционной системы Windows Server 2008 номер сборки 6001):

GPMC

Мы все равно должны использовать консоль управления политиками группы (Group Policy Management Console или GPMC), чтобы задать политику пароля по умолчанию для всего домена. Если вы забыли, как задать настройки политики паролей и политики блокировки учетной записи по умолчанию, то их можно найти в GPMC на уровне домена в “Default Domain Policy” > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy/Account Lockout Policy.

Между прочим, GPMC включен в состав операционной системы Windows Server 2008 (как и Windows Vista), но ее необходимо добавить из “Feature” – выбрать “Add Feature” в Server Manager, выбрать ‘Group Policy Management’ и через некоторое время ‘Group Policy Ready’ (политика группы готова).

ADSI Edit

Самый важный инструмент для этого упражнения – это инструмент, который большинство администраторов боялись на протяжении многих лет – т.к. оно используется лишь тогда, когда все очень плохо. Я говорю о утилите под названием ADSI Edit (adsiedit.msc). Большинство настроек политики паролей создается и настраивается с помощью этого инструмента. ADSI Edit является частью Windows Server 2008, поэтому вам не нужно устанавливать его дополнительно.

Этапы

Это краткий обзор этапов, необходимых для настройки ‘Granular Password Settings’ в операционной системе Windows Server 2008:

  1. Создание объекта настроек пароля или Password Settings Object (PSO) в контейнере настроек пароля или Password Settings Container (PSC) с помощью ADSI Edit
  2. Настройка параметров PSO с помощью обычного мастера ADSI Edit
  3. Назначение PSO для учетной записи пользователя или глобальной группы безопасности
  4. Подтверждение настроек

Теперь, когда мы знаем все этапы, давайте приступим!

Приступим

Сперва, давайте запустим ADSI Edit, нажав на Start > Run… > “adsiedit.msc” и нажав на кнопку OK (или клавишу Enter).

Щелкните правой кнопкой в корне “ADSI Edit” и выберите “Connect to…” (подключиться к…)

Нажмите на кнопку OK, чтобы выбрать настройки по умолчанию в диалоговом окне “Connection Settings” (настройки соединения):

В ADSI Edit у вас теперь появится возможность развернуть домен, развернуть контейнер ‘System’ и после этого нужно нажать правой кнопкой мыши ‘Password Settings Container’ (PSC) и выбрать New > “Object…”.

Теперь вы должны выбрать класс для нового объекта, но у вас для выбора лишь один элемент (иногда здорово иметь всего один вариант, не так ли?). Выберите msDS-PasswordSettings и нажмите на кнопку Next (далее):

После этого мастер поможет нам создать объект настроек для пароля (Password Settings Object или PSO). Нам необходимо будет указать значение для каждого из следующих 11 атрибутов. Наберите значение, как показано в таблице ниже (не забудьте ввести знаку минуса для тех значений, где это требуется) или же ввести свои настройки.

Таблица 1
АтрибутЗначениеКраткое описание
CnPassPolAdminsНазвание политики. Старайтесь присваивать политикам понятные имена, если у вас их будет много.
msDS-PasswordSettingsPrecedence10Параметр, используемый в качестве стоимости или приоритета для различных политик на тот случай, если для одного пользователя настраивается несколько политик PSO. Чем выше приоритет у настройки пароля PSO, тем меньше значение этого параметра.
msDS-PasswordReversibleEncryptionEnabledFalseБулевое значение. Верно, если пароль хранится и использованием обратного шифрования (обычно очень полезно)
msDS-PasswordHistoryLength32Количество ранее использованных паролей, которое должны помнить система
msDS-PasswordComplexityEnabledTrueБулевое значение. Верно, если вы хотите, чтобы пользователь использовал сложный пароль
msDS-MinimumPasswordLength16Минимальное количество символов для пароля для учетной записи пользователя
msDS-MinimumPasswordAge-864000000000(9 нулей)Минимальное время жизни пароля (в этом случае 1). Не забудьте поставить знак минус.
msDS-MaximumPasswordAge-36288000000000(9 нулей)Максимальное время жизни пароля? (в этом случае 42 дня). Не забудьте поставить знак минус.
msDS-LockoutTreshold30Количество попыток ввода неверного пароля после которого учетная запись будет заблокирована
msDS-LockoutObservationWindow-18000000000(9 нулей)Через это время счетчик количества попыток ввода неверного пароля будет обнулен (в этом случае 6 минут). Не забудьте поставить знак минус.
msDS-LockoutDuration-18000000000(9 нулей)Как долго будет заблокирована учетная запись пользователя при вводе большого количества неверных паролей (в этом случае 6 минут). Не забудьте поставить знак минус.

После завершения ввода этой информации вы увидите следующее диалоговое окно – просто нажмите в нем на кнопку Finish (Завершить).

Сделаем это

Теперь, когда мы создали объект PSO, он должен появиться ниже PSC в ADSI Edit и ADUC/Server Manager (не забудьте подключить “Advanced Features (дополнительные возможности)” в меню View (просмотр)), и должен выглядеть примерно так:

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

Для этого щелкните правой кнопкой на PSO в ADUC (или в ADSI Edit) и выберите пункт Properties (свойства)– нажмите на Filter (фильтр) и убедитесь, что у вас выбраны следующие настройки:

Если вы не видите рисунок, то я могу рассказать вам, что выбраны следующие параметры: “Mandatory”, “Optional”, “Constructed”, “Backlinks” и “System-only”. Параметр “Show only attributes that have values” не выбран.

Теперь найдите msDS-PSOAppliesTo, выберите его и нажмите на кнопку Edit (Редактировать).

В редакторе “Multi-valued String Editor” вставьте необходимое имя пользователя или глобальной группы безопасности в поле “Value to add” и нажмите на кнопку Add (Добавить). Вы можете добавить несколько различных имен с помощью этого окна – после того, как вы закончите, просто нажмите на кнопку OK.

В примере, изображенном на рисунке, я добавил глобальную группу безопасности под названием “Admins” (полное имя “CN=Admins,CN=Users,DC=Contoso,DC=Local”). Каждая учетная запись пользователя, которая входит в состав этой группы, теперь будет подчиняться новой политике пароля “PassPolAdmins”, вместо доменной политики по умолчанию (Default Domain Policy). Здорово!

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

Вы заметили перемены?

Когда вы раньше работали в ADUC, вы обратили внимание на новую закладку “Attribute Editor” (редактор атрибутов), которая теперь есть для большинства объектов (необходимо зайти View > “Advanced Features”)?

Это в действительности здорово, т.к. она позволяет администратору просматривать и редактировать множество элементов, что обычно делается при помощи инструмента ADSI Edit. С помощью этой закладки мы можем перенести свойства PSO в домен и изменить атрибут msDS-PSOAppliesTo, чтобы легко применить политику пароля для пользователя или группы (или удалить пользователя или группу из этой политики). Пожалуйста, обратите внимание, что вы не можете установить политику пароля в свойствах пользователя или группы – информация о том, какая политика применяется к пользователю или группе устанавливается самим объектом настроек пароля Password Settings Object!

Как я могу увидеть, что политика выиграла?

Может быть очень сложно определить, что политика ‘выиграла’ для конкретного пользовательского объекта. Но я рад сообщить вам, что компания Microsoft подумала об этом, и ввела атрибут msDS-ResultantPSO для пользовательского объекта (только лишь).

Это значение позволяет определить, какая политика применяется для конкретного пользователя (в нашем примере пользователь называется “Windows Admin”). Другими словами это активная политика пароля и блокировки учетной записи для выбранного пользователя.

И объекты групп и объекты пользователей имеют еще один новый атрибут, msDS-PSOApplied, который описывает (в многострочной строке) все политики, под влияние которых попадает группа или пользователь – либо напрямую, либо благодаря членству. В примере ниже группа под названием “Admins” попадает под действие двух различных политик пароля.

Примечание: Если вы не видите значения, о которых я здесь говорю, не забудьте задать настройки фильтра в закладке “Attribute Editor”, о которых я упоминал в параграфе под названием «Сделаем это».

Почему я захочу это сделать?

Теперь мы увидели, как создать PSO и назначить их для пользователей и групп, но для чего нам нужно несколько политик пароля и блокировки учетной записи (password and account lockout policy), можете спросить вы? Хорошо. Существует множество причин для этого – одно может заключаться в размещении сценариев, когда несколько компаний представлены в одном домене AD domain. Другая причина, которая встречается гораздо чаще, заключается в том, что мы должны более жестко контролировать группы людей с расширенными правами (как администраторы домена, сотрудники службы помощи и т.п.).

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

Чего это может коснуться?

Рискуя повториться, я все же скажу, чтобы это было на 100% ясно. Новая функциональность многопарольной политики (“multiple password policy”) в операционной системе Windows Server 2008 (кодовое название “Longhorn”) позволяет нам задавать индивидуальные политики пароля и блокировки учетной записи для объектов пользователей (user), объектов interOrgPerson и глобальных групп безопасности (global security groups).

Новые политики пароля нельзя напрямую применить для организационной единицы OU – теперь вместо этого мы должны применять эти политики для групп. Но не для любых групп, это должны быть группы безопасности (security group) глобальной области действия. Существует также возможность установки параметров/атрибутов для других групп; однако, это работает не так, как ожидалось (настройки игнорируются).

Если мы действительно хотим обрабатывать политики паролей внутри структуры OU, то могут быть полезны теневые группы ‘Shadow Groups’ – смотрите раздел ‘Shadow Groups and how to script them’ ниже в этой статье.

По умолчанию только члены группа администраторы домена “Domain Admins” могут устанавливать, создавать и удалять политики пароля – лучше известные как объекты настроек пароля (Password Setting Objects PSO). Однако, эти привилегии можно также передавать и забирать в случае необходимости, но для большинство сред этих настроек будет достаточно. Чтобы быть более точным, только члены группы администраторов домена (Domain Admins) имеют необходимые привилегии ‘Create Child’ (создать дочерний объект) и ‘Delete Child’ (удалить дочерний объект) для объекта Password Settings Container (PSC).

Чтобы применить PSO для пользователя или группы, вы должны обладать привилегиями на запись (‘Write’ permission) для объекта PSO – по умолчанию такими привилегиями обладают члены группы администраторов домена (Domain Admin).

Посмотрите на эти атрибуты

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

msDS-PSOAppliesTo
Каждый объект PSO имеет атрибут под названием msDS-PSOAppliesTo, который известен также, как ссылка, связывающая с пользователем или группой. Она может указывать на одного пользователя, одну группу, несколько пользователей, несколько групп или несколько пользователей и групп. Эти ссылки в действительности лишь выдающиеся имена (distinguished names), например, “CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local” для объектов.
У вас может возникнуть вопрос, а что будет, если мы переименуем или удалим пользователя или группу (в другой контейнер или OU), последует ли PSO за объектами? Да – атрибут PSO под названием msDS-PSOAppliesTo автоматически обновится службой директории в фоновом режиме, и будет указывать на новое место.
msDS-PSOApplied
Вышеупомянутый атрибут msDS-PSOAppliesTo для PSO можно редактировать в отличие от атрибута msDS-PSOApplied, который представляет пользователя или группу. Последний атрибут предназначен только для чтения и обрабатывается в фоновом режиме службой директории.
Атрибут msDS-PSOApplied содержит ссылку на PSO, указывающий на родительский объект – как пользователи, так и группы могут иметь несколько PSO, назначенных им.
msDS-ResultantPSO
Атрибут msDS-ResultantPSO существует только для объектов пользователей. Он содержит вычисляемое значение, которое также называют “Resultant Set of Policy” (RsoP результирующий набор политики). Это ссылка на один “счастливый” PSO, который активен для определенного объекта пользователя. Это значение определяется службой директории в фоновом режиме с помощью правил, упомянутых в следующем разделе этой статьи (“Проект”).
Вы можете спросить, если политика пароля активна для пользователя, который добавлен в группу? Как только пользователь добавляется в группу, то результирующая PSO также высчитывается для пользовательского объекта службой директории (directory service). То же самое происходит при удалении учетной записи пользователя из группы.
msDS-PasswordSettingsPrecedence
Атрибут msDS-PasswordSettingsPrecedence присутствует на объектах PSO. Низкое значение этого атрибута говорит о том, что PSO имеет высокий приоритет. Этот атрибут используется в том случае, когда для одного пользователя применяется несколько PSO – т.о. выбирается самое низкое значение. Если вы назначите несколько уникальных значений для каждого объекта PSO в домене, то легко можно будет определить эффективную политику пароля для определенного пользователя.

Проект

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

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

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

Простые правила …

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

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

Если не удается получить ни одного PSO исходя из условий 1 и 2, то применяются настройки для пароля и блокировки из доменной политики по умолчанию “Default Domain Policy”, точно также как и в предыдущих версиях Active Directory (AD).

Таким образом, мы немного сократили нашу историю: PSO, назначенный пользователю, выиграет у PSO, назначенному группе, а меньшее значение выиграет у большего – если такое сравнение не удается, то в ход вступает значение GUID. А если ничего не подходит, то мы приходим к началу – к доменной политике по умолчанию “Default Domain Policy”!

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

Поле ‘Description’ (описание) может быть использовано для указания настроек пароля и блокировки, которые включены в PSO. Используйте его для краткого описания конфигурации PSO.

Используйте соглашение по наименование (naming convention) для PSO, как вы делаете это для других объектов AD.

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

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

Правило Default Deny All (по умолчанию запретить все)

Я знаю, что это может быть не очень популярно, но я рекомендую вам установить настройки политик, содержащихся в “Default Domain Policy” (доменная политика по умолчанию) на очень высокий уровень безопасности. Это делается для того, что вы или кто-нибудь еще может забыть включить пользователя в одну из групп политик безопасности. В этом случае для учетной записи такого пользователя будут применяться политики для пароля, заданные в политике по умолчанию, которая задается на уровне домена.

Можно сравнить политику безопасности для доменной политики по умолчанию (Default Domain Policy) с правилом “Default Deny All” (запретить все по умолчанию) для брандмауэра – если ни одно из правил (политик) не подходит для пользователя (или группы, членом которой он является), то мы должны применить к нем самую строгую политику. В этом случае пользователь почти наверняка позвонит в службу помощи, чтобы исправить это. Если же мы дадим пользователю слишком много прав, то он скорее всего никогда не позвонит.

Еще одни способ выполнить это, заключается в указании политики паролей для группы “Domain Users” (пользователи домена) с использованием наименьшего приоритета – но опять же, по каким-либо причинам учетная запись может выпасть из этой группы… Поэтому лично я всегда задаю правило Default Deny All (запретить все по умолчанию)!

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

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

Например, у вас может быть OU, “OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local”, с учетными записями для всего отдела продаж – SG будет группа, которая на 100% соответствует ее содержимому. Для политик паролей это действительно может быть хорошей возможностью, если мы хотим, чтобы политики паролей виртуально удовлетворяли структуре OU, вместо того, чтобы совпадать со структурой группы безопасности (Security Group).

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

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

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

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

Написание сценариев

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

Конечно, мы можем использовать инструмент под названием LDIFDE, или PowerShell. Windows PowerShell включен в состав операционной системы Windows Server 2008 и может быть добавлен в качестве инструмента – выберите “Add Feature” (добавить возможность) в новом менеджере сервера Server Manager, выберите Windows PowerShell и через несколько секунд PowerShell готов к использованию

Я также рекомендую вам попробовать Quest AD Cmdlets и зайти на PowerGui.org.

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

admin-dm.livejournal.com

Тонкая настройка политик управления паролями в Windows Server 2008 | Windows IT Pro/RE

В статье «Политики паролей Windows Server 2008», опубликованной в Windows IT Pro/RE № 2 за 2008 г., Жан де Клерк рассказывал о возможностях применения политик управления паролями для обеспечения требований к качеству паролей у пользовательских учетных записей, отмечая, что Windows Server 2003 и Windows 2000 Server позволяют задать только одну политику для всех пользовательских учетных записей в домене. В Windows Server 2008 это ограничение снято. Поняв, как использовать политики управления паролями в Server 2008, вы сможете развернуть в домене детализированные политики обеспечения парольной защиты (Fine-Grained Password Policies, FGPP) для раздельного управления настройками защиты паролей учетных записей пользователей различных категорий в домене.

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

Проектируя FGPP для Server 2008, Microsoft отошла от моделей, используемых сторонними продуктами, взамен создав систему, где политики применяются к глобальным группам безопасности вместо организационных единиц (OU). При реализации FGPP в организации с уже развернутой инфраструктурой Active Directory (AD) перемещение учетных записей из одного OU в другой может пагубно отразиться на работе настроек групповых политик или делегировании полномочий, тогда как добавление пользовательских учетных записей в новую группу никак не влияет на существующую инфраструктуру.

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

Для создания теневых групп можно пользоваться такими средствами, как Windows PowerShell, LDIFDE и VBScript. Следующая команда запрашивает объекты типа «пользователь» в организационном подразделении HR домена ad.mycompany.com

dsquery user ou=hr, dc=ad, dc=mycompany, dc=com | dsmod group
cn=hr_ou_users, ou=groups, dc=ad, dc=mycompany, dc=com -chmbr

Эта команда также изменяет (dsmod) список членов существующей глобальной группы безопасности hr_ou_users, расположенной в OU под названием groups, так, чтобы в этом списке был отражен результат исходного запроса (dsquery). Команда dsquery используется для выполнения запросов LDAP к AD. В приведенном примере user определяет тип искомого объекта; область поиска ограничивается объектами, входящими в OU HR. Команда dsmod изменяет существующие объекты AD; group определяет тип изменяемого объекта, а следующая за этим словом строка точно указывает на положение объекта в AD. Ключ -chmbr заменяет существующих членов группы новыми.

Выполнив такую манипуляцию, можно применить FGPP к новой теневой группе и при необходимости обновлять членство данной группы путем регулярного запуска этой команды по расписанию. Фактически приведенное решение применяет FGPP к объектам типа «пользователь», расположенным в определенной OU, хотя с технической точки зрения политика применяется к группе.

Создавать и изменять объекты настроек парольной защиты Password Settings objects (PSO), а также привязывать их к группам AD через стандартные настройки безопасности AD могут только администраторы домена. Для того чтобы позволить специалистам службы поддержки изменять парольные политики для конкретных пользователей, рекомендуется привязывать PSO к группам, позволяя администраторам и сотрудникам службы поддержки перемещать учетные записи пользователей между соответствующими группами. Разработав подходящую вашей организации схему делегирования прав, можно переложить задачи изменения эффективной парольной политики пользователей на плечи сотрудников первой линии поддержки, не предоставляя им возможности напрямую редактировать AD.

Какие FGPP воздействуют на пользователя

При решении проблем, связанных с FGPP, нам может понадобиться выяснить, какой из объектов PSO оказывает влияние на пользовательскую учетную запись. Это не всегда просто сделать, поскольку при наложении нескольких PSO действует схема приоритетов для настроек уровня групп безопасности и отдельной учетной записи.

Значение атрибута msDS-ResultantPSO для пользовательской учетной записи можно получить с помощью команды dsget, указав отличительное имя (DN) учетной записи пользователя:

dsget user «cn=administrator, cn=users, dc=ad, dc=com»
-effectivepso

Команда вернет объект PSO, который фактически контролирует настройки пароля учетной записи администратора (если такой объект найдется) в следующем формате, где passpol_Admins — это имя действующего PSO:

effectivepso
«CN=passpol_Admins, CN=Password Settings Container,
CN=System, DC=ad, DC=mycompany, DC=com»
dsget succeeded

Выбрав в оснастке консоли MMC Active Directory Users and Computers команду Advanced Features из меню View, также можно найти значение атрибута msDS-ResultantPSO, выбрав объект учетной записи пользователя в графическом интерфейсе. Для этого нужно открыть контекстное меню щелчком правой кнопки мыши, открыть окно Properties и перейти на закладку Attribute Editor. Чтобы отобразить атрибут msDS-ResultantPSO, на закладке Attribute Editor следует нажать Filter и добавить к Show read-only attributes признак Constructed. Для младших специалистов службы поддержки этот способ может оказаться более доступным.

Создание объектов PSO с помощью PowerShell

В арсенале Microsoft пока нет графических инструментов для создания объектов настроек паролей PSO. Если вам не по душе стандартные инструменты ADSI Edit или ldp.exe, можно администрировать AD с помощью бесплатного набора команд PowerShell под названием ActiveRoles Management Shell for Active Directory от компании Quest Software, в который входят команды для управления PSO. Они пригодятся и для автоматизации процесса создания PSO. Данный набор команд нужно загрузить с сайта производителя и установить после развертывания .NET Framework и Windows PowerShell. Для этого требуется выполнить следующие действия.

  1. Откройте консоль PowerShell от имени администратора домена.
  2. Для работы с новыми командами в сеансе PowerShell выполните инструкцию
              add-pssnapin quest.activeroles. admanagement
  3. Чтобы создать новый объект PSO для администраторов домена, введите
              new-qadpasswordsettingsobject -name admins
              — precedence 10-passwordhistorylength 5
              — passwordcomplexityenabled $true -minimumpasswordlength 6
  4. Для применения политики к группе Domain Admins введите
              add-qadpasswordsettingsobjectappliesto admins
              — appliesto ‘addomain admins’

Чтобы проверить, привязан ли PSO для администраторов к группе Domain Admins и установлены ли все остальные атрибуты надлежащим образом, введите

get-qadpasswordsettingsobject | format-list

как показано на экране 1.

Для проверки наследования административного PSO учетной записью Administrator, введите

get-qaduser administrator
     -includedproperties
msds-resultantpso | format-list
     name, msds-resultantpso

Наконец, задайте следующую команду для удаления только что созданного PSO для администраторов:

remove-qadobject admins

Появится запрос на подтверждение перед удалением PSO.

Создание PSO при помощи Specops

Альтернативой использованию ADSI Edit или командной строки для создания PSO является Specops Password Policy Basic, продукт компании Special Operations Software. Этот инструмент можно бесплатно загрузить по адресу www.specopssoft.com/wiki/index.php/SpecopsasswordPolicyBasic/Download.

В программе Password Policy Basic организован простой интерфейс для создания, редактирования и удаления PSO. Создавать объекты PSO могут только администраторы домена, однако сотрудники Help desk могут воспользоваться оснасткой MMC Lookup password policy for user для просмотра приоритетов объектов PSO, как показано на экране 2.

  1. Откройте Password Policy Basic в сеансе администратора домена.
  2. В блоке Connected domains проверьте наличие записи для вашего домена. В данном случае присоединен домен ad.com.
  3. Нажмите кнопку Configure selected domain.
  4. В правой панели MMC появится базовая политика парольной защиты домена (по умолчанию). Нажмите New password policy для создания нового объекта PSO. Назовите новую политику Administrators.
  5. Настройте необходимые параметры PSO в блоках Password policy settings и Account lockout settings, как показано на экране 3. Нажмите Add member в правом нижнем углу диалогового окна Password policy, добавьте группу Domain Admins в диалоговом окне AD Select Users or Groups и нажмите OK.

 

На экране 4 показана новая политика Administrators, теперь она выполняется для всех пользователей, входящих в группу Domain Admins. Создав несколько объектов PSO, можно использовать стрелки в правой части окна оснастки MMC для изменения приоритетов, причем высший приоритет сохраняется за верхним объектом PSO в списке. Нажмите Lookup password policy for user и введите слово administrator в диалоговом окне Select Users. Для учетной записи Administrator в отчете должно быть указание на подчинение политике Administrators.

До встречи с R2…

Если вы не освоились со встроенными в Server 2008 механизмами управления FGPP в AD, для их настройки можно использовать PowerShell или графические инструменты сторонних поставщиков. Однако имейте в виду, что в составе Server 2008 R2 будет PowerShell 2.0, уже оснащенный командами для управления FGPP.

Рассел Смит ([email protected]) — независимый ИТ-консультант, специализируется на управлении системами

www.osp.ru

Раздельная политика паролей в Windows Server 2008 — Заметки о Windows

Как известно, домен в Active Directory (AD) является границей общей области безопасности. В связи с этим в домене Windows Server 2003 AD может существовать только одна политика паролей. На самом деле, ограничена не только политика паролей, но и более широкий набор параметров, относящихся к политикам учетных записей:

• Политики паролей (Password Policy)
• Политики блокировки учетных записей (Account Lockout Policy)
• Политики Kerberos (Kerberos Policy)

 

Параметры в этом объекте групповой политики управляют политиками учетных записей для всех пользователей и для всех компьютеров домена. Раньше, при необходимости использования разных политик учетных записей для разных групп пользователей  приходилось создавать несколько доменов, однако в Windows Server 2008 появилась возможность указывать разные политики для различных пользователей и групп. Эта новая функциональность называется раздельной политикой паролей  (Fine-Grained Password Policy) и основана на введении двух новых классов объектов в схему AD: контейнер настроек пароля (Password Settings Container) и настройки пароля (Password Setting). Эти объекты предоставляют нам возможность введения нескольких политик паролей в одном домене AD.

Настройка раздельной политики паролей

Первым делом открываем оснастку Active Directory Users and Computers (ADUC) и проверяем функциональный уровень домена Active Directory

 

Он должен быть не ниже Windows Server 2008

 

В этой же оснастке ADUC создаем глобальную группу безопасности, для которой в дальнейшем будут применяться новые политики паролей. (Да, как это не странно, политика паролей применяется не к организационным единицам, а к группам безопасности).

 

Затем запускаем редактор ADSI Edit

 

Щелкаем правой кнопкой в корне ADSI Edit и выбираем Connect to (Подключиться к)

 

Здесь у нас  появится возможность развернуть домен

 

Затем разворачиваем контейнер System и нажав правой кнопкой мыши Password Settings Container выбираем New — Object (Новый — Объект)

 

Теперь мы должны выбрать класс для нового объекта (правда, для выбора есть лишь один элемент). Выбираем msDS-PasswordSettings и нажимаем Next (Дальше):

 

После этого запускается мастер, который поможет нам создать объект настроек для пароля (Password Settings Object, PSO). Нам необходимо будет указать значение для каждого из следующих 11 атрибутов. Набираем значение, как показано в примере, не забывая ввести знак минуса для тех значений, где это требуется.

CN — название политики. Стоит присвоить политике понятное имя, если у вас их будет несколько.

 

msDS-PasswordSettingsPrecedence — параметр, используемый в качестве приоритета для различных политик. Используется в том случае, если для одного пользователя настраивается несколько политик PSO. Чем выше приоритет, тем меньше значение этого параметра.

 

msDS-PasswordReversibleEncriptionEnabled — булево значение. Верно, если пароль хранится с использованием обратного шифрования (может быть полезно для повышения безопасности).

 

msDS-PasswordHistoryLength — количество ранее использованных паролей, которое должна помнить система.

 

msDS-PasswordComplexityEnabled — булево значение. Верно, если вы хотите, чтобы пользователь использовал сложный пароль.

 

msDS-MinimumPasswordLength — минимальное количество символов для пароля для учетной записи пользователя.

 

msDS-MinimumPasswordAge — минимальное время жизни пароля (в примере 1 день).

 

msDS-MaximumPasswordAge — максимальное время жизни пароля (в примере 42 дня).

 

msDS-LockoutThreshold — количество попыток ввода неверного пароля, после которого учетная запись будет заблокирована.

 

msDS-LockoutObservationWindow — время, через которое счетчик количества попыток ввода неверного пароля будет обнулен (в примере 15 минут).

 

msDS-LockoutDuration — время, в течение которого будет заблокирована учетная запись пользователя при вводе большого количества неверных паролей (в примере 15 минут).

 

После завершения ввода этой информации в следующем диалоговом окно нажимаем в на кнопку Finish (Завершить).

 

Новая политика паролей создана, остается только назначить ее определенному пользователю или глобальной группе безопасности. Для этого щелкаем правой кнопкой на созданном объекте и выбираем пункт Properties (Свойства).

 

Теперь выбираем пункт msDS-PSOAppliesTo жмем  на кнопку Edit (Редактировать).
Здесь можно добавить необходимое имя пользователя или глобальной группы безопасности.

 

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

Если к пользователю применяется несколько политик PSO, то результирующая политика будет определяться следующим образом:

  • PSO, которая связана напрямую с пользователем, будет использоваться до тех пор, пока напрямую пользователю не назначено несколько PSO. Если назначено более одной PSO, то результирующей будет PSO с наименьшим значением msDS-PasswordSettingsPrecedence. Если система обнаружит, что с пользователем связаны две или более PSO с одинаковым значением msDS-PasswordSettingsPrecedence, то будет применена PSO с меньшим значением глобального уникального идентификатора Global Unique Identifier (GUID).
  • Если ни один PSO не связан с пользователем, то входит в рассмотрение членство пользователя в глобальной группе безопасности (global security group). Если пользователь является членом нескольких групп безопасности с различными PSO, то результирующим будет PSO с наименьшим значением. Если система обнаруживает два или более PSO, назначенных для групп, в состав которых входит этот пользователь, с одинаковым значением msDS-PasswordSettingsPrecedence, то применяется PSO с наименьшим значением GUID.
  • Если не удается получить ни одного PSO исходя из предыдущих условий, то применяются настройки для пароля и блокировки из доменной политики по умолчанию, точно также как и в предыдущих версиях Active Directory.

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

windowsnotes.ru

Offline domain join или удаленный ввод в домен через Direct Access | blog.eaglenn.ru

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

1. Создание файла ответов для автономного ввода (offline domain join) ПК в домен

Подключимся к консоли сервера используя Remote Desctop Protocol и запустим командную строку, либо консоль powershell. Используйте что вам больше нравится. В примере я буду использовать командную строку. для этого запущу утилиту cmd от имени администратора. Для этого щелкнем по Командной строке правой кнопкой мыши и выберем в появившемся окне Запустить от имени администратора.

Используя интерфейс командной строки введем следующую команду:

Djoin.exe /provision /domain EXAMPLE.COM /machine ИМЯ КОМПЬЮТЕРА /rootcacerts /machineou «ou=desktops, dc=EXAMPLE, dc=COM» /policynames «Параметры клиента DirectAccess» /savefile C:\ИМЯ ФАЙЛА.txt

Справка по работе с утилитой Djoin.exe:

/PROVISION — подготавливает учетную запись компьютера в домене.
/DOMAIN <имя> — <имя> домена, к которому необходимо присоединиться.
/MACHINE <имя> — <имя> компьютера, присоединяемого к домену.
/MACHINEOU <OU> — необязательный параметр, определяющий подразделение
<OU>, в котором создается учетная запись.
/DCNAME <DC> — необязательный параметр, определяющий целевой контроллер домена <DC>, на котором будет создана учетная запись.
/REUSE — повторно использовать существующую учетную запись (пароль будет сброшен).
/SAVEFILE <путь_к_файлу> — сохранить данные подготовки в файл, расположенный по указанному пути.
/NOSEARCH — пропустить обнаружение конфликтов учетных записей; требуется DCNAME (более высокая производительность).
/DOWNLEVEL — обеспечивает поддержку контроллера домена Windows Server 2008 или более ранней версии.
/PRINTBLOB — возвращает большой двоичный объект метаданных в кодировке base64 для файла ответов.
/DEFPWD — использовать пароль учетной записи компьютера по умолчанию (не рекомендуется).
/ROOTCACERTS — необязательный параметр, включить корневые сертификаты центра сертификации.
/CERTTEMPLATE <имя> — необязательный параметр, <имя> шаблона сертификата компьютера. Включает корневые сертификаты центра
сертификации.
/POLICYNAMES <имена> — необязательный параметр, список имен политик, разделенных точкой с запятой. Каждое имя является отображаемым именем объекта групповой политики в AD.
/POLICYPATHS <пути> — необязательный параметр, список путей к политикам, разделенных точкой с запятой. Каждый путь указывает на расположение файла политик реестра.
/NETBIOS <имя> — необязательный параметр, Netbios-имя компьютера, присоединяемого к домену.
/PSITE <имя> — необязательный параметр, <имя> постоянного сайта, в который нужно поместить компьютер, присоединяемый к домену.
/DSITE <имя> — необязательный параметр, <имя> динамического сайта, в который первоначально помещается компьютер, присоединяемый к домену.
/PRIMARYDNS <имя> — необязательный параметр, основной DNS-домен компьютера, присоединяемого к домену.
/REQUESTODJ — требует автономного присоединения к домену при следующей загрузке.
/LOADFILE <путь_к_файлу> — <путь_к_файлу>, указанный ранее с помощью параметра /SAVEFILE.
/WINDOWSPATH <путь> — <путь> к каталогу с автономным образом Windows.
/LOCALOS — позволяет указывать в параметре /WINDOWSPATH локальную операционную систему.
Эту команду должен выполнять локальный администратор.
Для применения изменений потребуется перезагрузить компьютер.

В результате выполнения команды с приведенными выше параметрами мы получим файл ответов, который уже содержит в себе необходимые для работы Direct Access сертификаты, список политик direct access, необходимо пространство имен DNS.

2. Ввод в домен компьютера через Direct Access

Передаем полученный текстовый файл на рабочее место пользователя и запускаем его из командной строки:

djoin /requestODJ /loadfile C:\ИМЯ ФАЙЛА.txt /windowspath %SystemRoot% /localos

Перезагрузка.

На этом процедура удаленного ввода компьютера в домен закончена. В окне приглашения вводим имя доменного пользователя и его пароль.

blog.eaglenn.ru

Active Directory | blog.eaglenn.ru | Заметки IT инженера

В дополнение к статьям:

Хочу описать процесс настройки конкретных пользователей и групп для добавления компьютеров в домен Active Directory.

Читать далее →

Запись опубликована автором Алексей Орлов в рубрике Active Directory, Windows Server 2008 R2, Windows Server 2012 R2 с метками active directory, gpo, Windows, Windows Server.

Как было описано ранее, каждый пользователь домена, может ввести в домен до 10 компьютеров и устройств. К чему это может привести описывалось в статье «Запрет на ввод в домен компьютера с существующим именем» Для полного запрета этой возможности можно необходимо изменить атрибут ms-DS-CreatorSID. Для изменения атрибута нам понадобиться утилита редактирования ADSI.

Читать далее →

Запись опубликована автором Алексей Орлов в рубрике Active Directory, Windows Server 2008 R2, Windows Server 2012 R2 с метками active directory, gpo, Microsoft, Windows Server.

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

Читать далее →

Запись опубликована автором Алексей Орлов в рубрике Active Directory, Windows Server 2008 R2, Windows Server 2012 R2 с метками active directory, Microsoft, Windows, Windows Server.

Самым простым способом настроить требования к политике паролей в Active Directory является использование оснастки mmc «Управление групповой политикой». Для этого нам необходимо на контроллере домена выполнить следующую последовательность действий: Пуск — Администрирование — Управление групповой политикой

Читать далее →

Запись опубликована автором Алексей Орлов в рубрике Active Directory, Group Policy Object (GPO) с метками gpo, Windows Server.

В одной из статей (Настройка политики паролей в Active Directory используя GPO) мы уже рассматривали вариант управления политикой паролей на основе использования Default Domain Policy, но как уже отмечалось ранее у данного способа есть некоторые минусы, которые могут привести к полной блокировке работы каталога Active Directory. Для того чтобы с минимизировать вероятность остановки работы AD, можно использовать тонкую настройку политики управления паролями. Рассмотрим ее в этой статье.

Читать далее →

Запись опубликована

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *