Модуль Active Directory для PowerShell

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

После установки появится новый сервис:

adws-service

Теперь можно устанавливать модуль 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»:

add-win-features

По умолчанию с модулем «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»

Active Directory for 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.

$group = Get-AdGroup 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.

Если Вам понравилась статья, то вы можете подписаться на RSS.
А также бесплатно подписаться по E-mail и получать актуальную информацию в числе первых.

Получать обновления на email

Вы можете оставить комментарий.

12 Комментариев »

 
  • 1# Kazun (82 комм.):

    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 и о чудо – это называется,что уже имеется.

      Цитировать

    • 2# Сергей Мариничев (687 комм.):

      Беседа с «коллегой» была в том ключе что PowerGUI хорошо, но детали поднимать не стал (про командлеты) да и тут я не особо настаиваю на использовании как одного так и второго.
      Наличие ADWS это безусловно лишняя служба, да и она потенциально опасна т.к. прежде чем ее разворачивать стоит подумать.

      Если она есть то почему бы ее не использовать?
      Если ее нет или нет необходимости-уверенности-и пр. ставить ADWS то надо думать про PowerGUI+Quest

      Вопрос безопасности и методик защиты сильно выходит за пределы этого поста.

        Цитировать

  • 3# Kazun (82 комм.):

    … и не учел то что PowerGUI хоть и удобен, но все же является сторонним средством которое надо хотя бы изредка обновлять.

    Тоже самое произойдет с модулем AD,сейчас у него гораздо больше командлетов,а следовательно и функционала,но пока в Windows 8.Спустят ли этот модуль,до более ранних редакций не известно,как он будет завязан на версии PowerShell и того же .NET.Так же странно чудесные названия командлетов по 50-60 символов,что будет проблематично,но надеюсь создадут кучу альсов.

    Так что вывод ,тут один – лучше учить оба компонента,хуже не будет,причем чаще возникают проблемы именно с модулем AD от Microsoft,нежели от Quest Software.

      Цитировать

  • 5# Kazun (82 комм.):

    Сергей Мариничев:
    Тоже согласен, но с другой стороны никто не тянет за уши обновляться…

    Не тянет,но почему-то в статье на PowerGUI именно в этом контексте был укор.

      Цитировать

    • 6# Сергей Мариничев (687 комм.):

      Мне как то на сервере не охота разводить не то что лишние приложения (т.е. я не сторонник устанавливать PowerGUI не только на контроллеры, но и на member-серверы) а даже лишние службы.
      ADWS стоит на одной из железок и на нее зарезан доступ только с конкретных адресов…

      PowerGui есть только на рабочем месте, использую очень редко (я даже не отпираюсь :) ), штука удобная но жутко неповоротливая…

      Мне привычнее ise

        Цитировать

  • 7# Kazun (82 комм.):

    Сергей Мариничев:
    Мне как то на сервере не охота разводить не то что лишние приложения (т.е. я не сторонник устанавливать 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.

      Цитировать

  • 10# Kazun (82 комм.):

    Сергей Мариничев:
    Кстати.
    У 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/

      Цитировать

 

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

XHTML: Вы можете использовать тэги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>