Модуль Active Directory для PowerShell
На днях спорил с одним из коллег по методикам управления Active Directory средствами PowerShell-а.
Коллега доказывал что нет ничего лучше и удобнее чем PowerGUI, но он либо забыл либо не учел что есть еще Active Directory Module for Windows PowerShell и не учел то что PowerGUI хоть и удобен, но все же является сторонним средством которое надо хотя бы изредка обновлять.
Собственно, ниже речь пойдет о том как установить и о методиках использования модуля Active Directory для PowerShell.
Устанавливаем Active Directory Module для Windows PowerShell
С выходом PowerShell 2.0 мы получили замечательный модуль для администрирования Active Directory. Модуль Active Directory для Windows PowerShell работает на Windows Server 2008 R2 и на Windows 7, для его работы необходим веб-сервис который должен быть размещен на одном из контроллеров домена.
Подготовка контроллера домена
Для работы нам понадобится установка Active Directory Web Services (ADWS) на контроллере с Windows Server 2008 R2 AD DS. В случае если у вас нет контроллера на Windows Server 2008 R2, можно установить Active Directory Management Gateway Service на имеющиеся системы список которых есть чуть ниже.
Загрузить Active Directory Management Gateway Service можно здесь.
Установку производится на следующие ОС:
- Windows Server 2003 R2 with Service Pack 2
- Windows Server 2003 SP2
- Windows Server 2008
- Windows Server 2008 SP2
После установки появится новый сервис:

Теперь можно устанавливать модуль Active Directory для Windows PowerShell. Он доступен на всех версиях Windows Server 2008 R2 (кроме Web Edition) и на Windows 7.
Установка Active Directory Module для Windows PowerShell на 2008 R2
Первый вариант установки слегка устарел, но он вполне работоспособен. Запускаем cmd.exe, вводим:
Servermanagercmd -install RSAT-AD-PowerShell Servermanagercmd -install RSAT-AD-AdminCenter
Второй вариант установки доступен через добавление фичи RSAT-AD-PowerShell и для полного комплекта еще и RSAT-AD-AdminCenter (для кучи), через выполнение следующих команд:
Import-Module ServerManager
Add-WindowsFeature RSAT-AD-PowerShell Add-WindowsFeature RSAT-AD-AdminCenter
Примечание: Перечисленные ниже команды относятся только к рядовому серверу Windows Server 2008 R2членом, на контроллере RSAT-AD-PowerShell функция будет установлена во время выполнения DCPromo.
Установка Remote Server Administration Tools (RSAT) для Windows 7
Чтобы установить Модуль Active Directory для Windows PowerShell, Вы должны загрузить RSAT (Remote Server Administration Tools) для Windows 7 здесь.
После завершения установки открываем «Control Panel» – «Programs and » – «Turn Windows features on or off» и выбираем Модуль «Active Directory for Windows PowerShell»:
По умолчанию с модулем «Active Directory for PowerShell» устанавливаются следующие компоненты.
- Windows PowerShell
- Платформа Microsoft .NET Framework 3.5.1
После запуска ADWS установленных хотя бы на один контроллер можно запускать установленный модуль »Active Directory for PowerShell» одним из способов:
Метод №1
Открываем «Control Panel» – «Administrative Tools» – «Active Directory Module for Windows Powershell»

Нажимаем правой кнопкой мыши и выбираем »Run as administrator».
Метод №2
Я предпочитаю второй вариант т.е. импорт AD PowerShell модуля прямо из сессии PowerShell. Для этого выполняем следующую команду:
Import-Module ActiveDirectory
Использование
Импорт модуля мы произвели ранее, но на всякий случай убеждаемся что он у нас есть:
get-module -ListAvailable
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest ActiveDirectory {}
Manifest AppLocker {}
Manifest BitsTransfer {}
Manifest GroupPolicy {}
...
Нужный модуль есть в списке, импортируем его:
Import-Module ActiveDirectory
Изучаем домен с помощью командлета Get-ADDomain. Полный вывод давать не буду, тут и ниже буду приводить только чать.
Get-ADDomain
ChildDomains : {}
ComputersContainer : OU=Computers,OU=Preparation,OU=test-lab,DC=lab,DC=local
DistinguishedName : DC=lab,DC=local
DNSRoot : LAB.LOCAL
DomainControllersContainer : OU=Domain Controllers,DC=LAB,DC=LOCAL
DomainMode : Windows2003Domain
InfrastructureMaster : DC01.LAB.LOCAL
Name : LAB
NetBIOSName : RETAIL
ParentDomain : {}
PDCEmulator : DC01.LAB.LOCAL
ReplicaDirectoryServers : {dc02.LAB.LOCAL}
RIDMaster : DC01.LAB.LOCAL
UsersContainer : OU=Users,OU=Preparation,OU=test-lab,DC=lab,DC=local
Информативно, не правда ли?
Теперь мы знаем имя домена, имена контроллеров
(Get-ADDomain).ReplicaDirectoryServers
держателей FSMO ролей, режим и пр.
Теперь вводим:
Get-ADDomainController
Domain : LAB.LOCAL
Enabled : True
HostName : DC01.LAB.LOCAL
IPv4Address : 192.168.0.1
IPv6Address :
IsGlobalCatalog : True
IsReadOnly : False
LdapPort : 389
Name : DC01
OperatingSystem : Windows Server 2008 R2 Standard
OperatingSystemVersion : 6.1 (7600)
OperationMasterRoles : {PDCEmulator, RIDMaster}
Site : LABSite
Вывод «порезан», но из него видно что операционная система у нас Windows Server 2008 R2 Standard, что этот контроллер является Global Catalog-ом.
Для полной ясности выясним кто у нас является Администратором, вернее получим список группы Administrators.
Get-ADUser -Filter {MemberOf -recursivematch $group.DistinguishedName}
Дальше проще.
Смотрим когда пользователь Administrator в последний раз менял пароль.
Get-ADUser Administrator -properties PasswordLastSet DistinguishedName : CN=Administrator,CN=Users,DC=LAB,DC=LOCAL Enabled : True GivenName : Name : Administrator ObjectClass : user ObjectGUID : ed5de06a-265c-43da-ab4e-65f3e09e4c32 PasswordLastSet : 11.06.2011 12:54:33 SamAccountName : Administrator
Выходит что давно ![]()
Изучаем то что имеется дальше и запрашиваем список имеющихся учетных записей компьютеров.
Get-ADComputer -LDAPFilter "(name=*)" DistinguishedName : CN=SRV-01,OU=OU=Members Servers,DC=LAB,DC=LOCAL DNSHostName : SRV-01.LAB.LOCAL Enabled : True Name : SRV-01 ObjectClass : computer SamAccountName : SRV-01$ UserPrincipalName : ...
Для того что бы детально изучить список найденных серверов, берем первый сервер из списка и вводим:
Get-ADComputer -LDAPFilter "(name=SRV-01)" -properties *
CanonicalName : LAB.LOCAL/Members Servers/SRV-01
CN : SRV-01
Created : 25.04.2011 11:53:17
Enabled : True
IPv4Address : 192.168.1.100
IPv6Address :
isCriticalSystemObject : False
LastLogonDate : 07.12.2011 6:57:28
Location : Site-2
MemberOf : {CN=SCOM-MS-02_PrimarySG_2164,CN=LAB,CN=OperationsManager,DC=LAB,DC=LOCAL, CN=SCOM-MS-01_PrimarySG_2164,CN=LAB,CN=OperationsManager,DC=LAB,DC=LOCAL}
msDFSR-ComputerReferenceBL : {CN=6c3d3b66-923e-4aaa-9cdc-1319aaa6e95c,CN=Topology,CN=DFS-TESTMEDIA,CN=DFSR-GlobalSettings,CN=System,DC=LAB,DC=LOCAL}
Name : SRV-01
OperatingSystem : Windows Server 2003
OperatingSystemHotfix :
OperatingSystemServicePack : Service Pack 2
OperatingSystemVersion : 5.2 (3790)
PasswordLastSet : 03.12.2011 18:23:53
servicePrincipalName : {Dfsr-12F9A27C-BF97-4787-9162-D31B6C55EB04/SRV-01.LAB.LOCAL, WSMAN/SRV-01, WSMAN/SRV-01.LAB.LOCAL, SMTPSVC/SRV-01.LAB.LOCAL...}
По прежнему интересно?
Судя по выводу мы имеем Windows 2003 Server, с установленным SP2, на котором имеются следы от DFSr и SMTP, обнаруживается так же присутствие установленного SCOM-а.
Посмотрим список SPN-ов подробнее.
(Get-ADComputer -LDAPFilter "(name=SRV-01)" -properties *).servicePrincipalName
Содержательно, но надо двигаться дальше. Для полноты картины посмотрим в DefaultDomainPasswordPolicy:
Get-ADDefaultDomainPasswordPolicy
ComplexityEnabled : True
DistinguishedName : DC=lab,DC=local
LockoutDuration : 00:10:00
LockoutObservationWindow : 00:10:00
LockoutThreshold : 5
MaxPasswordAge : 45.00:00:00
MinPasswordAge : 0.00:00:00
MinPasswordLength : 10
objectClass : {domainDNS}
objectGuid : 515a4469-fda9-4a18-95f9-404da09f3210
PasswordHistoryCount : 5
ReversibleEncryptionEnabled : False
Изучим всех пользователей с не-истекающими паролями:
Get-ADUser -filter {PasswordNeverExpires -eq $True -AND Enabled -eq $True} | Select Distinguishedname
Distinguishedname
-----------------
CN=Administrator,CN=Users,DC=lab,DC=local
CN=user01,CN=TestOU,DC=lab,DC=local
CN=user02,CN=TestOU,DC=lab,DC=local
CN=user03,CN=TestOU,DC=lab,DC=local
Можно было бы выбрать любое количество свойств для отображения, но нам нужно только одно свойство PasswordLastSet. Немного изменяем команду:
Get-ADUser -filter {PasswordNeverExpires -eq $True -AND Enabled -eq $True} -properties PasswordLastSet | Sort PasswordLastSet | Select Distinguishedname,PasswordLastSet
Distinguishedname PasswordLastSet
----------------- ---------------
CN=Administrator,CN=Users,DC=lab,... 1/24/2011 1:20:19 PM
CN=user01,CN=TestOU,DC=lab,DC=local 1/24/2011 3:20:19 PM
CN=user02,CN=TestOU,DC=lab,DC=local 1/24/2011 3:20:18 PM
CN=user03,CN=TestOU,DC=lab,DC=local 1/24/2011 3:20:18 PM
Теперь считаем учетные записи срок действия паролей для которых истек
Get-ADUser -filter {Enabled -eq $True} -properties passwordExpired | where {$_.PasswordExpired} | measure-object
Count : 5
Average :
Sum :
Maximum :
Minimum :
Property :
Много и интересно
но мало пригодно для использования.
Для комплекта стоит создать отчет об активных аккаунтах у которых не истекает пароль в виде таблички.
Get-ADUser -filter {Enabled -eq $True -AND PasswordNeverExpires -eq $False} -properties * | Sort PasswordLastSet | Select Name,PasswordLastSet,PasswordExpired,@{Name="PasswordAge";Expression={(Get-Date)-$_.PasswordLastSet}}
Name PasswordLastSet PasswordExpired PasswordAge
---- --------------- --------------- -----------
user04 1/24/2011 3:20:19 PM False 5.05:23:24.7644101
…
Как использовать полученные данные решать вам. Уверен что данные выше «галопом по европе» рецепты будут использованы только в благих целях.
Какова мораль всего вышесказанного?
Прежде чем кидаться устанавливать сторонние приложения, пусть даже такие удобные и функциональные как PowerGUI, стоит изучить то что уже имеется.
Похожие статьи
Информация об авторе
|
|
Сергей Мариничев. Вы можете присоединиться ко мне в Facebook или в Twitter. |
А также бесплатно подписаться по E-mail и получать актуальную информацию в числе первых.
Вы можете оставить комментарий.


PowerGUI – это GUI интерфейс и скриптовый редактор для PowerShell,что бы управлять Active Directory ,надо скачать командлеты – http://www.quest.com/powershell/activeroles-server.aspx
Так что,сам PowerGUI совершенно не обязателен иметь для управления AD(хотя кому нравится оснастки,то придеться ставить PowerGui).Обновление,это только камень в сторону MS,когда есть баги и прочие вещи,или улучшение текущего функционала,они правятся только после следующих релизов,ближайщий Windows 8.Здесь же только более удобный функционал и добавление гораздо больших возможностей,нежели тот же самый модуль AD.Плюс еще один камень в огород MS(для управления только Windows Server 2008 R2 или Windows 7 – причем надо качать RSAT,т.е по умолчанию нет),когда модуль от Quest работает от XP – 2008 R2 и версия PowerShell не особа важна и никаких дополнений ввиде ADWS(лишняя служба) – ставить не нужно,плюс не надо версий .Net 3.5 и выше,все написанно на чистых WinAPI.
Так же кто не особо любит обновляться скачать два обновления :
http://support.microsoft.com/kb/967574 http://support.microsoft.com/kb/969166
Какова мораль всего вышесказанного?
Прежде чем кидаться устанавливать сторонние приложения, пусть даже такие удобные и функциональные как PowerGUI, стоит изучить то что уже имеется.
1) Имееть Windows Server 2008 R2 или Windows 7 ,у кого-то не получится ,поэтому выход командлеты от Quest,как самый простой способ.
2) Сбегать за обновлениями для Windows,для Net,для ADWS,RSAT и о чудо – это называется,что уже имеется.
KazunЦитировать
Беседа с «коллегой» была в том ключе что PowerGUI хорошо, но детали поднимать не стал (про командлеты) да и тут я не особо настаиваю на использовании как одного так и второго.
Наличие ADWS это безусловно лишняя служба, да и она потенциально опасна т.к. прежде чем ее разворачивать стоит подумать.
Если она есть то почему бы ее не использовать?
Если ее нет или нет необходимости-уверенности-и пр. ставить ADWS то надо думать про PowerGUI+Quest
Вопрос безопасности и методик защиты сильно выходит за пределы этого поста.
Сергей МариничевЦитировать
… и не учел то что PowerGUI хоть и удобен, но все же является сторонним средством которое надо хотя бы изредка обновлять.
Тоже самое произойдет с модулем AD,сейчас у него гораздо больше командлетов,а следовательно и функционала,но пока в Windows 8.Спустят ли этот модуль,до более ранних редакций не известно,как он будет завязан на версии PowerShell и того же .NET.Так же странно чудесные названия командлетов по 50-60 символов,что будет проблематично,но надеюсь создадут кучу альсов.
Так что вывод ,тут один – лучше учить оба компонента,хуже не будет,причем чаще возникают проблемы именно с модулем AD от Microsoft,нежели от Quest Software.
KazunЦитировать
Тоже согласен, но с другой стороны никто не тянет за уши обновляться…
Сергей МариничевЦитировать
Не тянет,но почему-то в статье на PowerGUI именно в этом контексте был укор.
KazunЦитировать
Мне как то на сервере не охота разводить не то что лишние приложения (т.е. я не сторонник устанавливать PowerGUI не только на контроллеры, но и на member-серверы) а даже лишние службы.
ADWS стоит на одной из железок и на нее зарезан доступ только с конкретных адресов…
PowerGui есть только на рабочем месте, использую очень редко (я даже не отпираюсь
), штука удобная но жутко неповоротливая…
Мне привычнее ise
Сергей МариничевЦитировать
Еще раз,PowerGUI – это GUI интерфейс и скриптовый редактор для PowerShell.При установке,он просит,для поддержки AD нужно установить модуль,ссылку я выше давал и только тогда,будет поддержка AD,т.е PowerGUI с набором паков,может заменять некоторые оснастки Windows.
Поэтому модуль от Quest ,легко работает в связке с PowerGUI,так и без него.Достаточно иметь PowerShell+Quest Software AD cmdlets,не важно где(сервер,рабочай станция),главное где удобнее,для управления AD.
ADWS стоит на одной из железок и на нее зарезан доступ только с конкретных адресов… – и что,остальные DC дадут легко туже информацию.
В основном,я не пользуюсь ISE вообще,только PowerGUI в качестве редактора.Возможно с выходом PowerShell V3,что-то измениться,но так уровень прямо нулевой у ISE.
KazunЦитировать
Тоже спорить не буду.
Опять же повторюсь что использую как PowerGUI так и просто командлеты (для запланированных задач).
PS ну ISE не нулевой уровень… Просто он слишком аскетичен
но это лучше чем блокнот.
Сергей МариничевЦитировать
Кстати.
У ISE в версии 3. Появится много нового http://social.technet.microsoft.com/wiki/contents/articles/4667.aspx
Сергей МариничевЦитировать
Бедный обзор,пару месяцев назад об этом гораздо лучше писал Jonathan Medd, в своем блоге – http://www.jonathanmedd.net/2011/09/powershell-ise-v3-now-with-intellisense.html
http://www.jonathanmedd.net/2011/09/powershell-v3-ise-commands-add-on.html
Так же в PowerShell Magazine,было не плохое добавление – http://www.powershellmagazine.com/2011/09/28/powershell-v3-ise-and-ise-scripting-model-changes-improvements/
KazunЦитировать
Спасибо за ссылки.
Подписался на RSS
Сергей МариничевЦитировать