Блог команды разработки Active Directory Powershell

Active Directory PowerShell – Расширенный фильтр (Часть 2)

Andrey Beshkov — Mon, 30 Nov 2009 14:13:22 GMT

В моем предыдущем посте я рассказывал о различных возможностях, доступных с помощью параметра –Filter, также известного как «расширенный фильтр». Этот пост дополняет предыдущий и рассказывает о различных операторах, которые поддерживаются расширенным фильтром и представляет некоторые примеры использования каждого из них. Большинство примеров взяты из нашей встроенной справки, которую вы можете вызвать командой:

PS C:\> get-help about_ActiveDirectory_Filter ## работает только в самых последних сборках

Вот список поддерживаемых операторов в расширенных фильтрах Active Directory Powershell:

Логический оператор	Описание	Эквивалентный оператор/выражение LDAP
-eq	Равно. Не поддерживает подстановочные знаки.	=
-ne	Не равно. Не поддерживает подстановочные знаки.	! x = y
-like	Аналогично –eq, но поддерживает сравнение с использованием подстановочных знаков. Единственный поддерживаемый подстановочный знак: *	=
-notlike	Не соответствует. Поддерживает сравнение с использованием подстановочных знаков.	! x = y
-approx	Приблизительно равно	~=
-le	Лексикографически меньше или равно	<=
-lt	Лексикографически меньше	! x >= y
-ge	Лексикографически больше или равно	>=
-gt	Лексикографически больше	! x <= y
-and	И	&
-or	ИЛИ	\|
-not	НЕ	!
-bor	Побитовое ИЛИ	:1.2.840.113556.1.4.804:=
-band	Побитовое И	:1.2.840.113556.1.4.803:=
-recursivematch	Использует LDAP_MATCHING_RULE_IN_CHAIN (Win2k3 SP2 и выше)	:1.2.840.113556.1.4.1941:=

Пример 1: Получаем все записи
Get-ADObject -Filter { ObjectClass -like "*" }

Эквивалентный LDAP фильтр: (objectClass=*)

Пример 2: Получаем записи, содержащие "bob" где-либо в common name
Get-ADObject -Filter { CN -like "*bob*" }

Эквивалентный LDAP фильтр: (cn=*bob*)

Пример 3: Получаем записи, для которых количество ошибочных вводов пароля больше 5
Get-ADUser -Filter { badpwdcount -ge 5 }

Эквивалентный LDAP фильтр: (badpwdcount>=5)

Пример 4: Получаем всех пользователей с атрибутом e-mail
        Get-ADUser -filter { email -like "*" }
        -или-
        Get-ADObject -filter { email -like "*" -and ObjectClass -eq "user" }

Эквивалентный LDAP фильтр: (&(objectClass=user)(email=*))

Пример 5: Получаем все записи пользователей с атрибутом e-mail, где фамилия = "smith"
        Get-ADUser -Filter { Email -like "*" -and Surname -eq "smith" }
        -или-
        Get-ADUser -Filter { Email -like "*" -and sn -eq "smith" }

Эквивалентный LDAP фильтр: (&(sn=smith)(objectClass=user)(email=*))

Пример 6: Получаем все записи пользователей, где common name начинается с "andy", а также пользователей, у которых common name "steve" или "margaret"
        Get-ADUser -Filter { CN -like "andy*" -or CN -eq "steve" -or CN -eq "margaret" }
        -или-
        Get-ADObject -Filter { objectClass -eq "user" -and (CN -like "andy*" -or CN -eq "steve" -or CN -eq "margaret") }

Эквивалентный LDAP фильтр: (&(objectClass=user) | (cn=andy*)(cn=steve)(cn=margaret))

Пример 7: Получаем все записи без атрибута e-mail
        Get-ADUser -Filter { -not Email -like "*" }
        -или-
        Get-ADUser -Filter { Email -notlike "*" }

Эквивалентный LDAP фильтр: (!(email=*))

Пример 8: Получаем объекты всех пользователей, которые не входили в систему с 1 января 2007 г.
$date = new-object System.DateTime -ArgumentList @(2007,1,1,0,0,0)
Get-ADUser -Filter { -not LastLogon -le $date }

Эквивалентный LDAP фильтр: (&(lastlogon<=X)(objectClass=user))
## где X – количество 100-наносекундных интервалов, прошедших с 1 января 1601 г.

Пример 9: Получаем всех пользователей, которые входили в систему в последние 5 дней
$date = (get-date) - (new-timespan -days 5)
Get-ADUser -Filter { lastLogon -gt $date }

Эквивалентный LDAP фильтр: (&(lastLogon>=128812906535515110) (objectClass=user)(!(objectClass=computer)))

Пример 10: Получаем все группы безопасности
Следующий запрос возвращает все объекты групп, у которых установлен флаг ADS_GROUP_TYPE_SECURITY_ENABLED (0x80000000 = 2147483648).
Get-ADGroup -filter { groupType -band 0x80000000 }
-или-
Get-ADGroup -filter { GroupCategory -eq "Security" }

Эквивалентный LDAP фильтр: (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

Пример 11: Проверяем, является ли пользователь членом группы (с использованием рекурсивного поиска)
Следующий пример запроса использует LDAP_MATCHING_RULE_IN_CHAIN - это OID правила, которое позволяет искать происхождение объекта.

Get-ADUser -Filter { memberOf -RecursiveMatch "CN=Administrators,CN=Builtin,DC=Fabrikam,DC=com" } -SearchBase "CN=Administrator,CN=Users,DC=Fabrikam,DC=com" -SearchScope Base
## ВНИМАНИЕ: Указанная вверху команда возвратит объект пользователя (Administrator в данном случае), если она найдет совпадение рекурсивно в атрибуте memberOf.
-или-
        $userObj = Get-ADUser Administrator
        $groupObj = Get-ADUser Administrators
        Get-ADUser -Filter { memberOf -RecursiveMatch $userObj.DistinguishedName } -SearchBase $groupObj.DistinguishedName -SearchScope Base

Эквивалентный LDAP фильтр: (memberof:1.2.840.113556.1.4.1941:=(CN=Administrators,CN=Builtin,DC=Fabrikam,DC=com)))

Cheers!
Swami

--
Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

Оригинал: http://blogs.msdn.com/adpowershell/archive/2009/04/14/active-directory-powershell-advanced-filter-part-ii.aspx

Перевод: Илья Лушников

Работа с сертификатами в Active Directory PowerShell

Andrey Beshkov — Mon, 30 Nov 2009 14:10:26 GMT

AD Powershell использует .NET класс X509Certificate для представления сертификата. Давайте посмотрим, как можно управлять сертификатами пользователя.

Обновление пользовательских сертификатов

Создаем объект X509Certificate (или X509Certificate2) с помощью файла сертификата.

PS C:\> $cert1 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate "C:\Certs\Test1.cer"
PS C:\> $cert2 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate "C:\Certs\Test2.cer"

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

PS C:\> $certs = $cert1,$cert2 #create certificate array
PS C:\> New-ADUser -Name TestUser1 -SamAccountName TestUser1 -Certificates $certs

На заметку: Параметр Certificates обновляет атрибут LDAP userCertificate.

Также можно назначить сертификаты существующей учетной записи пользователя.
PS C:\> Set-ADUser TestUser1 -Certificates @{Replace=$cert1,$cert2}

Просмотр пользовательских сертификатов

Можно выбрать сертификаты для существующего пользователя.
PS C:\> $user1 = Get-ADUser TestUser1 -Properties "Certificates"

И затем просмотреть основные параметры сертификатов:

PS C:\> $user1.Certificates | fl * -f

Handle  : 456139856
Issuer  : OU=EFS File Encryption Certificate, L=EFS, CN=Administrator
Subject : OU=EFS File Encryption Certificate, L=EFS, CN=Administrator
...

Класс X509Certificate2 используется для получения большей информации о сертификатах.

PS C:\> $user1.Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | fl * -f

...
FriendlyName       :
IssuerName         : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter           : 2/24/2109 8:35:26 AM
NotBefore          : 3/20/2009 9:35:26 AM
HasPrivateKey      : False
PrivateKey         :
PublicKey          : System.Security.Cryptography.X509Certificates.PublicKey
RawData            : {48, 130, 3, 139...}
SerialNumber       : …
SubjectName        : System.Security.Cryptography.X509Certificates.X500DistinguishedName
SignatureAlgorithm : System.Security.Cryptography.Oid
Thumbprint         : …
Version            : 3
Handle             : 456139856
Issuer             : OU=EFS File Encryption Certificate, L=EFS, CN=Administrator
Subject            : OU=EFS File Encryption Certificate, L=EFS, CN=Administrator

Также можно назначить существующие сертификаты новому пользователю.

PS C:\> $user1 = Get-ADUser TestUser1 -Properties "Certificates"
PS C:\> New-ADUser -Name TestUser2 -SamAccountName TestUser2 -Certificates $user1.Certificates

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

Надеюсь, это поможет.

Cheers!
Ashish

--
Ашлиш Шарма (Ashish Sharma) [MSFT]
Developer – Active Directory Powershell Team

Оригинал

Перевод: Илья Лушников

Обзор Active Directory Web Services

Andrey Beshkov — Mon, 30 Nov 2009 14:05:31 GMT

Active Directory Web Services (ADWS) – это новый сервис, впервые появившийся в Windows Server 2008 R2 и позволяющий удаленно управлять любыми службами каталогов с помощью протоколов WS-*.

ADWS поддерживает следующие протоколы веб-служб:

WS-Transfer
IMDA (WS-Transfer Extensions for Identity Management Operations for Directory Access)
WS-Enumeration Directory Services Protocol Extensions, который является набором расширений для WS-Enumeration.
Custom Actions
LDAP Generic Control Extension: Собственное расширение для WS-Transfer и WS-Enumeration, которое представляет механизм для передачи в LDAP, контролирующее часть запросов.

Модель данных, используемая AD Webservice, описана здесь.

AD Webservice автоматически устанавливается вместе с ролями AD DS или AD LDS и автоматически запускается, когда выполняется запрос к службам каталогов. Модуль Active Directory для Windows Powershell использует AD Webservice для управления и администрирования Active Directory. Кроме того, поскольку Active Directory Administrative Center (ADAC) выполнен на основе AD PowerShell, он также использует AD Webservice для управления сервером служб каталогов. Эта клиент-серверная модель изображена на диаграмме:

Как показано на диаграмме вверху, один экземпляр ADWS управляет всеми экземплярами службы каталогов, работающими на сервере. Среди них могут быть контроллер домена, сервер глобального каталога, моментальные снимки каталогов и экземпляры AD LDS. AD Webservice реализован с помощью WCF и прослушивает зарегистрированный TCP порт 9389. Эта служба работает с привилегиями Local System.

Не переключайтесь с нашей волны, и получайте больше информации о AD Webservice.

Cheers,
Манас Сингх (Manas Singh)

Оригинал: http://blogs.msdn.com/adpowershell/archive/2009/04/06/active-directory-web-services-overview.aspx

Перевод: Илья Лушников

Как создать функцию для подтверждения наличия объекта AD (Test-XADObject)

Andrey Beshkov — Mon, 30 Nov 2009 14:04:24 GMT

В этом посте я покажу вам простую, но очень нужную функцию, которая может понадобиться во многих скриптах. Эта функция возвращает истину, если заданный объект AD действительно существует. Параметр Identity может принимать значение любого типа ADObject. Это означает, что он может принимать те же значения, что и командлеты вида *-ADObject.

function Test-XADObject() {
	[CmdletBinding(ConfirmImpact="Low")]

	Param (

		[Parameter(Mandatory=$true,
			Position=0,
			ValueFromPipeline=$true,
			HelpMessage="Identity of the AD object to verify if exists or not."
			)]
		[Object] $Identity
	)
	
	trap [Exception] {
		return $false
	}

	$auxObject = Get-ADObject -Identity $Identity

	return $true

}

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

Cheers,

Джайро Кадена (Jairo Cadena)

Active Directory

Оригинал

Перевод: Илья Лушников

Как просмотреть удаленные объекты Active Directory перед восстановлением

Andrey Beshkov — Mon, 30 Nov 2009 14:00:00 GMT

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

Что было удалено?
Когда произошло удаление?
Где (на каком контроллере домена) произошло удаление?

После выполнения анализа, когда определены объекты, которые необходимо восстановить, – вы можете выбрать предпочтительный метод восстановления.
Традиционное восстановление предполагает, что есть недавняя резервная копия состояния системы (system state) и необходимо произвести авторитетное восстановление удаленных объектов. Но для лесов с функциональным уровнем Windows Server 2008 R2 есть новая функция Корзина (Recycle Bin), которая делает восстановление одиночных объектов очень простым. С момента включения этой функции, все атрибуты сохраняются в объекте при его удалении. И когда объект восстанавливается с помощью командлета Restore-ADObject – объект восстанавливается полностью. Таким образом, если объект пользователя был случайно удален и восстановлен с помощью Restore-ADObject – все прямые и обратные ссылки на объект пользователя также восстанавливаются – членство в группах, менеджер, ManagedObjects, DirectReports и т.д., также, как и атрибуты, не являющиеся ссылками.
Этот пост описывает фазу анализа: определение объектов, которые необходимо восстановить.
Необходимо определить способы, которыми вы можете анализировать произошедшее удаление. Три основных подхода таковы:

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

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

Далее вывод этой команды можно передать по конвейеру командлету Where-Object и отфильтровать по нужному критерию – когда или где произошло удаление.

Можно также отсортировать по полю WhenDeleted – хотя это и нарушает вид дерева …

Восстановление дерева
Восстановление для удаленных деревьев не так просто, как для отдельных объектов. Когда объекты удаляются, они перемещаются в контейнер Deleted Objects с плоской иерархией. Таким образом, удаленное дерево теряет свою иерархию. Скрипт Restore-ADTree делает восстановление дерева более простым. Можно передать в скрипт DN или GUID корня дерева и он рекурсивно восстановит все нижележащие объекты. Скрипт Restore-ADTree можно использовать на удаленных OU, только если ВСЕ удаленные дочерние объекты этого OU (ныне расположенные в контейнере для удаленных объетов) должны быть восстановлены.
При использовании с параметром -LeafObjectInfo, этот скрипт (Get-ADDeletedContainers) также показывает информацию о подчиненных (subordinates) каждого контейнера. Поле 'subordinates' показывает количество удаленных объетов, непосредственно расположенных ниже удаленного OU и максимальный промежуток между временем удаления подчиненных объектов. Итак, пусть свежесозданное OU содержало 5 объектов пользователей. Один из них был удален 3 дня назад (правильное умышленное удаление), а сегодня OU и 4 дочерних объекта были удалены случайно – Поле “subordinates” (подчиненные) для данного OU покажет 5 (3.00:00:00).

С опцией LeafObjectsInfo скрипт будет выполняться дольше. Эта опция поможет проанализировать, нужно ли использовать для удаленных OU скрипт Restore-ADTree. Если время удаления подчиненных объектов различается более, чем на несколько минут – нужно проанализировать, все ли подчиненные объекты являются кандидатами на восстановление.
Таким образом, перед использованием Restore-ADObject или Restore-ADTree или даже если вы планируете использовать авторитетное восстановление (ввиду невозможности использования корзины) – вы можете использовать этот скрипт для лучшего просмотра и анализа содержимого контейнера удаленных объектов.
Использование: Укажите диском AD PowerShell на вашу AD или перейдите на диск AD: и используйте скрипт, как показано в примерах. Не требуется включать корзину, чтобы скрипт работал.

PS CONTOSO:\> Get-ADDeletedContainers.ps1 | ft DisplayName,WhenDeleted,WhereDeleted
PS CONTOSO:\> Get-ADDeletedContainers.ps1 | ft DisplayName,ObjectClass,ObjectGUID,WhenDeleted,WhereDeleted
PS CONTOSO:\> Get-ADDeletedContainers.ps1 -LeafObjectsInfo | ft DisplayName,Subordinates
PS CONTOSO:\> Get-ADDeletedContainers.ps1 | where {$_.WhenDeleted -gt [DateTime]::Parse("5/25/2009 9:40:00 AM")}|ft DisplayName,WhenDeleted,WhereDeleted
PS CONTOSO:\> Get-ADDeletedContainers.ps1 | where {$_.WhereDeleted -like "CONTOSO-DC2*"}|ft DisplayName,WhenDeleted,WhereDeleted
PS CONTOSO:\> Get-ADDeletedContainers.ps1 | where {$_.WhenDeleted -gt [DateTime]::Parse("5/25/2009") -and $_.WhereDeleted -like "CONTOSO-DC2*"}|ft DisplayName,WhenDeleted,WhereDeleted

ps: Защитите ваши OU от случайного удаления, для предотвращения подобного в дальнейшем. Чтобы узнать как – сделайте поиск по фразе "Protect an Organizational Unit from Accidental Deletion"

Наслаждайтесь!
Душянт Гилл (Dushyant Gill)
Program Manager, Directory Services

Присоединенный файл: Get-ADDeletedContainers ps1.txt

Оригинал

Перевод: Илья Лушников

Используем Active Directory PowerShell для управления сайтами – Часть 1 (New-XADSite)

Andrey Beshkov — Mon, 30 Nov 2009 13:58:48 GMT

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

Прежде всего, необходимо понять, для чего создаются сайты AD. Можно сказать, что сайт AD представлен тремя объектами служб каталогов и ссылками в атрибутах других объектов (например, объекта Site Link – связь сайтов). Если точнее, сайт AD состоит из:

1. Объекта site (objectClass=site), который в иерархии расположен ниже объекта sites в разделе конфигурации.

2. Объекта NTDS site settings (objectClass=nTDSSiteSettings), который является дочерним объектом объекта site

3. Объекта servers containers (objectClass=serversContainer), который является дочерним объектом объекта site

4. Значения в многозначном атрибуте siteList объекта site link, представляющего связь сайтов.

В первую очередь, необходимо знать различительное имя (DN – distinguished name) контейнера sites. Этот объект имеет относительное различительное имя (RDN - relative distinguished name) Sites и расположен непосредственно ниже контекста именования конфигурации. Итак, получить DN контейнера sites можно следующим образом:

$configNCDN = (Get-ADRootDSE).ConfigurationNamingContext

$sitesContainerDN = ("CN=Sites," + $configNCDN)

Новый объект site станет объектом внутри контейнера sites:

 $newSiteDN = ("CN=" + $newSiteName +"," + $sitesContainerDN)

Для создания объектов Site, NTDS Site Settings и Servers внутри контейнера Sites, можно использовать командлет New-ADObject:

New-ADObject -Name $newSiteName -Path $sitesContainerDN -Type site
New-ADObject -Name "NTDS Site Settings" -Path $newSiteDN -Type nTDSSiteSettings
New-ADObject -Name "Servers" -Path $newSiteDN -Type serversContainer

Далее, для добавления сайта в связь сайтов необходима ссылка на объект сайта. Ссылки на объект сайта (site link objects) расположены ниже объекта внутрисайтового транспорта (inter-site transport object) (IP или SMTP). Например, для связи сайтов DEFAULTIPSITELINK контейнер связей сайтов будет расположен так:

$siteLinkContainer = ("CN=DEFAULTIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites," + $configNCDN)

Последний шаг – это добавление сайта к связи сайтов путем включения имени сайта в атрибут siteList в соответствующем объекте связи сайтов. Для изменения атрибута siteList в объекте связи сайтов, необходимо сначала получить объект связи сайтов с атрибутом siteList с помощью командлета Get-ADObject (для создания экземпляра), а затем изменить его с помощью командлета Set-ADObject:

$siteLink = Get-ADObject $siteLinkContainer -Properties siteList
$siteLink.siteList.Add($newSiteDN)
Set-ADObject -Instance $siteLink

Вот так оно будет выглядеть.

Я создал функцию по имени New-XADSite, которая принимает имя сайта и имя объекта связи сайтов (поддерживается протокол IP, но для поддержки SMTP требуется совсем немного изменений). Она также содержит проверки особых случаев, которые обеспечивают более надежную работу для использования функции в лесах AD. В будущем, я покажу вам, как в AD PowerShell создать функции для получения имен сайтов в лесу, перемещения сайта в другую связь сайтов, переименования сайта и удаления сайта из леса AD. Обратите внимание, что скрипт использует функцию Test-XADObject, которая представлена в предыдущем посте.

   1:  function New-XADSite() {
   2:     [CmdletBinding(ConfirmImpact="Low")]
   3:     Param (
   4:        [Parameter(Mandatory=$true,
   5:                   Position=0,
   6:                   ValueFromPipeline=$true,
   7:                   HelpMessage="Идентификатор создаваемого сайта. В  этой версии скрипта, имя – единственный допустимый идентификатор сайта."
   8:                  )]
   9:        [Object] $Identity,
  10:        [Parameter(Mandatory=$false,
  11:                   Position=1,
  12:                   ValueFromPipeline=$false,
  13:                   HelpMessage="Имя объекта связи сайтов, к которому будет относиться сайт."
  14:                  )]
  15:        [Object] $SiteLinkName
  16:     )
  17:   
  18:     BEGIN {
  19:   
  20:     }
  21:   
  22:     PROCESS {
  23:   
  24:        # В этой версии скрипта, имя сайта – единственный поддерживаемый идентификатор
  25:        # Измените строку ниже для поддержки других идентификаторов
  26:        $newSiteName = $Identity
  27:   
  28:        if ([String]::IsNullOrEmpty($newSiteName)) {
  29:           throw New-Object System.Management.Automation.PSArgumentException("Имя сайта не может быть пустым. Пожалуйста, укажите правильное имя сайта.")
  30:        }
  31:   
  32:        if ($SiteLinkName -eq $null) {
  33:           $SiteLinkName = "DEFAULTIPSITELINK"
  34:        }
  35:   
  36:        # Получаем DN раздела конфигурации, контейнера sites и создаем DN нового сайта
  37:        $configNCDN = (Get-ADRootDSE).ConfigurationNamingContext
  38:        $sitesContainerDN = ("CN=Sites," + $configNCDN)
  39:        $newSiteDN = ("CN=" + $newSiteName +"," + $sitesContainerDN)
  40:   
  41:        $siteLinkContainerDN = ("CN=" + $SiteLinkName + ",CN=IP,CN=Inter-Site Transports,CN=Sites," + $configNCDN)
  42:        # Проверяем, существует ли связь сайтов
  43:        $siteLinkExists = Test-XADObject -Identity $siteLinkContainerDN
  44:        if ($siteLinkExists -eq $false) {
  45:           throw New-Object System.Management.Automation.RuntimeException("Указанная связь сайтов не существует. Пожалуйста, укажите имя существующей связи сайтов.")
  46:        }
  47:   
  48:        # Проверяем, существует ли сайт
  49:        $siteExists = Test-XADObject -Identity $newSiteDN
  50:        if ($siteExists) {
  51:           throw New-Object System.Management.Automation.RuntimeException("Сайт с таким именем уже существует. Для создания нового сайта, укажите имя сайта, которое не используется.")
  52:        }
  53:        else {
  54:           $siteObjectCreated = $false
  55:   
  56:           trap [Exception] {
  57:              # Ошибки выводим в конвейер
  58:              Write-Host $_
  59:   
  60:              # Убираем объекты, созданные для совместимости
  61:              if ($siteObjectCreated -eq $true) {
  62:                 Remove-ADObject -Identity $newSiteDN -Recursive -Confirm:$false
  63:              }
  64:   
  65:              # Выдаем новое исключение, куда включаем созданные исключения в качестве внутренних исключений
  66:              throw New-Object System.Management.Automation.RuntimeException("При создании сайта возникло исключение. Подробности см. во внутренних исключениях.", $_.Exception)
  67:           }
  68:   
  69:           # Создаем объекты сайта, Параметры NTDS и объекты серверов
  70:           New-ADObject -Name $newSiteName -Path $sitesContainerDN -Type site
  71:           $siteObjectCreated = $true
  72:           New-ADObject -Name "NTDS Site Settings" -Path $newSiteDN -Type nTDSSiteSettings
  73:           New-ADObject -Name "Servers" -Path $newSiteDN -Type serversContainer
  74:   
  75:           $siteLink = Get-ADObject $siteLinkContainerDN -Properties siteList
  76:           $numberOfSitesInSiteLink = $siteLink.siteList.Add($newSiteDN)
  77:           Set-ADObject -Instance $siteLink
  78:   
  79:           # Возвращает объекты службы каталогов, которые создают сайт AD
  80:           Get-ADObject -Identity $newSiteDN
  81:           Get-ADObject -Identity ("CN=NTDS Site Settings," + $newSiteDN)
  82:           Get-ADObject -Identity ("CN=Servers," + $newSiteDN)
  83:        }
  84:   
  85:      }
  86:   
  87:      END {
  88:   
  89:      }
  90:  }

Наслаждайтесь,

Джайро Кадена (Jairo Cadena)

Active Directory

Оригинал

Перевод: Илья Лушников

Используем Active Directory PowerShell для управления контроллерами домена на Windows Server 2003/2008

Andrey Beshkov — Mon, 30 Nov 2009 13:56:34 GMT

Многие читатели интересовались возможностью управлять контроллерами на ранних ОС (Windows Server 2003/2008) с помощью ADPowershell. Единственным, чего для этого не хватало, были возможности Active Directory Web Service (описание здесь). Итак, представляем вам бета-версию ADWS для контроллеров домена на ранних версиях ОС. С помощью этой бета-версии, вы можете управлять существующими лесами Active Directory с помощью ADPowershell. Далее опишем шаги, необходимые для участия в бета-тестировании:

Заходим на сайт http://connect.microsoft.com и вводим код приглашения ADWS-FDBT-CVJK на главной странице.
Входим под своим live/hotmail ID
Сведения о загрузке Active Directory Management Gateway Service и инструкции доступны на сайте MS Connect - http://connect.microsoft.com/ADWS/

Прим. пер. 1: в настоящее время уже выпущена финальная версия Active Directory Management Gateway Service: Ссылка для загрузки. Таким образом, необходимости в использовании сайта connect.microsoft.com для загрузки этого продукта сейчас нет. Подробнее об установке читайте в документации - здесь.

Прим. пер. 2: хотя ADWS и устанавливается на Windows Server 2003/2008, для установки командлетов ADPowerShell потребуется компьютер на Windows 7 или Windows Server 2008 R2.

Обратите внимание, что есть секция для обратной связи, которую нужно использовать :) Пожалуйста, установите эту бету и дайте нам обратную связь.

С благодарностью,

Али

---

Мудассир Али (Mudassir Ali)
Software Development Engineer in Test - Active Directory Powershell Team

Оригинал

Перевод: Илья Лушников

Active Directory Powershell – Расширенный фильтр

Andrey Beshkov — Mon, 30 Nov 2009 13:44:09 GMT

Чтение/написание LDAP-фильтров вызывает у вас затруднения? Вы бы хотели писать LDAP-фильтры в более естественном виде? Вы бы хотели, чтобы парсер LDAP-фильтров указывал вам на ошибочный символ, вместо показа расплывчатого сообщения об ошибке LDAP_FILTER_ERROR (87)? Вам непонятно, как указывать OID в фильтре? Если хотя бы на один из этих вопросов вы ответили «да», имеет смысл дочитать этот пост до конца...

Active Directory Module for Windows Powershell представляет новую мощную замену LDAP-фильтрам; мы называем это «Расширенный фильтр» («The Advanced Filter»). Расширенный фильтр поддерживается с помощью параметра –Filter во всех командлетах вида Get-AD*.

Так что же такого «расширенного» в этом фильтре?

1. Простота написания – Новый фильтр удобен в чтении и написании. Он использует инфиксную запись (например: { GivenName –eq “John” –and SurName –eq “Smith” } ), которая более удобна по сравнению с префиксной записью (например: (&(givenName=john)(sn=smith)) ).

Новый синтаксис фильтров аналогичен языку выражений PowerShell (Powershell Expression Language) и используется в параметре FilterScript командлета Where-Object. Так что для пользователей Powershell становится просто делать запросы к AD без знаний в области Ldap-фильтрации. Большинство используемых операторов стандартны для Powershell (например: -eq, -like, -band и т.п.). Также представлены несколько новых операторов – таких, как -recursivematch и т.п.

2. Улучшенные сообщения об ошибках парсинга фильтра – Давайте попробуем задать в параметре –Filter некорректную строку запроса.

PS D:\Users\Administrator> Get-ADUser -Filter { Name -isequal "Administrator" }
Get-ADUser : Error parsing query: ' Name -isequal "Administrator" ' Error Message: 'Operator Not supported: -isequal' at position: '7'.
At line:1 char:11
+ Get-ADUser <<<<  -Filter { Name -isequal "Administrator" }
+ CategoryInfo          : ParserError: (:) [Get-ADUser], ADFilterParsingException
+ FullyQualifiedErrorId : Error parsing query: ' Name -isequal "Administrator" ' Error Message: 'Operator Not supported: -isequal' at position: '7'., Microsoft.ActiveDirectory.Management.Commands.GetADUser

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

PS D:\Users\Administrator> Get-ADUser -Filter { Name -like Administrator }
Get-ADUser : Error parsing query: ' Name -like Administrator ' Error Message: 'syntax error' at position: '13'.
At line:1 char:11
+ Get-ADUser <<<<  -Filter { Name -like Administrator }
+ CategoryInfo          : ParserError: (:) [Get-ADUser], ADFilterParsingException
+ FullyQualifiedErrorId : Error parsing query: ' Name -like Administrator' Error Message: 'syntax error' at position: '13'., Microsoft.ActiveDirecto  ry.Management.Commands.GetADUser

Здесь сообщение об ошибке для парсера расширенных фильтров указывает на позицию в строке, где синтаксис некорректен. Корректным будет такой фильтр: -Filter { Name -like "Administrator" }

3. Внутри фильтра можно использовать переменные Powershell! – Расширенный Фильтр позволяет получать доступ к переменным Powershell внутри фильтра. Вы можете также получать доступ к свойствам переменных Powershell внутри фильтра.

PS D:\> $JohnSmith = Get-ADUser JohnSmith
PS D:\> Get-ADUser -Filter { manager -eq $JohnSmith.DistinguishedName }

## Получаем все учетные записи пользователей, где менеджер - JohnSmith

Внимание: Расширенный Фильтр не поддерживает индексатор (например: $a[0]) и вызов функции (например: $a.ToString()) внутри фильтра.

4. Автоматическое кодирование в Ldap – Ldap-кодирование значений (таких, как байты и т.д.) автоматически обрабатывается конвертерами Расширенных Фильтров. Например, если вы хотите найти пользователей по параметру «Время входа», не нужно задумываться о кодировании байтового значения Logon Hour в строковый формат LDAP. Расширенный Фильтр сделает это сам. Вы можете просто указать массив байт внутри Расширенного Фильтра.

PS D:\> $u = Get-ADUser Administrator -Properties *
PS D:\> $byt  = $u.logonHours
PS D:\> $byt.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Byte[]                                   System.Array

С помощью Расширенного Фильтра:

PS D:\> Get-ADUser -Filter { logonHours -eq $byt }

С помощью LDAP-фильтра:

## Каким-либо образом Ldap-кодируем byte[] в строку и помещаем ее в фильтр.
PS D:\> Get-ADUser -LdapFilter "(logonHours=\00\0B\FF\FF\FF\1F\FB\FF\AF\FF\FF\FC\FF\0A\FF\FF\FF\FF\FF\FF\1B)"

5. Поддержка значений в расширенном формате – Расширенный Фильтр поддерживает значения в расширенном формате .NET объектов и подходящих строковых форматах. Он также делает необходимое преобразование в формат поиска Ldap. Например:

PS D:\> Get-ADGroup -Filter {isCriticalSystemObject -eq $true } ## Получаем все системные критические группы

PS D:\> $SixtyDaysAgo = (Get-Date).Subtract((New-TimeSpan -Days 60))
PS D:\> Get-ADUser -Filter { lastLogonTimeStamp -notlike "*" -or  lastLogonTimeStamp -le $ SixtyDaysAgo }

## Получаем объекты всех пользователей, которые не входили в систему за последние 60 дней

PS D:\> Get-ADGroup -filter { groupType -band 0x80000000 } ## Получаем все группы безопасности, представляя целое значение в шестнадцатеричном формате.
                                              ## Аналогичный запрос LDAP выглядел бы так: 
                                              ## (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

Вот список поддерживаемых типов .NET:

System.Guid, System.Security.Cryptography.X509Certificates.X509Certificate, System.Security.Principal.SecurityIdentifier, System.DirectoryServices.ActiveDirectorySecurity

- Значения этих типов конвертируются в byte[] и затем кодируются в строку поиска Ldap.

System.DateTime

- Значения этого типа конвертируются в соответствующий формат даты Ldap - Large Integer/Interval, Generalized Time, UTC Coded Time.

System.String, System.Int32, System.Int64, System.UInt32, System.UInt64, System.Boolean, System.Byte, System.SByte, System.Int16, System.UInt16, System.Char, System.Single, System.Single, System.Double, System.Decimal

- Значения этих типов конвертируются в строковый формат.

На заметку: Все командлеты вида Get-AD* также поддерживают Ldap-фильтрацию через параметр -LdapFilter.

Cheers!
Swami

--
Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

Filed under: Filter

Оригинал: http://blogs.msdn.com/adpowershell/archive/2009/04/03/active-directory-powershell-advanced-filter.aspx

Перевод: Илья Лушников

Дополнение по Tab имен атрибутов LDAP внутри Расширенных фильтров

Andrey Beshkov — Mon, 30 Nov 2009 11:16:35 GMT

В своем предыдщем посте о Расширенных фильтрах я показал, как использовать переменные Powershell для представления значений внутри фильтров. Например:

PS D:\> $JohnSmith = Get-ADUser JohnSmith

PS D:\> Get-ADUser -Filter { manager -eq $JohnSmith.DistinguishedName }

## Получает все учетные записи пользователей, где менеджером указан JohnSmith

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

PS D:\> $SamAccountNameProperty = "SamAccountName"

PS D:\> Get-ADUser -Filter { $SamAccountNameProperty -eq "JohnSmith" }

## Получает объекты пользователей, где samAccountName = JohnSmith

Вы можете спросить: что такого интересного в этой возможности?

А теперь давайте представим, что у вас есть переменная PowerShell, которая содержит все имена атрибутов LDAP и имена свойств объектов AD PowerShell, представленные как свойства .NET, и вы бы хотели использовать эти переменные внутри фильтра. Когда в интерактивном режиме вы вводите строку фильтра в консоли Powershell, вы можете использовать дополнение по Tab для этих свойств. Это означает, что вам не требуется больше запоминать написание ваших любимых атрибутов LDAP!

Скажем, например, вы написали простой класс .NET:

public class ADObjectProp

{

public string ObjectGuid { get { return "objectGuid"; } }

public string Name { get { return "name"; } }

public string DistinguishedName { get { return "DistinguishedName"; } }

public string ObjectClass { get { return "ObjectClass"; } }

}

Теперь вы можете использовать переменные типа ADObjectProp внутри расширенного фильтра. Я называю такие переменные “переменные запросов”.

PS D:\> $queryADObject = new-object –type ADObjectProp

PS D:\> Get-ADObject -Filter { $queryADObject.Name -eq "JohnSmith" }

В показанном выше примере, если вы нажмете <TAB> после “$queryAODbject.”, PowerShell будет циклически перебирать все свойства. Можно также использовать неполное имя свойства и имена с универсальными символами («*», «?»), и PowerShell будет циклически перебирать подходящие свойства.

Это отличная возможность, особенно для тех, кому сложно запоминать все имена атрибутов LDAP и/или запоминать новые имена свойств, представленные в объектной модели AD Powershell. Теперь вопрос в том, как создать такой класс .NET, который бы содержал все имена атрибутов LDAP, представленные в вашей схеме? Для этого можно воспользоваться функцией Get-PossibleLdapAttributes, доступной в Active Directory Extensions и командлетом Add-Type, доступном в самом Powershell.

В Powershell можно динамически создавать собственные классы.NET с помощью командлета Add-Type. Вот команда Powershell, которая создает класс ADObjectProp (показанный выше):

PS D:\> Add-Type –Name ADObjectProp –NameSpace “Microsoft.ActiveDirectoryExtensions” –MemberDefinition ‘ public string ObjectGuid { get { return “objectGuid”; } } public string Name { get { return “name”; } } public string DistinguishedName { get { return “DistinguishedName”; } } public string ObjectClass { get { return “ObjectClass”; } }’ –PassThru

Инициализировать объект этого класса можно командой:

PS D:\> $xADObject = new-object –type Microsoft.ActiveDirectoryExtensions .ADObjectProp

Я изменил скрипт ActiveDirectoryExtensions для создания группы переменных запросов. Скрипт добавляет расширенные свойства для передаваемого типа объектов и получает список доступных атрибутов LDAP для соответствующего класса объектов, а также добавляет переменные запросов.

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

PS C:\> import-module ActiveDirectory

PS C:\> C:\ActiveDirectoryExtension.ps1

PS D:\> dir variable:xad*

Name Value

---- -----

xADObject Microsoft.ActiveDirectoryExtensions.ADObjectProp

xADPrincipal Microsoft.ActiveDirectoryExtensions.ADPrincipalProp

Вот таблица, где показаны все переменные запросов, созданные скриптом ActiveDirectoryExtensions и краткое описание каждой из них:

$xADObject	Содержит все расширенные свойства ADObject и LDAP-атрибуты объекта top
$xADPrincipal	Содержит все расширенные свойства ADPrincipal и LDAP-атрибуты объекта top
$xADAccount	Содержит все расширенные свойства ADAccount и LDAP-атрибуты объекта top
$xADGroup	Содержит все расширенные свойства ADGroup и LDAP-атрибуты для объекта group
$xADUser	Содержит все расширенные свойства ADUser и LDAP-атрибуты для объекта user
$xADComputer	Содержит все расширенные свойства ADComputer и LDAP-атрибуты для объекта computer
$xADOrganizationalUnit	Содержит все расширенные свойства ADOrganizationalUnit и LDAP-атрибуты для объекта organizationalUnit
$xADFineGrainedPasswordPolicy	Содержит все расширенные свойства ADFineGrainedPasswordPolicy и LDAP-атрибуты для объекта msDS-PasswordSettings
$xADServiceAccount	Содержит все расширенные свойства ADServiceAccount и LDAP-атрибуты для msDS-ManagedServiceAccount
$xADDomainController	Содержит все расширенные свойства ADDomainController

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

Вот примеры того, как можно использовать переменные запросов в консоли Powershell:

Get-ADObject -Filter { $xADUser.SamAccountName -eq "Administrator" }

## Можно набрать $xADUser.Sam<TAB> для дополнения по tab до $xADUser.SamAccountName

## Или можно набрать $xADUser.*Account*<TAB> и циклически перебирать значения для поиска SamAccountName

Get-ADObject -Filter { $xADUser.displayName -like "*Policy*" }

Get-ADObject -Filter { $xADObject.Name -eq "Administrator" }

Небольшое предупреждение об использовании переменных запросов при дополнении по tab:

- Многие LDAP-атрибуты, определенные в схеме AD, содержат дефис (‘-’). Так как имена свойств .NET не могут содержать дефис, скрипт был изменен для конвертирования дефисов (‘-’) в символы подчеркивания (‘_’). Таким образом, для написания фильтра с использованием атрибута “msDS-LastKnownRDN”, можно указать $xADUser.msDS_LastKnownRDN.

Get-ADObject -filter { $xADObject.msDS_LastKnownRDN -like "*" } -IncludeDeletedObjects

Наслаждайтесь!

Swami

Swaminathan Pattabiraman

Developer – Active Directory Powershell Team

Присоединенный файл: ActiveDirectoryExtension.ps1.txt

Оригинал

Перевод: Илья Лушников

Active Directory Administrative Center для Windows Server 2008 R2 реализован с помощью ADPowershell!

Andrey Beshkov — Fri, 27 Mar 2009 03:14:00 GMT

В Windows Server 2008 R2 добавлен не только ADPowershell – он также содержит Active Directory Administrative Center (или ADAC), новый графический инструмент для администраторов AD. Прочитать об этом можно здесь. Что нельзя определить, только взглянув на ADAC, - так это что он реализован полностью на Windows PowerShell 2.0 и ADPowershell! Каждое чтение и запись информации в AD происходит с помощью ADPowerShell. Итак, если вы думали, что Windows PowerShell и ADPowershell – это только для авторов сценариев - вы ошибались! Windows PowerShell и ADPowerShell представляют мощный и гибкий API для создания управляемых приложений любого типа.

С благодарностью,
Джон Ньюман (Jon Newman)
Active Directory Administrative Center
(раньше входил в команду разработки PowerShell 1.0)

Перевод: Илья Лушников

Сообщения об ошибках в Active Directory Powershell

Andrey Beshkov — Wed, 25 Mar 2009 17:08:00 GMT

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

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


PS C:\> New-ADUser -Name:"ADPSUser" -SamAccountName:"ADPSUser" -Enabled:$true
New-ADUser : The password does not meet the length, complexity, or history requirement of the domain.
At line:1 char:11
+ New-ADUser <<<<  -Name:"ADPSUser" -SamAccountName:"ADPSUser" -Enabled:$true
    + CategoryInfo          : InvalidData: (CN=ADPSUser,CN=...icrosoft,DC=com:String) [New-ADUser], ADPasswordComplexi
   tyException
    + FullyQualifiedErrorId : The password does not meet the length, complexity, or history requirement of the domain.
   ,Microsoft.ActiveDirectory.Management.Commands.NewADUser

Указанная выше ошибка – это на самом деле объект System.Management.Automation.ErrorRecord. В PowerShell, ошибки, произошедшие при выполнении командлетов и сценариев, сохраняются в переменной $Error (которая содержит объекты ErrorRecord). $Error – это массив, которые содержит последние ошибки, а переменная $Error[0] содержит самую последнюю ошибку.


PS C:\> $Error[0] | fl * -f
PSMessageDetails      :
Exception             : Microsoft.ActiveDirectory.Management.ADPasswordComplexityException: The password does not meet the ...
TargetObject          : CN=ADPSUser,...
CategoryInfo          : InvalidData: (CN=ADPSUser,CN=...icrosoft,DC=com:String) [New-ADUser], ADPasswordComplexityException
FullyQualifiedErrorId : The password does not meet the length, complexity, or history requirement of the ...
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
PipelineIterationInfo : {0, 1}

Как показано выше, ErrorRecord содержит объект Exception (Microsoft.ActiveDirectory.Management.ADPasswordComplexityException). AD PowerShell передает соответствующее исключение (exception) в зависимости от ошибки. Исключения могут быть System.UnauthorizedAccessException, System.TimeoutException, Microsoft.ActiveDirectory.Management.ADException и т.д.

На заметку: Исключения могут использоваться для обработки ошибок в сценарии. Я планирую написать об обработке ошибок в блоге более подробно. Вот еще несколько замечаний об обработке ошибок.

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


PS C:\> $Error[0].Exception | fl * -f
ErrorCode          : 1325
ServerErrorMessage : 0000052D: SvcErr: DSID-031A120C, problem 5003 (WILL_NOT_PERFORM), data 0
Message            : The password does not meet the length, complexity, or history requirement of the domain.
Data               : {}
InnerException     : System.ServiceModel.FaultException: Active Directory returned an error processing the operation.
TargetSite         : Void ThrowExceptionForExtendedError(System.String, System.Exception)
StackTrace         :    at Microsoft.ActiveDirectory.Management.AdwsConnection.ThrowExceptionForExtendedError(String extendedErrorMessage, Exception innerException) in ...
HelpLink           :
Source             : Microsoft.ActiveDirectory.Management

На заметку: ServerErrorMessage – это сообщение об ошибке, возвращенное сервером AD и кодировка текста в сообщении зависит от сервера.

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

--
Ашлиш Шарма (Ashish Sharma) [MSFT]
Developer – Active Directory Powershell Team

Перевод: Илья Лушников

Active Directory Powershell: Установка с помощью RSAT для Windows 7

Andrey Beshkov — Tue, 24 Mar 2009 09:58:00 GMT

Некоторые читали блога упоминали, что это было бы великолепно, если бы командлеты AD Powershell были доступны на клиенте Windows 7. Именно на этот случай и предназначен пакет Microsoft Remote Server Administration Tools (RSAT). Его можно загрузить здесь:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=82516c35-c7dc-4652-b2ea-2df99ea83dbb

Теперь большинство пользователей, включая меня, не хотят тратить время на чтение инструкций на странице загрузки, потомучто там нет красивых картинок :) Я бы хотел только загрузить файл, дважды кликнуть по нему для установки и чтобы установленные средства появились где-нибудь в меню «Пуск». Но все не так просто? Так давайте поговорим о том, что делать ПОСЛЕ установки пакета RSAT.

Подключите компонент Windows ADPowerShell

Выберите «Пуск» – «Панель управления» – «Программы».
В разделе «Программы и Компоненты» выберите «Установка и удаление компонентов Windows».
В окне «Компоненты Windows», разворачивайте дерево Remote Server Administration Tools, пока не выделите элемент Acitve Directory PowerShell Snap-In (см. скриншот ниже).
Нажмите OK.

Создаем ярлык «Админист��ирование»

Щелкните правой кнопкой мыши по кнопке «Пуск», выберите «Свойства».
На закладке «Меню «Пуск», нажмите «Настроить».
В окне «Настройка меню «Пуск», пролистайте до раздела «Администрирование» и выберите «Отображать в меню «Все программы» и «Пуск» (см. скриншот ниже).
Нажимайте OK для закрытия всех диалоговых окон.

Начинаем использовать оснастку Active Directory PowerShell

Нажмите «Пуск» - «Администрирование» - «Оснастка Active Directory PowerShell».

Вот видите, это ваш персональный ярлык, чтобы щелкнуть по нему и начать использовать Active Directory Module на клиенте Windows 7.

Мудассир Али (Mudassir Ali)
Software Development Engineer in Test - Active Directory Powershell Team

Перевод: Илья Лушников

Расширяем Active Directory Powershell

Andrey Beshkov — Fri, 20 Mar 2009 17:03:00 GMT

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

Несколько недель назад один из моих коллег (Александр Лаш - Alexander Lash) показал мне великолепную возможность PowerShell V2 под названием Script Cmdlets. С ее помощью можно писать полнофункциональные командлеты внутри модуля с помощью самого Powershell! Я подумал о том, что стоит поэкспериментировать немного с этим и сделать несколько командлетов, которые могут расширить функциональность командлетов AD. Итогом экспериментов стал новый модуль ActiveDirectoryExtension, в котором я и некоторые члены моей команды планируем добавить функции/командлеты, сделанные с помощью командлетов модуля Active Directory Module.

Первый набор командлетов, который я публикую сегодня – это расширение командлетов Get-ADUser, Get-ADGroup, которое поддерживает в качестве идентификаторов имена учетных записей в стиле NT4 (domain\username) и UPN (UserPrincipalName, например, username@domain.com).

Вот пример использования нового набора командлетов. Перед всеми существительными используемыми в названиях команд, установлен префикс “XAD”, что означает eXtending AD (расширение AD).

Загружаем модуль ActiveDirectoryExtension в память

Запускаем ActiveDirectoryExtensions.ps1 в консоли Powershell и импортируем модуль ActiveDirectoryExtensions. Полный текст скрипта и инструкции по его загрузке приведены ниже.

PS C:\> C:\ActiveDirectoryExtension.ps1
PS C:\> import-module ActiveDirectory

На заметку: Скопируйте вышеприведенные команды в файл $PROFILE,тогда ActiveDirectory и ActiveDirectoryExtension будут всегда загружаться при открытии консоли Powershell.

Примеры команд с использованием новых командлетов расширения

PS C:\> Get-XADUser administrator
PS C:\> Get-XADUser fabrikam\administrator       ## имя в стиле NT4. должно работать при обращении к другим лесам и доменам.
PS C:\> Get-XDAUser administrator@fabrikam.com   ## UPN. ВНИАНИЕ: имя UserPrincipalName должно быть предварительно настроено для учетной записи, чтобы это работало. 
                                                 ## Должно работать при обращении к другим доменам. 
PS C:\> Get-XADComputer myMemberServer *         ## Извлекает весь набор атрибутов объекта computer, идентифицированного как myMemberServer.
PS C:\> Get-XADComputer myMemberServer *  | Out-SortADProperties     ## Сортирует и отображает все свойства, найденные для объекта, в виде строки.
PS C:\> Get-PossibleLdapAttributes user        ## Выводит все атрибуты Ldap, которые могут быть установлены для объекта user
PS C:\> Get-PossibleLdapAttributes computer    ## Выводит все атрибуты Ldap, которые могут быть установлены для объекта computer
PS C:\> Get-PossibleLdapAttributes group       ## Выводит все атрибуты Ldap, которые могут быть установлены для объекта group
PS C:\> Get-PossibleLdapAttributes msDS-ManagedServiceAccount  ## Выводит все атрибуты Ldap, которые могут быть установлены для объекта service account

Скрипт

Вот полный скрипт:

ВНИМАНИЕ: Этот скрипт сделан только для подтверждения концепции и не планировался для использования в действующей инфраструктуре.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221

new-module -name ActiveDirectoryExtension -scriptblock {

#
# Описание: Эта функция сортирует все свойства, найденные в ADEntity, и 
# записывает их в консоль в виде строки.
# Протестировано в: Windows 2008 R2 Beta.
# 
function Out-SortADProperties() {     
   foreach ($msADE in $input) {
        $msADEProps = $msADE.PropertyNames | sort
        if ($msADEProps -ne $null) {
            foreach ($msADEProp in $msADEProps) {
                $msADEProp.ToString().PadRight(23) + ": " + $msADE[$msADEProp]
            }
        }
    }
}



#
# Описание: Эта функция выводит все атрибуты Ldap, которые могут быть установлены 
# для объекта типа objectClass.
# Протестировано в: Windows 2008 R2 Beta.
# 
function Get-PossibleLdapAttributes() {
    Param ([Parameter(Mandatory=$true, Position=0)] [String] $ObjectClass)
    $rootDSE = Get-ADRootDSE
    $schemaObject = get-adobject  -filter { ldapdisplayname -like $ObjectClass } -Properties mayContain, SystemMayContain, SubClassOf -searchbase  $rootDSE.SchemaNamingContext
    $schemaObject.MayContain
    $schemaObject.SystemMayContain
    if ($ObjectClass -ne "top" -and $schemaObject.SubClassOf -ne "" -and $schemaObject.SubClassOf -ne $null) {
        Get-PossibleLdapAttributes $schemaObject.SubClassOf
    }
}


#
# Описание: Следующие функции – это расширения над командлетами Get-ADUser, 
# Get-ADGroup, Get-ADComputer b Get-ADServiceAccount.
# В дополнение ко всем поддерживаемым видам идентификаторов для Get-ADUser, эта функция
# поддерживает имена в стиле NT4 (например: fabrikam\administrator)
# и имена UserPrincipalName - UPN (например: administrator@fabrikam.com)
# ВНИМАНИЕ: Имена в стиле NT4 будут работать между разными доменами и лесами,
# имена UPN будут работать только между разными доменами.
# Проверено в: Windows 2008 R2 Beta.
# 
function Get-XADUser() {
    Param (
        [Parameter(Mandatory=$true, 
                   Position=0,
                   ValueFromPipeline=$true,
                   HelpMessage="Идентификация объекта User. ВНИМАНИЕ: Поддерживаются имена в стиле NT4 (такие как fabrikam\administrator) и UPN (такие как administrator@fabrikam.com)"
                   )]
        [Object] $Identity,
        [Parameter(Mandatory=$false, 
                   Position=1,
                   HelpMessage="Список извлекаемых свойств"
                   )]
        [Object] $Properties
    )
    Get-XADPrincipal -Identity $Identity -ObjectType "ADUser" -Properties $Properties
}

function Get-XADGroup() {
    Param (
        [Parameter(Mandatory=$true, 
                   Position=0,
                   ValueFromPipeline=$true,
                   HelpMessage="Идентификация объекта Group. ВНИМАНИЕ: Поддерживаются имена в стиле NT4 Style (такие как fabrikam\mymachine)"
                   )]
        [Object] $Identity,
        [Parameter(Mandatory=$false, 
                   Position=1,
                   HelpMessage="Список извлекаемых свойств"
                   )]
        [Object] $Properties
    )
    Get-XADPrincipal -Identity $Identity -ObjectType "ADGroup" -Properties $Properties
}

function Get-XADComputer() {
    Param (
        [Parameter(Mandatory=$true, 
                   Position=0,
                   ValueFromPipeline=$true,
                   HelpMessage="Идентификация объекта Computer. ВНИМАНИЕ: Поддерживаются имена в стиле NT4 Style (такие как fabrikam\mymachine)"
                   )]
        [Object] $Identity,
        [Parameter(Mandatory=$false, 
                   Position=1,
                   HelpMessage="Список извлекаемых свойств"
                   )]
        [Object] $Properties
    )
    Get-XADPrincipal -Identity $Identity -ObjectType "ADComputer" -Properties $Properties
}

function Get-XADServiceAccount() {
    Param (
        [Parameter(Mandatory=$true, 
                   Position=0,
                   ValueFromPipeline=$true,
                   HelpMessage="Идентификация объекта ServiceAccount. ВНИМАНИЕ: Поддерживаются имена в стиле NT4 (такие как fabrikam\svcacct1)"
                   )]
        [Object] $Identity,
        [Parameter(Mandatory=$false, 
                   Position=1,
                   HelpMessage="Список извлекаемых свойств"
                   )]
        [Object] $Properties
    )
    Get-XADPrincipal -Identity $Identity -ObjectType "ADServiceAccount" -Properties $Properties
}


#
# Внутренняя служебная функция
#
function GetServer() {
   Param ([String] $serverName)

   if ($serverName -ne $null -and $serverName -ne "") {
       $portSeparatorInd = $serverName.IndexOf(":")
       if ($portSeparatorInd -ge 0) {
           $serverName.SubString(0, $portSeparatorInd)
       } 
       else {
           $serverName
       }
   }
   else {
       $rootdse = get-adrootdse
       $rootdse.dnsHostName
   }
}

#
# Внутренняя служебная функция
#
# Описание: Это служебная функция, которая является надстройкой над Get-ADUser,
# Get-ADGroup и т.д. Протестировано в: Windows 2008 R2 Beta.
# 
function Get-XADPrincipal() {
    [CmdletBinding(ConfirmImpact="Low")]
    Param (
        [Parameter(Mandatory=$true, 
                   Position=0,
                   ValueFromPipeline=$true,
                   HelpMessage="Идентификация учетной записи. ВНИМАНИЕ: Поддерживаются имена в стиле NT4 (такие как fabrikam\administrator)"
                   )]
        [Object] $Identity,
        [Parameter(Mandatory=$true, 
                   Position=1,
                   ValueFromPipeline=$false,
                   HelpMessage="Тип учетной записи. Поддерживаемые типы: G или ADGroup, U или ADUser, C или ADComputer, S или ADServiceAccount"
                   )]
        [String] $ObjectType,
        [Parameter(Mandatory=$false, 
                   Position=2,
                   HelpMessage="Список извлекаемых свойств"
                   )]
        [Object] $Properties
     )
        
    BEGIN {
    }

    PROCESS {
        if ($ObjectType -eq "ADUser" -or $ObjectType -eq "u") {
            $commandStr = "Get-ADUser "
        }
        elseif ($ObjectType -eq "ADGroup"-or $ObjectType -eq "g") {
            $commandStr = "Get-ADGroup "
        }
        elseif ($ObjectType -eq "ADComputer"-or $ObjectType -eq "c") {
            $commandStr = "Get-ADComputer " 
        }
        elseif ($ObjectType -eq "ADServiceAccount"-or $ObjectType -eq "s") {
            $commandStr = "Get-ADADServiceAccount " 
        }
        if ($Identity.GetType() -eq [String] ) {
            #
            # Допустимые имена в стиле NT4 всегда содержат обратный слэш \
            # Проверяем отсутствие символа '=' .. чтобы не обработать DN с \.
            #
            if ($Identity.Contains("\") -and ! $Identity.Contains("=") ) {
                [Int] $slashIndex = $Identity.IndexOf("\")
                $xNewServer      = $Identity.SubString(0, $slashIndex)
                $xNewIdentity = $Identity.SubString($slashIndex + 1)
                $commandStr += " -Identity $xNewIdentity -Server $xNewServer " 
            }
            #
            # Допустимые имена UPN всегда содержат @
            # Проверяем отсутствие символа '=' .. чтобы не обработать DN с @.
            #
            elseif ($Identity.Contains("@") -and ! $Identity.Contains("=") ) {
                $xNewServer = (GetServer $null) + ":3268"     # Обращаемся к глобальному каталогу для разрешения имен UPN
                $xFilter = " { userPrincipalName -eq '$Identity' } "
                $commandStr += " -Filter $xFilter -Server $xNewServer " 
            } 
            else {
               $commandStr += " -Identity $Identity "
            }
        }
        else {
             $commandStr += " -Identity '" + $Identity.ToString() + "'"
        }
        if ($Properties -ne $null) {
            $commandStr += " -Properties $Properties "
        }
        $scriptBlock = [ScriptBlock]::Create( $commandStr )
        $scriptBlock.Invoke()
    }

    END {

    }
}

} 

На здоровье!
Swami

--
Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

Перевод: Илья Лушников

Active Directory PowerShell: диск – это подключение

Andrey Beshkov — Sat, 14 Mar 2009 10:52:00 GMT

Те, у кого есть опыт работы с LDAP, ADSI и командлетами PowerShell для работы с Active Directory от третьих сторон, могут быть удивлены: а где командлеты для создания и закрытия подключения?

Ответ таков: жизненным циклом подключения автоматически управляют AD-командлеты. Если вы хотите, чтобы командлет подключался к определенному серверу, используйте параметр –server и присваивайте ему значение в формате «имя_сервера:порт». По умолчанию (если не указан параметр –server), командлеты попробуют самостоятельно найти применимый контроллер домена и установить соединение. Подключение закрывается командлетом перед выходом. Например:

PS C:\> Get-ADUser -Server "fabrikam.com:389" -credential "fabrikam.com\administrator" -filter { objectClass -like "*" } -SearchBase "OU=Accounts Department,DC=fabrikam,DC=com"

Классно, да? Но подождите, здесь нужна одна оговорка. Когда используется приведенный выше метод, новое подключение будет открываться и закрываться при каждом вызове командлета. Это нормально, когда делаются одна-две операции, но очень неэффективно для пачки операций. Так как вы можете использовать одно соединение для нескольких вызовов командлетов?

Ответ таков: используйте диск PowerShell (PSDrive) для Active Directory и используйте командлеты в контексте этого диска. Active Directory PSDrive поддерживает постоянное соединение с указанным/найденным сервером и оно может быть использовано всеми командлетами, запускаемыми в этом контексте. Диск также обслуживает жизненный цикл соединения, так что если соединение закрывается по таймауту или по другой причине, то новое подключение создается за ним.

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

PS C:\> New-PSDrive -PSProvider ActiveDirectory -Name GC -Root "" -Server "fabrikam.com:3268"
Name           Used (GB)     Free (GB) Provider      Root
----           ---------     --------- --------      ----
GC                                     ActiveDire...

PS D:\> cd GC:
PS GC:\>

На заметку: если вы указываете для параметра –server имя домена вместо имени контроллера домена, командлет New-PSDrive найдет контроллер в искомом домене и подключится к нему. Преимущество подхода в том, что если контроллер домена по какой-то причине недоступен, диск сможет найти другой подходящий контроллер и подключиться к нему.

New-PSDrive и другие AD-командлеты не имеют опций (типа DC-Locator) для поиска определенного контроллера домена – эмулятора PDC, глобального каталога и т.д. Если вы хотите подключиться к контроллеру домена со специфической ролью, вы можете использовать другие AD-командлеты (Get-ADDomainController, Get-ADForest и т.д.) и использовать их вывод для определения нужного сервера.

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

PS D:\> New-PSDrive -PSProvider ActiveDirectory -Name PdcDrive -Root "" -Server (Get-ADDomainController -Discover -Service PrimaryDC).Name

Name           Used (GB)     Free (GB) Provider      Root
----           ---------     --------- --------      ----
PdcDrive                               ActiveDire...

Вот пример создания нового диска, подключенного к владельцу FSMO-роли Хозяина Схемы (Schema Master) с помощью командлета Get-ADForest:

PS D:\> New-PSDrive -PSProvider ActiveDirectory -Name SchemaMasterDrive -Root "" -Server (Get-ADForest -Current LoggedOnUser).SchemaMaster

Name           Used (GB)     Free (GB) Provider      Root
----           ---------     --------- --------      ----
SchemaM...                             ActiveDire...

Чтобы увидеть список дисков ActiveDirectory PSDrive, подключенных к консоли, введите:

PS D:\> Get-PSDrive -PSProvider ActiveDirectory

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

Наслаждайтесь!

Swami

-
Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

Перевод: Илья Лушников

Обзор Active Directory PowerShell:

Andrey Beshkov — Sat, 14 Mar 2009 10:46:00 GMT

Хотя с помощью PowerShell можно легко просмотреть список всех командлетов AD, многие из вас, возможно, захотят просмотреть список командлетов AD, с классификацией по административным сценариям и задачам. Итак…

Текущий набор командлетов AD PowerShell может быть разделен на четыре больших категории:

Управление аккаунтами
Управление топологией
Управление объектами каталога
Командлеты провайдера

Командлеты управления аккаунтами:

Создают, удаляют, изменяют и читают объекты пользователей, групп, компьютеров, управляемых аккаунтов служб и организационных подразделений (OU)
Управляют свойствами аккаунтов: дата истечения, пароль и т.д.
Управляют членством в группах, получают список групп, в которые включен аккаунт
Управляют гибко назначаемой политикой паролей и политикой паролей домена по умолчанию

Командлеты управления топологией:

Находят контроллеры домена, управляют ролями FSMO, перемещают контроллеры домена между сайтами и получают информацию о контроллерах доменов
Управляют политикой репликации пароля контроллера домена только для чтения (Read-only domain controller – RODC)
Управляют доменами и лесами, устанавливают функциональный уровень домена и леса.
Управляют прочими возможностями

Командлеты управления объектами каталога:

Создают, удаляют, изменяют и читают объекты AD любых типов
Перемещают, переименовывают и восстанавливают объекты AD

Командлеты провайдера позволяют работать с AD через специальный диск PowerShell (PSDrive), указывающий на каталог AD. Для этого используются привычные функции для работы с файловой системой.

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

Наслаждайтесь!

Swami

-
Swaminathan Pattabiraman [MSFT]
Developer – Active Directory Powershell Team

Перевод: Илья Лушников

Модуль Active Directory для Windows PowerShell – Руководство по быстрому старту (Quick start guide)

Andrey Beshkov — Wed, 25 Feb 2009 13:10:00 GMT

Командлеты AD Powershell доступны, начиная с Windows Server 2008 R2. Чтобы использовать командлеты AD Powershell, в домене должен быть хотя бы один контроллер на основе Windows Server 2008 R2.

Установка модуля AD Powershell:

В Windows Server 2008 R2, откройте окно консоли PowerShell (powershell.exe) и выполните команды:

PS C:\> import-module servermanager
PS C:\> Add-WindowsFeature -Name "RSAT-AD-PowerShell" –IncludeAllSubFeature

Примечание: модуль AD Powershell по умолчанию уже установлен на котроллере домена.

Загрузка модуля AD Powershell:

Откройте окно консоли PowerShell и наберите:

PS C:\> import-module activedirectory

Если компьютер включен в домен, по умолчанию создается диск по имени AD: Вы можете перейти на этот диск командой CD и использовать привычные команды работы с файловой системой для навигации по этому диску. Пути представлены в формате X500.

PS C:\> cd AD:
PS AD:\>
PS AD:\> dir
…
PS AD:\> cd "DC=fabrikam,DC=com"
PS AD:\DC=fabrikam,DC=com> md "OU=myNewOU"
…
PS AD:\DC=fabrikam,DC=com> del "OU=myNewOU"

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

PS C:\> New-PSDrive -PSProvider ActiveDirectory -Server "contoso.fabrikam.com" -Credential "Contoso\Administrator" -Root "" -Name Contoso -FormatType Canonical
…
PS C:\> cd Contoso:
PS Contoso:\> dir | ft CanonicalName
…
PS Contoso:\> cd "contoso.fabrikam.com/"

Как получить список командлетов, описание и примеры:

PowerShell использует имена командлетов, состоящие из глагола и существительного. Например:

New-ADGroup
Get-ADDomain

Чтобы получить список командлетов, посвященных AD, введите:

PS AD:\> get-help *-AD*
PS AD:\> get-help New-AD* ## просматриваем все командлеты, создающие новые объекты AD

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

PS AD:\> get-help set-aduser -detailed
PS AD:\> get-help get-aduser –examples

На заметку: Вы можете дополнять имена командлетов PowerShell или параметров с помощью кнопки < Tab>. Например, после ввода глагола из названия командлета, нажимайте кнопку <Tab> для циклического просмотра существительных, которые допустимы для этого глагола, чтобы составить название командлета.

Типовые применения:

Ниже приведены несколько примеров решения типовых административных задач с помощью командлетов AD:

PS C:\> New-ADUser –Name "John Smith" –SamAccountName JohnS –DisplayName "John Smith" –Title "Account Manager" –Enabled $true –ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "p@ssw0rd" -AsPlainText -force) -PassThru

PS C:\> New-ADGroup -Name "Account Managers" -SamAccountName AcctMgrs -GroupScope Global -GroupCategory Security -Description "Account Managers Group" –PassThru

PS C:\> New-ADOrganizationalUnit -Name AccountsDepartment -ProtectedFromAccidentalDeletion $true -PassThru

PS C:\> Get-ADUser -Filter { name –like "john*" } ## Получаем объекты всех пользователей, чьи имена начинаются с «John»

PS C:\> Add-ADGroupMember -Identity AcctMgrs -Members JohnS

PS C:\> Get-ADGroupMember -Identity AcctMgrs

PS C:\> Get-ADPrincipalGroupMembership -Identity JohnS ## Получаем список всех групп, в которые непосредственно включен указанный пользователь

PS C:\> Get-ADAccountAuthorizationGroup -Identity JohnS ## Получаем список всех групп, чьи идентификаторы (SID) включены в билет доступа (token) аккаунта

PS C:\> Unlock-ADAccount -Identity JohnS

PS C:\> Get-ADForest -Current LocalComputer

PS C:\> Get-ADDomain -Current LoggedOnUser

PS C:\> Get-ADDomainController -Filter { name -like "*" } ## Получаем все контроллеры домена текущего домена

Что дальше?

В следующем посте мы сделаем обзор Active Directory PowerShell и поговорим о различных командлетах, которые мы предлагаем.

Наслаждайтесь!

Swami

Swaminathan Pattabiraman [MSFT]

Developer – Active Directory Powershell Team

Перевод: Илья Лушников

Добро пожаловать!

Andrey Beshkov — Wed, 18 Feb 2009 23:02:00 GMT

Приветствую вас в блоге Active Directory PowerShell! Этот блог создан группой разработчиков, тестировщиков, менеджеров и технических писателей из команды Active Directory PowerShell.

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

Перевод: Илья Лушников