Где находится active directory. Использование Active Directory Provider. Репликация данных в Active Directory

В ноябрьском номере КомпьютерПресс мы ознакомили вас с ключевыми возможностями Windows PowerShell - новой среды командной строки и языка сценариев от компании Microsoft. Сегодня мы рассмот­рим применение этой среды для администрирования корпоративной директории Active Directory (AD).

Коротко о PowerShell

Windows PowerShell - новая командная строка и язык сценариев от компании Microsoft. PowerShell является компонентом Windows Server 2008 (надо только выбрать его в Server Manager) и доступна для загрузки со странички www.microsoft.com/powershell для Windows XP, Windows Server 2003 и Windows Vista.

Если вы не знакомы с Windows PowerShell, то рекомендуем вам сначала прочитать статью «Windows PowerShell. Коротко о главном» в КомпьютерПресс № 11’2007. В данной публикации мы ограничимся лишь кратким повторением основ и сразу перейдем к главной теме статьи.

Итак, команды PowerShell называются командлетами (cmdlet) и состоят из глагола (например, get, set, new, remove, move, connect) и существительного в единственном числе, описывающего объект действия. Между ними ставится дефис. Получается что-то вроде: get-process, stop-service и т.п.

Команды, как правило, связываются конвейером, обозначаемым вертикальной чертой (|). Этот знак означает, что вся коллекция объектов из предыдущей команды передается на вход следующей.

Такая объектная ориентированность очень удобна, поскольку позволяет легко оперировать объектами и связывать команды вместе. В этой статье мы расскажем, как подобный подход облегчает управление корпоративной директорией на базе Active Directory.

Способы работы с Active Directory

Директория Active Directory является основой корпоративных сетей на базе Windows Server 2000, 2003 и 2008. Именно там хранятся все учетные записи пользователей, информация о группах, компьютерах сети, ящиках электронной почты и многом другом.

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

Существует три основных способа работы с Active Directory в Windows PowerShell:

• с помощью интерфейса Active Directory Service Interfaces (ADSI) - этот способ является наиболее сложным, но работает в любой установке PowerShell и не требует дополнительных модулей. Он также наиболее близок к способу управления, который использовался в языке сценариев VBScript;
• с помощью провайдера Active Directory, входящего в расширения PowerShell, - этот способ позволяет подключить директорию в виде диска на вашем компьютере и перемещаться по ней с помощью соответствующих команд: dir, cd и т.д. Данный способ требует установки дополнительного модуля с сайта codeplex;
• с помощью командлетов управления Active Directory - это наиболее удобный способ манипулирования объектами директории, но он тоже требует дополнительной инсталляции соответствующих модулей.

ADSI

Active Directory Service Interfaces (ADSI) хорошо знаком всем, кто пытался писать сценарии на языке VBScript. В PowerShell этот интерфейс реализован с помощью так называемого адаптера. Указав в квадратных скобках название адаптера (ADSI) и путь к объекту в директории на языке LDAP-запроса (Lightweight Directory Access Protocol - протокол работы с директориями, который поддерживает и AD), мы получаем доступ к объекту из директории и можем дальше вызывать его методы.

Например, подсоединимся к одному из контейнеров директории и создадим в нем новую пользовательскую учетную запись.

$objOU = ”LDAP://mydc:389/ou=CTO,dc=Employees,dc=testdomain,dc=local”

Итак, теперь у нас переменная $objOU содержит информацию о контейнере (имена переменных в PowerShell начинаются со значка доллара).

Вызовем метод Create и создадим в контейнере нового пользователя:

$objUser = $objOU.Create(“user”, “cn=Dmitry Sotnikov”)

Теперь мы можем устанавливать различные атрибуты:

$objUser.Put(«sAMAccountName”, «dsotnikov”)

И наконец, укажем директории, что эти изменения надо применить:

$objUser.SetInfo()

Преимуществами использования адаптера ADSI являются:

• его наличие в любой поставке PowerShell. Если у вас установлен PowerShell и есть директория, с которой вам надо работать, - вы имеете все, что вам надо;
• применение подхода, близкого к VBScript. Если у вас богатый опыт работы с директорией на языке сценариев VBScript или в приложениях.NET, вы сможете уверенно себя чувствовать, используя этот подход.

К сожалению, у метода есть и недостатки:

• сложность - это самый сложный способ работы с директорией. Писать путь к объекту в виде запроса LDAP нетривиально. Для любой работы с атрибутами требуется указание их внутренних имен, а значит, надо помнить, что атрибут, обозначающий город пользователя, называется не «City», а «l» и т.д.;
• громоздкость - как видно из примера, простейшая операция создания одной учетной записи занимает как минимум четыре строчки, включая служебные операции подсоединения к контейнеру и применения изменений. Таким образом, даже относительно простые операции становятся похожи на сложные сценарии.

Провайдер AD

PowerShell позволяет представлять различные системы в виде дополнительных дисков компьютера с помощью так называемых провайдеров. Например, в состав поставки PowerShell входит провайдер реестра и мы можем перемещаться по реестру с помощью знакомых и любимых всеми нами команд cd и dir (для любителей UNIX команда ls тоже поддерживается).

Провайдера Active Directory в составе PowerShell нет, но его можно установить, зайдя на сайт проекта расширений PowerShell - PowerShell Community Extensions: http://www.codeplex.com/PowerShellCX .

Это проект с открытым кодом, который добавляет большое количество команд в систему PowerShell, а кроме того, устанавливает провайдера AD.

Использование провайдера Active Directory

После установки расширений, набрав Get-PSDrive, мы видим, что к прежним дискам добавился диск текущей активной директории.

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

Кроме того, можно вызывать и другие привычные команды управления файлами (например, del).

К несомненным преимуществам использования провайдера можно отнести:

естественность представления структуры директории - директория AD по своей природе иерархична и похожа на файловую систему;

удобство нахождения объектов - применять cd и dir куда удобнее, чем составлять запрос на языке LDAP.

Из недостатков бросаются в глаза:

• сложность внесения изменений в объекты - провайдер помогает легко добраться до объекта, но чтобы что-либо поменять, нам опять приходится использовать все те же директорные объекты, что и в методе ADSI, а для этого надо оперировать на низком уровне служебных методов и атрибутов AD;
• необходимость дополнительной установки - провайдер не входит в состав PowerShell, и для его применения необходимо скачать и установить расширения PowerShell;
• третьестороннее происхождение - расширения PowerShell не являются продуктом компании Microsoft. Они созданы энтузиастами проекта. Вы вольны их использовать, но за технической поддержкой придется обращаться не в Microsoft, а на сайт проекта.

Командлеты AD

Кроме описанного выше провайдера, для работы с AD существует и набор командлетов (часто называемых также AD cmdlets или QAD cmdlets), доступный с сайта http://www.quest.com/activeroles_server/arms.aspx .

Командлеты состоят из стандартных глаголов операций (get-, set-, rename-, remove-, new-, move-, connect-) и существительных объектов с префиксом QAD (-QADUser, -QADGroup, -QADComputer, -QADObject).

Например, чтобы создать новую четную запись пользователя, понадобится выполнить такую команду:

Преимущества данного подхода таковы:

• простота - использование командлетов скрывает от вас сложность директории, ее схемы и внутренних атрибутов. Вы работаете с объектами директории на уровне понятных названий объектов (user, group, computer), их свойств (name, password, city, department) и действий над ними (get, set, remove, move, new);
• краткость и выразительность - как мы видели, большую часть действий с помощью командлетов можно выразить в виде простых и естественных однострочных операций.

• необходимость дополнительной установки - командлеты, как и провайдер, не входят в состав PowerShell, и для их использования необходимо скачать и установить соответствующую библиотеку;
• третьестороннее происхождение - командлеты для работы с AD не являются продуктом компании Microsoft. Они созданы партнером Microsoft - компанией Quest Software. Вы вольны их применять, но за технической поддержкой придется обращаться не в Microsoft, а на форумы по работе с Active Directory на сайте PowerGUI.org.

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

Управление Active Directory

Давайте посмотрим, как PowerShell позволяет выполнять основные операции по работе с директорией AD:

• получение информации;
• изменение свойств;
• работа с группами;
• создание новых объектов;
• изменение структуры директории

Получение информации

Получение информации осуществляется в PowerShell с помощью командлетов с глаголом Get.

Например, чтобы получить список всех пользователей, наберем:

Для групп:

Для записей компьютеров:

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

Получение списка пользователей

Все группы из контейнера Users:

Get-QADGroup -SearchRoot scorpio.local/users

Все пользователи из отдела продаж московского офиса, чьи имена начинаются на букву A:

Get-QADUser -City Moscow -Department Sales -Name a*

При этом вы можете сказать PowerShell’y, в каком виде вы хотите видеть получаемую информацию.

Таблица с именами, городами и подразделениями сотрудников:

Get-QADUser | Format-Table Name, City, Department

То же самое с сортировкой по городам:

Get-QADUser | Sort City | Format-Table DisplayName, City, Department

Сортировка значений и выбор полей для вывода

Для списочного представления той же информации просто используем команду Format-List:

Get-QADUser | Format-List Name, City, Department

Экспортировать информацию в файл CSV (comma-separated values - значения через запятую):

Get-QADUser | Select Name, City, Department | Out-CSV users.csv

Создать отчет в формате HTML:

Get-QADUser | Select Name, City, Department | ConvertTo-HTML | Out-File users.html

Таким образом, одной строчкой простой команды PowerShell вы можете создавать сложные отчеты в удобном для вас формате.

PowerShell позволяет менять атрибуты множества
записей одной командой

Изменение свойств

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

Свойствами объектов можно манипулировать с помощью команд Set-*.

Например, поменяем мне телефон:

Set-QADUser ‘Dmitry Sotnikov’ -Phone ‘111-111-111’

Но, разумеется, куда более интересны массовые изменения. Для этого мы можем применять конвейер PowerShell, то есть получать список нужных нам объектов с помощью команд Get- и отправлять их в команду Set- для внесения изменений.

Например, наш пермский офис переехал в новое помещение. Возьмем всех пользователей Перми и присвоим им новый номер телефона:

Get-QADUser -City Perm | Set-QADUser -PhoneNumber ‘+7-342-1111111’

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

Get-QADUser | ForEach-Object { Set-QADUser $_ -Description (S_.City + « « + $_.Department) }

Переменная $_ в данном примере обозначает текущий объект коллекции.

PowerShell предоставляет возможности удобной работы
с группами пользователей

Работа с группами

Работа с группами и членством в них - еще одна массовая операция, которую часто хочется автоматизировать. PowerShell предоставляет такую возможность.

Получение членов группы производится с помощью командлета Get-QADGroupMember:

Get-QADGroubMember Managers

Добавить объект в группу тоже несложно:

Add-QADGroupMember Scorpio\Managers -Member dsotnikov

Аналогично удаление из группы осуществляется с помощью командлеты Remove-QADGroupMember.

Но, разумеется, наиболее полезными являются массовые манипуляции. Добавим всех менеджеров в соответствующую группу:

Get-QADUser -Title Manager | Add-QADGroupMember Scorpio\Managers

Скопируем членство в группе:

Get-QADGroupMember Scorpio\Managers | Add-QADGroupMember Scorpio\Managers_Copy

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

Get-QADGroupMember Scorpio\Managers | where { $_.City -eq ‘Ekaterinburg’} | Add-QADGroupMember Scorpio\Ekaterinburg_Managers

Обратите внимание, как мы отфильтровали пользователей с помощью команды where и логического условия (логический оператор -eq - это оператор равенства в PowerShell, от англ. equals).

Создание объектов

Создание объектов, как мы уже видели, осуществляется командами New:

New-QADUser -ParentContainer scorpio.local/Employees -Name ‘Dmitry Sotnikov’

New-QADGroup -ParentContainer scorpio.local/Employees -Name ‘Managers’ -Type Security -Scope Global

Вы можете установить и любые другие атрибуты в процессе создания записи:

New-QADUser -ParentContainer scorpio.local/Employees -Name ‘Dmitry Sotnikov’ -samAccountName dsotnikov -City ‘Saint-Petersburg’ -Password ‘P@ssword’

Чтобы активировать запись, просто отправьте ее по конвейеру в Enable-QADUser (не забудьте установить пароль - иначе операция не пройдет):

New-QADUser -ParentContainer scorpio.local/Employees -Name ‘Dmitry Sotnikov’ -Password ‘P@ssword’ | Enable-QADUser

Import-CSV new_users.csv | ForEach-Object { New-QADUser -ParentContainer scorpio.local/users -Name ($_.Familia + ‘, ’ + $_.Imya) -samAccountName ($_.Imya + $_.Familia) -Department $_.Department -Title $_.Title}

Обратите внимание на то, что мы на лету составляем название учетной записи из фамилии и имени пользователя.

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

Изменение структуры директории

И наконец, конечно же, можно управлять структурой директории.

Например, можно создавать новые контейнеры:

New-QADObject -type OrganizationUnit -ParentContainer scorpio.local -Name NewOU

и перемещать в них объекты по одному:

Move-QADObject MyServer -To scorpio.local/servers

или оптом:

Get-QADUser -Disabled | Move-QADObject -To scorpio.local/Disabled

Импортируем файл и создаем новые учетные записи

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

И многое другое

ММы рассмотрели только малую часть сценариев по управлению активной директорией. Чтобы получить полный перечень командлетов для AD, выполните команду:

Get-Command *-QAD*

Чтобы получить справку по любой команде:

Get-Help Get-QADUser

Чтобы узнать, какие свойства есть у выдаваемого командой объекта:

Get-User | Get-Member

Возможности PowerShell практически безграничны, но при этом найти их достаточно легко.

Заключение

ККак мы видели, PowerShell является отличным средством управления Active Directory. Часть свойств (ADSI) доступна в любой установке PowerShell. Некоторые (провайдер и командлеты) требуют дополнительных модулей. Все они предоставляют огромные возможности, чтобы автоматизировать управление вашей корпоративной директорией, а значит, уменьшить риски, избавиться от рутины и увеличить вашу эффективность на работе.

Главное - эти технологии уже доступны и способны помочь вам в администрировании вверенных систем уже сегодня. В заключение процитируем системного администратора ЗАО «УК «ЕвразФинанс» Василия Гусева: «В нашей компании, как и практически везде, Active Directory является одним из самых используемых и критичных сервисов. С помощью PowerShell и AD Cmdlets многие задачи стало проще выполнять через командную строку, нежели через ADUC (Active Directory Users and Computers. - Прим. ред .). Никогда еще автоматизация Active Directory не была столь легкой и доступной».

Посвященную использования PowerShell для администрирования AD. В качестве исходного пункта автор решил взять 10 типичных задач администрирования AD и рассмотреть то, как их можно упростить, используя PowerShell:

1. Сбросить пароль пользователя
2. Активировать и деактивировать учетные записи
3. Разблокировать учетную запись пользователя
4. Удалить учетную запись
5. Найти пустые группы
6. Добавить пользователей в группу
7. Вывести список членов группы
8. Найти устаревшие учетные записи компьютеров
9. Деактивировать учетную запись компьютера
10. Найти компьютеры по типу

Помимо этого автор ведет блог (по PowerShell, конечно), рекомендуем заглянуть - jdhitsolutions.com/blog . А самое актуальное Вы можете получить из его твиттера twitter.com/jeffhicks .
Итак, ниже приводим перевод статьи “Top 10 Active Directory Tasks Solved with PowerShell”.

Управление Active Directory (AD) с помощью Windows PowerShell – это проще, чем Вы думаете, и я хочу доказать Вам это. Вы можете просто взять приведенные ниже скрипты и с их помощью решить ряд задач по управлению AD.

Требования

Чтобы использовать PowerShell для управления AD, нужно соблюсти несколько требований. Я собираюсь продемонстрировать, как командлеты для AD работают на примере компьютера на Windows 7.
Чтобы использовать командлеты, контроллер домена у Вас должен быть уровня Windows Server 2008 R2, или же Вы можете скачать и установить Active Directory Management Gateway Service на наследуемых контроллерах домена (legacy DCs). Внимательно прочитайте документацию перед установкой; требуется перезагрузка КД.
На стороне клиента, скачайте и установите (RSAT) либо для Windows 7 , либо для Windows 8 . В Windows 7, Вам необходимо будет открыть в Панели управления (Control Panel) раздел Программы (Programs) и выбрать Включить или выключить функции Windows (Turn Windows Features On or Off) . Найдите Remote Server Administration Tools и раскройте раздел Role Administration Tools . Выберите подходящие пункты для AD DS and AD LDS Tools, особенно обратите внимание на то, что должен быть выбран пункт Active Directory Module for Windows PowerShell , как показано на рисунке 1. (В Windows 8 все инструменты выбраны по умолчанию). Теперь мы готовы работать.

Рис.1 Включение AD DS и AD LDS Tools

Я вошел в систему под учетной записью с правами доменного администратора. Большинство командлетов, которые я буду показывать, позволят Вам уточнить альтернативные полномочия (credentials). В любом случае я рекомендую прочитать справку (Get-Help ) и примеры, которые я буду демонстрировать ниже.
Начните сессию PowerShell и импортируйте модуль:

PS C:\> Import-Module ActiveDirectory

В результате импорта создается новый PSDrive, но мы не будем использовать его. Однако, Вы можете посмотреть, какие команды имеются в импортированном модуле.

PS C:\> get-command -module ActiveDirectory

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

Задача 1: Сброс пароля пользователя

Давайте начнем с типичной задачи: сброс пароля пользователя. Сделать это легко и просто можно через командлет Set-ADAccountPassword . Сложная часть заключается в том, что новый пароль должен быть уточнен как защищенная строка: фрагмент текста, который зашифрован и хранится в памяти на протяжении PowerShell сессии. Во-первых, создадим переменную с новым паролем:
PS C:\> $new=Read-Host "Enter the new password" -AsSecureString

Затем, введем новый пароль:

Теперь мы можем извлечь учетную запись (использование samAccountname – лучший вариант) и задать новый пароль. Вот пример для пользователя Jack Frost:

PS C:\> Set-ADAccountPassword jfrost -NewPassword $new

К сожалению, в случае с этим командлетом наблюдается баг: -Passthru , -Whatif , и –Confirm не работают. Если Вы предпочитаете короткий путь, попробуйте следующее:

PS C:\> Set-ADAccountPassword jfrost -NewPassword (ConvertTo-SecureString -AsPlainText -String "P@ssw0rd1z3" -force)

В итоге мне необходимо, чтобы Jack сменил пароль при следующем входе в систему, и я модифицирую учетную запись используя Set-ADUser .

PS C:\> Set-ADUser jfrost -ChangePasswordAtLogon $True

Результаты выполнения командлета не пишутся в консоль. Если это необходимо сделать, используйте –True . Но я могу узнать, успешно или нет прошла операция, произведя извлечения имени пользователя с помощью командлета Get-ADUser и уточнив свойство PasswordExpired , как показано на рисунке 2.

Рис. 2. Результаты работы командлета Get-ADUser Cmdlet со свойством PasswordExpired

Итог: сбросить пароль пользователя с помощью PowerShell совсем не сложно. Признаюсь, что сбросить пароль также просто через оснастку Active Directory Users and Computers консоли Microsoft Management Console (MMC). Но использование PowerShell подходит в том случае, если Вам необходимо делегировать задачу, Вы не хотите разворачивать вышеупомянутую оснастку или сбрасываете пароль в ходе большого автоматизированного ИТ-процесса.

Задача 2: Активировать и деактивировать учетные записи

А теперь давайте деактивируем учетную запись. Продолжим работать с Jack Frost. Этот код использует параметр –Whatif , который Вы можете встретить в других комадлетах, которые осуществляют изменения, чтобы проверить мою команду не запуская ее.

PS C:\> Disable-ADAccount jfrost -whatif What if: Performing operation "Set" on Target "CN=Jack Frost, OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".

А теперь деактивируем по-настоящему:

PS C:\> Disable-ADAccount jfrost

А когда настанет время активировать учетную запись, какой командлет нам поможет?

PS C:\> Enable-ADAccount jfrost

Эти командлеты могут быть использованы в конвейерном выражении (pipelined expression), позволяя активировать или деактивировать столько учетных записей, сколько душе угодно. Например, этот код деактивирует все учетные записи в отделе продаж (Sales)

PS C:\> get-aduser -filter "department -eq "sales"" | disable-adaccount

Конечно, писать фильтр для Get-ADUser довольно-таки сложно, но именно здесь использование параметра –Whatif вместе с командлетом Disable-ADAccount приходит на помощь.

Задача 3: Разблокировать учетную запись пользователя

Рассмотрим ситуацию, когда Jack заблокировал свою учетную запись, пытаясь ввести новый пароль. Вмест того, чтобы пытаться найти его учетную запись через GUI, процедуру разблокировки можно осуществить с помощью простой команды.

PS C:\> Unlock-ADAccount jfrost

Командлет также поддерживает параметры -Whatif и -Confirm .

Задача 4: Удалить учетную запись

Неважно, сколько пользователей Вы удаляете, - это просто осуществить с помощью командлета Remove-ADUser . Мне не хочется удалять Jack Frost, но если бы я захотел, то использовал бы такой код:

PS C:\> Remove-ADUser jfrost -whatif What if: Performing operation "Remove" on Target "CN=Jack Frost,OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".

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

PS C:\> get-aduser -filter "enabled -eq "false"" -property WhenChanged -SearchBase "OU=Employees, DC=Globomantics,DC=Local" | where {$_.WhenChanged -le (Get-Date).AddDays(-180)} | Remove-ADuser -whatif

С помощью этой команды будут найдены и удалены все деактивованные учетные записи подразделения (OU) Employees, которые не менялись в течение 180 и более дней.

Задача 5: Поиск пустых групп

Управление группами – занятие бесконечное и неблагодарное. Существует множество способов найти пустые группы. Некоторые выражения могут работать лучше, чем другие, в зависимости от Вашей организации. Код, приведенный ниже, позволит найти все группы в домене, включая встроенные (built-in).

PS C:\> get-adgroup -filter * | where {-Not ($_ | get-adgroupmember)} | Select Name

Если у Вас есть группы с сотнями членов, тогда использование этой команды может занять много времени; Get-ADGroupMember проверяет каждую группу. Если Вы можете ограничить или настроить, это будет лучше.
Вот еще один подход:

PS C:\> get-adgroup -filter "members -notlike "*" -AND GroupScope -eq "Universal"" -SearchBase "OU=Groups,OU=Employees,DC=Globomantics, DC=local" | Select Name,Group*

Эта команда находит все универсальные группы (Universal groups), которые не имеют членство в OU Groups и выводит некоторые из свойств. Результат приведен на рисунке 3.


Рис. 3. Поиск и фильтрация универсальных групп

Задача 6: Добавление пользователей в группу

Давайте добавим Jack Frost в группу Chicago IT:

PS C:\> add-adgroupmember "chicago IT" -Members jfrost

Да, все так просто. Вы можете также легко добавлять сотни пользователей в группы, хотя, на мой взгляд, это слегка неудобно:

PS C:\> Add-ADGroupMember "Chicago Employees" -member (get-aduser -filter "city -eq "Chicago"")

Я использовал вводное конвейерное выражение (parenthetical pipelined expression), чтобы найти всех пользователей, у которых имеется свойство City в Chicago. Код в скобках выполняется, и полученные объекты передаются в параметр –Member. Каждый пользовательский объект добавляется в группу Chicago Employees. Неважно, имеем ли мы дело с 5 или 5000 пользователей, обновление членства в группах занимает всего несколько секунд. Это выражение может также быть написано с использованием ForEach-Object , что может быть удобнее:

PS C:\> Get-ADUser -filter "city -eq "Chicago"" | foreach {Add-ADGroupMember "Chicago Employees" -Member $_}

Задача 7: Выводим список членов группы

Вы возможно захотите узнать, кто находится в определенной группе. Например, Вы должны периодически узнавать, кто входит в группу доменных администраторов (Domain Admins):

PS C:\> Get-ADGroupMember "Domain Admins"

На рисунке 4 приведен результат.

Рис. 4. Члены группы Domain Admins

Командлет выводит объект AD для каждого члена группы. А что делать с вложенными группами? Моя группа Chicago All Users является коллекцией вложенных групп. Чтобы получить список всех учетных записей, я всего лишь должен использовать параметр –Recursive .

PS C:\> Get-ADGroupMember "Chicago All Users" -Recursive | Select DistinguishedName

Если Вы хотите пойти другим путем – найти, в каких группах пользователь состоит, - используйте свойство пользователя MemberOf :

PS C:\> get-aduser jfrost -property Memberof | Select -ExpandProperty memberOf CN=NewTest,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Test,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago IT,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Sales Users,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local

Я использовал параметр -ExpandProperty , чтобы вывести имена MemberOf как строки.

Задача 8: Найти устаревшие учетные записи компьютеров

Мне часто задают этот вопрос: “Как найти устаревшие учетные записи компьютеров?”. И я всегда отвечаю: “А что для вас является устаревшим?” Компании по-разному определяют то, когда учетная запись компьютера (или пользователя, неважно), признается устаревшей и не подлежит дальнейшему использованию. Что касается меня, то я обращаю внимание на те учетные записи, у которых пароли не менялись в течение определенного периода времени. Этот период для меня составляет 90 дней – если компьютер не сменил пароль вместе с доменом за этот период, скорее всего он находится оффлайн и является устаревшим. Используется командлет Get-ADComputer :

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Select name,passwordlastset

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

Рис. 5. Находим устаревшие учетные записи компьютеров

Другой вариант: предположим, вы хотя бы на функциональном уровне домена Windows 2003. Поставьте фильтр по свойству LastLogontimeStamp . Это значение – число 100 наносекундных интервалов с 1 января, 1601 года, и храниться в GMT, поэтому работа с этим значением слегка сложно:

PS C:\> get-adcomputer -filter "LastlogonTimestamp -gt 0" -properties * | select name,lastlogontimestamp, @{Name="LastLogon";Expression={::FromFileTime ($_.Lastlogontimestamp)}},passwordlastset | Sort LastLogonTimeStamp

Рис. 6. Конвертируем значение LastLogonTimeStamp в привычный формат

Чтобы создать фильтр, мне необходимо конвертировать дату, например, 1 января 2012, в корректный формат. Конвертация осуществляется в FileTime:

PS C:\> $cutoff=(Get-Date "1/1/2012").ToFileTime() PS C:\> $cutoff 129698676000000000

Теперь я могу использовать эту переменную в фильтре для Get-ADComputer :

PS C:\> Get-ADComputer -Filter "(lastlogontimestamp -lt $cutoff) -or (lastlogontimestamp -notlike "*")" -property * | Select Name,LastlogonTimestamp,PasswordLastSet

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

Задача 9: Деактивировать учетную запись компьютера

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

PS C:\> Disable-ADAccount -Identity "chi-srv01$" -whatif What if: Performing operation "Set" on Target "CN=CHI-SRV01, CN=Computers,DC=GLOBOMANTICS,DC=local".

Или же использовав конвейерное выражение:

PS C:\> get-adcomputer "chi-srv01" | Disable-ADAccount

Я также могу использовать мой код, чтобы найти устаревшие учетные записи и все их деактивировать:

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Disable-ADAccount

Задача 10: Найти компьютеры по типу

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

PS C:\> Get-ADComputer -Filter * -Properties OperatingSystem | Select OperatingSystem -unique | Sort OperatingSystem

Результаты показаны на рисунке 7.

Рис. 7. Извлечение списка ОС

Я хочу найти все компьютеры, на которых стоит серверная ОС:

PS C:\> Get-ADComputer -Filter "OperatingSystem -like "*Server*"" -properties OperatingSystem,OperatingSystem ServicePack | Select Name,Op* | format-list

Результаты приведены на рисунке 8.

Как и другими командлетами AD Get, Вы можете настроить поисковые параметры и ограничить запрос отдельными OU, если это необходимо. Все выражения, которые я показал, могут быть интегрированы в большие PowerShell выражения. Например, Вы можете сортировать, группировать, применять фильтры, экспортировать в CSV или создавать и отправлять на почту HTML отчеты – и все это из PowerShell! При этом Вам не придется писать ни единого скрипа.
Вот Вам бонус: отчет о возрасте пароля пользователя (user password-age report), сохраненный в HTML файле:

PS C:\> Get-ADUser -Filter "Enabled -eq "True" -AND PasswordNeverExpires -eq "False"" -Properties PasswordLastSet,PasswordNeverExpires,PasswordExpired | Select DistinguishedName,Name,pass*,@{Name="PasswordAge"; Expression={(Get-Date)-$_.PasswordLastSet}} |sort PasswordAge -Descending | ConvertTo-Html -Title "Password Age Report" | Out-File c:\Work\pwage.htm

Хотя это выражение может выглядеть слегка пугающим, при минимальном знании PowerShell им легко воспользоваться. И остается лишь последний совет: как определить кастомное свойство под названием PasswordAge . Значение представляет собой промежуток между сегодняшним днем и свойством PasswordLastSet. Затем я сортирую результаты для моего нового свойства. На рисунке 9 показан выход для моего небольшого тестового домена.

Upd:
В посте приведен перевод статьи на портале

В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.

Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.

Стандартизация
Планирование Active Directory следует начать с разработки своих стандартов назначения имен объектов и их расположения в каталоге. Необходимо создать документ, в котором определить все необходимые стандарты. Конечно, это довольно частая рекомендация для ИТ специалистов. Принцип «сначала пишем документацию, а потом по данной документации строим систему» является очень хорошим, но он редко реализуем на практике по многим причинам. Среди этих причин - простая человеческая лень или отсутствие соответствующей компетенции, остальные причины являются производными от первых двух.
Рекомендую - сначала напишите документацию, все обдумайте и только потом приступайте к инсталляции первого контроллера домена.
Для примера приведу раздел документа по стандартам названия объектов Active Directory.
Именование объектов.

• Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
• Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
• Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
• Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
• Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
• Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
• Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.

Рекомендую называть объекты Active Directory таким образом, чтобы вам не приходилось заполнять поле «Description». Например, из названия группы GPCP_Restricted_Groups понятно, что это группа для политики, которая применяется для компьютеров и выполняет работу механизма Restricted Groups.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.

Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.

Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.

• Группы пользователей (GRUS_)
• Группы администраторов (GRAD_)
• Группы делегирования (GRDL_)
• Группы политик (GRGP_)

Группы компьютеров

• Группы серверов (GRSR_)
• Группы клиентских компьютеров (GRCP_)

Группы доступа к ресурсам

• Группы доступа к общим ресурсам (GRRS_)
• Группы доступа к принтерам (GRPR_)

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

Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.

Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:

• С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
• С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).

Поле Surname обоих типов административных аккаунтов следует начинать с буквы I (Например, iPetrov P Vasily)
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.

Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.

Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)

Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.

Копирование ADMX-шаблонов

Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.

Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:

• Audit Computer Account Management - Success, Failure
• Audit Other Account Management Events - Success, Failure
• Audit Security Group Management - Success, Failure
• Audit User Account Management - Success, Failure

• Audit Kerberos Authentication Service - Failure
• Audit Other Account Logon Events - Failure
• Audit Audit Policy Change - Success, Failure

Аудит необходимо конфиругировать в разделе Advanced Audit Policy Configuration и обязательно включить настройку в разделел Local Policy/Security Options - Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings , которая отменит настройки верхнего уровня и применит расширенные.

Расширенные настройки аудита

Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.

Скрипты администрирования и уборки
Все однотипные и часто повторяемые действия необходимо выполнять при помощи скриптов администрирования. Среди таких действий: создание аккаунтов пользователей, создание аккаунтов администраторов, создание групп, создание OU и так далее. Создание объектов при помощи скриптов позволит соблюдать вашу логику названия объектов Active Directory, встроив проверки синтаксиса прямо в скрипты.
Также стоит написать скрипты уборки, которые будут в автоматическом режиме контролировать составы групп, выявлять пользователей и компьютеры, которые давно не подключались к домену, выявлять нарушение другие ваших стандартов так далее.
Я не встречал в качестве явной официальной рекомендации использование скриптов администрирования для контроля соблюдения стандартов и выполнения фоновых операций. Но сам предпочитаю проверки и процедуры в автоматическом режиме при помощи скриптов, так как это очень сильно экономит время и избавляет от большого количества ошибок и, конечно, здесь сказывается мой немного юниксовый подход к администрированию, когда проще набрать пару команд, чем щелкать мышкой по окнам.

Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.

Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.

Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.

Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.

Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.

Заключение
Сегодня утром я думал о том, почему человеческий эгоизм не приветствуется в обществе и где-то на глубинном уровне восприятия вызывает крайне отрицательные эмоции. И единственный ответ, который пришел мне в голову, это то, что человеческая раса не выжила бы на этой планете, если бы не научилась совместному использованию физических и интеллектуальных ресурсов. Именно поэтому я и делюсь данной статьей с вами и, надеюсь, что мои рекомендации помогут вам улучшить свои системы, и вы станете значительно меньше тратить времени на поиск и устранение неисправностей. Все это приведет к освобождению большего количества времени и энергии для творчества. Гораздо приятнее жить в мире творческих и свободных людей.
Хорошо, если в комментариях вы по возможности поделитесь своими знаниями и практиками построения Active Directory.
Всем мира и добра!

Вы можете помочь и перевести немного средств на развитие сайта

Всем доброго времени суток, продолжаем наши уроки системного администрирования. Продолжим сегодня разбираться в основных объектах Active Directory. После того, как мы разобрались с планированием Active Directory , первое что нужно создать, это структуру организационных подразделений (OU). Делается это для того, чтобы системный администратор, мог делегировать права на отдельные группы объектов, объединенных по каким-то критериям, применять групповые политики, по тем же соображениям. Если вы организуете себе удобную иерархию, то у вас все будет в AD просто лафа, которая вам сэкономит много времени.

Я создам у себя в AD, структуру такого плана:

• На верху OU территориальной принадлежности. В моем случае это города
• Дальше это OU серверы, пользователи и компьютеры
• Дальше можно уже при необходимости делить на этажи, отделы и все такое, как вашей фантазии придет в голову.

Ну собственно начнем. Открываем Пуск-Администирование-ADUC

Вводим название OU, в моем случае Город. Дальше подобным образом создаем нужное вам количество OU в нужной вам иерархии.

У меня это выглядит вот так. Есть несколько городов, которые содержат в себе дополнительные организационные подразделения:

• Пользователи
• Группы рассылок
• Группы
• Системные учетные записи
• Сервера
• Компьютеры

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

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

Для того чтобы, это поправить и у вас был в Active Directory порядок, идем меню "Вид-Дополнительные компоненты".

Теперь кликаем правым кликом по нужному OU и выбираем свойства.

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

Как видите компания Microsoft сделала процесс создания объектов в Active Directory, очень тривиальным, так как многие вещи, системный администратор просто делегирует, например, на отдел кадров, которые заводят учетные записи. Если остались вопросы, то пишите их в комментариях, рад буду пообщаться.

17.03.2014 Даррен Мар-Элиа

Когда Windows PowerShell только появился, многие стали спрашивать, можно ли управлять Active Directory (AD) с использованием PowerShell. В те времена ответ Microsoft был не таким, какой хотелось бы услышать большинству администраторов. В PowerShell имелся встроенный "акселератор типов" Active Directory Service Interfaces (ADSI) для доступа к объектам AD, но пользователю приходилось в основном самостоятельно выяснять, как применить PowerShell для решения задач администрирования AD. Значительные изменения произошли с выпуском Windows Server 2008 R2, в котором появился модуль PowerShell для Active Directory. В модуль AD входит набор команд для управления AD, а также AD Provider, с помощью которого можно перемещаться по AD, как по диску с символьным обозначением. В этой статье я покажу, как установить модуль AD, и подробно опишу его функционирование

Когда Windows PowerShell только появился, многие стали спрашивать, можно ли управлять Active Directory (AD) с использованием PowerShell. В те времена ответ Microsoft был не таким, какой хотелось бы услышать большинству администраторов. В PowerShell имелся встроенный «акселератор типов» Active Directory Service Interfaces (ADSI) для доступа к объектам AD, но пользователю приходилось в основном самостоятельно выяснять, как применить PowerShell для решения задач администрирования AD. Спустя некоторое время компания Quest Software предоставила бесплатный набор команд для административных задач AD, в том числе создания, изменения и удаления объектов AD, и поиска объектов в AD. В течение длительного периода состояние PowerShell и управления AD было таким.

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

Установка Active Directory Module

В отличие от предыдущих инструментов, в которых для связи с AD применялся протокол LDAP, модуль AD использует протоколы Active Directory Web Services (ADWS) для обмена данными с контроллером домена (DC) AD. Эти протоколы подробно описаны в блоге MSDN «Active Directory Web Services Overview», но достаточно отметить, что команды PowerShell в модуле AD и Active Directory Administrative Center (ADAC) используют ADWS для связи и получения информации из AD.

При установке контроллеров домена Windows Server 2012 или Server 2008 R2 в домене AD протокол ADWS устанавливается и запускается по умолчанию на каждом из них. Если ваш домен состоит целиком из контроллеров домена Windows Server 2008 или Windows Server 2003, необходимо установить ADWS отдельно. Microsoft бесплатно предоставляет пакет Active Directory Management Gateway Service для этой цели. Если установить пакет по крайней мере на одном контроллере домена AD Server 2008 или Server 2003, то можно использовать модуль AD для PowerShell наряду с ADAC.

Собственно модуль AD устанавливается по умолчанию на любом DC с операционной системой Server 2012 или Server 2008 R2. На компьютерах Windows 8 и Windows 7 (или любом компьютере, кроме DC, работающем с Server 2012 или Server 2008 R2), необходимо установить средства удаленного администрирования сервера Remote Server Administration Tools из центра загрузки Microsoft.

Независимо от того, установлены Remote Server Administration Tools на компьютере заранее или отдельно, следующий шаг - открыть раздел установки и удаления программ Add/Remove Programs в панели управления и выбрать пункт включения или отключения компонентов Windows - Turn Windows features on or off - в меню слева. Прокрутите диалоговое окно компонентов Windows Feature вниз до раздела Remote Server Administration Tools. Найдите флажок Active Directory Module for Windows PowerShell в папке \Remote Server Administration Tools\Role Administration Tools\AD DS and AD LDS Tools, как показано на экране 1. Установите флажок и нажмите кнопку OK, чтобы установить модуль.

После этого вы должны увидеть ярлык Active Directory Module for Windows PowerShell в разделе Administrative Tools меню Start. Щелкните этот ярлык, чтобы запустить PowerShell с загруженным модулем AD. Если вы уже работаете в PowerShell и хотите просто загрузить модуль, чтобы он стал доступным для использования, можно ввести следующую команду и получить доступ к командам AD и AD Provider:

Import-Module ActiveDirectory

Теперь посмотрим, как перемещаться по AD с помощью AD Provider.

Использование Active Directory Provider

В PowerShell реализована концепция дисков PowerShell, которые я буду называть просто дисками PS. Упрощенно можно назвать диск PS представлением ресурса, такого как пригодная для навигации файловая система, состоящая из папок и конечных элементов. Не каждый ресурс можно представить таким образом, но многие (в том числе AD и реестр) хорошо вписываются в эту модель. Модуль AD содержит провайдера для диска PS AD. Соответственно, можно перемещаться и даже изменять AD, как будто это файловая система.

Как же перемещаться по AD, используя AD Provider? Предполагается, что PowerShell открыт и модуль AD загружен. В этом случае первый шаг - запустить команду Set-Location, которая имеет несколько псевдонимов, в том числе sl и cd:

Set-Location AD:

Эта команда изменяет текущее рабочее положение диска PS AD. В результате приглашение PowerShell покажет AD:\ вместо C:\. Затем, чтобы увидеть элементы в диске PS AD, можно применить команду Get-ChildItem с псевдонимом dir:

Get-ChildItem

На экране 2 показан пример результата на моем компьютере.

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

Set-Location «dc=cpandl,dc=com»

Обратите внимание, что используется команда Set-Location с различающимся именем (DN) моего домена AD. Это требуется для корректной навигации. После перехода в каталог домена (на что указывает приглашение AD:\dc=cpandl,dc=com в PowerShell), можно использовать команду Get-ChildItem, чтобы увидеть структуру AD верхнего уровня (экран 3).

Экран 3. Просмотр верхнего уровня иерархии AD

Если нужно взглянуть на пользователей в организационной единице (OU) SDM, то для перехода в эту OU достаточно ввести:

Set-Location «OU=SDM»

Командная строка PowerShell будет иметь вид AD:\ou=SDM,dc=cpandl,dc=com. На данном этапе можно использовать команду Get-ChildItem, чтобы увидеть все объекты пользователя в этом OU. Если нужно изменить свойство Description на объекте пользователя, представляющем мою учетную запись пользователя Darren Mar-Elia. Для этого есть команда! Команда Set-ItemProperty позволяет изменить свойство в объекте AD. Если нужно изменить описание учетной записи пользователя на Chief Techie, следует выполнить команду:

Set-ItemProperty -Path ".\CN=Darren Mar-Elia" ` -Name «Description» -Value «Chief Techie»

Как мы видим, здесь используется параметр –Path для указания моей учетной записи пользователя в текущем каталоге. Я также использую параметр -Name, дабы указать, что нужно изменить свойство Description, и параметр –Value, для указания описания Chief Techie.

Обратите внимание, что если нужно найти все объекты с определенным значением свойства, можно задействовать Get-ItemProperty. Если требуется просто получить ссылку на объект AD, используйте Get-Item.

Как видите, работать с AD таким образом довольно просто. Механизм вряд ли подходит для массовых изменений, однако он удобен для работы с AD как с файловой системой. При этом, как я выяснил, большинство администраторов использует команды вместо диска PS AD для управления AD. Посмотрим, как действуют некоторые из этих команд.

Применение команд Active Directory

Модуль для AD, поставляемый с Windows 7, содержит 76 команд для управления AD. Их можно использовать почти для любых целей, в том числе поиска объектов AD, создания и удаления объектов AD и манипуляций с информацией о настройках AD (например, режим леса и детальная политика паролей). Обычно команды группируются по глаголам, таким как Add-, Remove-, Get- и Set-. Обратите внимание, что не каждая команда Get- имеет соответствующую команду Set- и наоборот, поэтому иногда приходится потратить усилия, чтобы найти нужную команду для задачи. Например, можно установить уровень функциональности леса AD с использованием Set-ADForestMode, но чтобы выяснить текущий уровень функциональности леса, необходимо задействовать команду Get-ADForest и посмотреть свойство ForestMode на возвращенном объекте.

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

Добавление учетных записей пользователя

Команда New-ADUser обеспечивает простой способ добавлять учетные записи пользователя в AD. Если нужно добавить новую учетную запись пользователя с именем Bill Smith в организационную единицу SDM, то в самом простом случае можно создать учетную запись нового пользователя с помощью команды:

New-ADUser -Name «Bill Smith» -SamAccountName «bsmith» ` -GivenName «Bill» -Surname «Smith» ` -DisplayName «Bill Smith» -Path «OU=SDM,DC=cpandl,DC=com»

В этой команде вводится основная информация об учетной записи пользователя. В частности, параметр -SamAccountName служит для предоставления имени учетной записи SAM, необходимой для создания объекта пользователя. Также применяется параметр –Path, чтобы сообщить команде место, куда следует поместить объект - в данном случае в организационную единицу SDM в домене cpandl.com. Кроме того, указано имя пользователя (параметр -GivenName), фамилия (параметр -Surname) и отображаемое имя (параметр -DisplayName).

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

Чтобы избежать необходимости активировать учетную запись и назначать пароль отдельно, можно изменить команду New-ADUser. New-ADUser автоматически активирует учетную запись, если указать параметр -Enabled $true в команде. Для активирования требуется пароль, поэтому необходимо также указать его в команде.

Чтобы предоставить пароль, можно использовать параметр –AccountPassword. Однако нельзя ввести пароль простым текстом в командной строке. Этот параметр требует, чтобы пароль был введен в защищенной строке (то есть имел тип данных SecureString). Существует два способа преобразовать пароль в защищенную строку, и в обоих случаях используется переменная.

В первом методе применяется команда ConvertTo-SecureString, которая преобразует строки простого текста в защищенные строки. Например, если нужно преобразовать пароль P@ssw0rd12 в защищенную строку и назначить его переменной $pwd, следует выполнить команду:

$pwd = ConvertTo-SecureString -string «P@ssw0rd12» ` -AsPlainText –force

Это не самый безопасный метод назначения пароля, так как кто-то может заглянуть вам через плечо при вводе команды. Более надежный способ, если команда New-ADUser запросит пароль и будет скрывать вводимые символы. Это можно сделать с помощью команды Read-Hostcmdlet с параметром –AsSecureString:

$pwd = Read-Host -AsSecureString

После выполнения этой команды вы увидите на экране знакомый символ «*" при вводе пароля. Завершив ввод, нажмите клавишу Enter.

После того, как пароль сохранен в переменной $pwd, можно передать его в команду New-ADUser:

New-ADUser -Name»Bill Smith«-SamAccountName»bsmith«` -GivenName»Bill«-Surname»Smith«` -DisplayName»Bill Smith«` -Path»OU=SDM,DC=cpandl,DC=com«` -Enabled $true -AccountPassword $pwd

Как мы видим, команда содержит параметры -Enabled и –AccountPassword, которые активируют учетную запись и безопасно назначают ей пароль.

Создание пользовательских учетных записей по одной - аккуратный способ, но иногда требуется создать несколько учетных записей одновременно. PowerShell прекрасно подходит для этой цели. Например, если нужно создать три учетных записи пользователя, то можно подготовить файл с разделением запятыми (CSV), который содержит информацию об учетной записи, а затем использовать команду Import-CSV для передачи этой информации в New-ADUser.

На экране 4 показан файл CSV с именем userlist.csv.

Обратите внимание, что в этом файле заголовки столбцов соответствуют именам параметров, предоставленных в предыдущей команде New-ADUser. Это сделано специально. Когда данные CSV передаются в New-ADUser, команда выберет эти имена параметров из конвейера PowerShell и их не придется указывать в самой команде. Вот команда, применявшаяся для создания трех учетных записей пользователя:

Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pwd

Как можно заметить, выходные строки команды Import-CSV поступают в команду New-ADUser. Конвейер распознает, что заголовки столбца в CSV-файле представляют собой имена параметров, а остальные строки содержат значения, поэтому нужно лишь предоставить параметры -Enabled и –AccountPassword. Это превосходная возможность конвейера. Благодаря ей удается гораздо эффективнее использовать PowerShell для задач автоматизации такого типа.

Управление членством в группах

Добавление учетных записей пользователей и компьютеров - типичная задача управления AD. С помощью модуля AD выполнить ее сравнительно несложно. Используя команду Add-ADGroupMember, можно добавить в группу одну или несколько учетных записей. Например, если нужно добавить трех новых пользователей в группу Marketing Users. Самый простой способ - использовать команду:

Add-ADGroupMember -Identity»Marketing Users«` -Members jadams,tthumb,mtwain

В этой команде параметр -Identity служит для того, чтобы предоставить имя группы. Также применяется параметр -Members для предоставления имен учетных записей SAM пользователей. Если имеется несколько имен учетных записей SAM, то их следует указать в файле с разделителями в виде запятых.

Можно объединить операции создания трех учетных записей и их добавления в группу Marketing Users в одной команде, чтобы решить задачу одним действием. Однако команда Add-ADGroupMember не поддерживает передачу имен членов группы в конвейер. Поэтому необходимо использовать команду Add-ADPrincipalGroupMembership, если требуется задействовать конвейер. Эта команда может принимать объекты пользователя, компьютера или группы как входные из конвейера и добавлять эти объекты в указанную группу.

Соединить операцию создания пользователей с операцией добавления новых пользователей в группу Marketing Users в одной команде можно следующим образом:

Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pass ` -PassThru | Add-ADPrincipalGroupMembership ` -MemberOf»Marketing Users«

Обратите внимание, что к части New-ADUser команды добавлен параметр –PassThru. Этот параметр указывает New-ADUser, что нужно передать созданные объекты пользователя в конвейер. Если данный параметр не указан, то выполнение команды Add-ADPrincipalGroupMembership завершится неудачей.

Также примечательно, что используется только параметр -MemberOf для указания имени группы в разделе Add-ADPrincipalGroupMembership команды. Конвейер обеспечивает остальное, добавляя каждого из трех пользователей в группу Marketing Users.

Итак, с помощью одной команды PowerShell было создано три новых пользователя, они были размещены в OU, получили пароли и были добавлены в группу Marketing Users. Теперь рассмотрим некоторые другие типичные задачи обслуживания AD, которые можно автоматизировать с использованием PowerShell и модуля AD.

Сброс паролей учетных записей пользователя

Иногда пользователям требуется сбросить пароль учетной записи. Эту задачу легко автоматизировать с помощью команды Set-ADAccountPassword, изменив или сбросив пароль учетной записи. Чтобы изменить пароль, необходимо знать старый пароль и ввести новый. Чтобы сбросить пароль, достаточно предоставить новый пароль. Однако необходимо разрешение Reset Password на объект пользователя в AD, чтобы выполнить сброс пароля.

Как и параметр -AccountPassword команды New-ADUser, команда Set-ADAccountPassword использует тип данных SecureString для паролей, поэтому необходимо задействовать один из методов преобразования простых текстовых паролей в защищенные строки. Например, если нужно сбросить пароль для учетной записи пользователя Tom Thumb, то после сохранения нового пароля как защищенной строки в переменной $pass можно выполнить команду:

Set-ADAccountPassword -Identity»tthumb«` -NewPassword $pass –Reset

В этой команде я использую параметр –Identity, чтобы назначить имя учетной записи SAM для учетной записи пользователя Tom Thumb. Я также ввожу параметр -NewPassword с переменной $pass, чтобы предоставить новый пароль. Наконец, задается параметр –Reset, дабы указать, что выполняется сброс, а не изменение пароля.

Еще одна дополнительная задача: переключить флаг учетной записи пользователя Tom Thumb, чтобы заставить его изменить пароль при следующей регистрации. Это обычный прием, когда нужно сбросить пароль пользователя. Данную задачу можно выполнить с помощью команды Set-ADUser, присвоив параметру -ChangePasswordAtLogon значение $true:

Set-ADUser -Identity tthumb -ChangePasswordAtLogon $true

Возникает вопрос, почему не был использован конвейер для передачи вывода команды Set-ADAccountPassword в команду Set-ADUser, чтобы выполнить обе операции в одной команде PowerShell. Я попробовал этот подход, он не работает. Вероятно, в команде Set-ADAccountPassword есть какое-то ограничение, не позволяющее успешно выполнить единую команду. В любом случае, достаточно просто переключить флаг с использованием команды Set-ADUser, как показано выше.

Поиск объектов Active Directory

Другая типичная задача AD - поиск объектов AD, соответствующих определенным критериям. Например, можно найти все компьютеры с определенной версией операционной системы Windows в домене AD. Команда Get-ADObject - самая удобная для поиска LDAP. Например, чтобы найти компьютеры Server 2008 R2 в домене cpandl.com, была применена команда:

Get-ADObject -LDAPFilter ` »(&(operatingSystem=Windows Server 2008 R2 Enterprise)` (objectClass=computer))«-SearchBase»dc=cpandl,dc=com«` -SearchScope Subtree

Эта команда использует три параметра для выполнения задачи: -LDAPFilter, -SearchBase и -SearchScope. Параметр -LDAPFilter принимает в качестве входного стандартный запрос LDAP. В этом примере запрашиваются все объекты компьютера, у которых атрибут OperatingSystem имеет значение Windows Server 2008 R2 Enterprise. Параметр -SearchBase указывает команде, где начать поиск в иерархии AD. В данном случае выполняется поиск из корневого каталога домена AD, но не составляет труда ограничить поиск определенной OU. Параметр –SearchScope указывает команде, следует ли обходить все контейнеры под базой поиска, обнаруживая указанные объекты. В этом случае используется параметр Subtree, чтобы команда проверяла все нижележащие контейнеры.

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

Обратите внимание, что для масштабных поисков полезно задействовать параметр –ResultPageSize, чтобы управлять разбиением результатов поиска на страницы. Обычно я присваиваю этому параметру значение 1000, и команда Get-ADObject возвращает 1000 объектов за один раз. В противном случае можно не получить ожидаемый результат, так как число возвращаемых объектов превышает максимально предусмотренное политикой, установленной для одного запроса поиска.

Другая команда для поиска, предоставленная компанией Microsoft, - Search-ADAccount. Эта команда особенно полезна для поиска с различными заранее заданными условиями, например отключенных учетных записей, учетных записей с просроченными паролями и блокированных учетных записей. Так, следующая команда отыскивает все учетные записи пользователя с просроченными паролями в OU SDM:

Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase»OU=sdm,dc=cpandl,dc=com«` -SearchScope OneLevel Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase»OU=sdm,dc=cpandl,dc=com" ` -SearchScope OneLevel

В этой команде используется параметр –PasswordExpired, указывающий, что нужны учетные записи с просроченными паролями. Параметр -UsersOnly указывает, что нужно искать только объекты пользователя (то есть исключить объекты «компьютер»). Как в предыдущем примере, используются параметры -SearchBase и –SearchScope, чтобы указать область поиска. Но в данном случае я использую параметр OneLevel для поиска только в ближайшем OU (то есть исключая любые дочерние организационные единицы).

Это лишь поверхностный рассказ о модуле AD, но надеюсь, вы получили представление о заложенных в нем возможностях. Как отмечалось выше, в модуле более 70 команд. Среди тем, которые не были затронуты в статье, - удаление объектов с использованием команды Remove-, восстановление удаленных объектов с помощью команды Restore-ADObject и удаление свойств UAC на объектах пользователя посредством команды Set-ADAccountControl. Существуют команды почти для любых административных задач AD.