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

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

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

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

Создаем объект 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 (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)

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

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

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

Оригинал

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

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

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

1. Если были случайно удалены несколько объектов, обычно все такие объекты удаляются за короткий промежуток времени. Это может быть действие непрофессиональных сотрудников во время установки приложения или некорректный скрипт, который удалил не только те объекты, которые требовалось, но и другие тоже, или неуклюжий администратор, удаливший целое дерево OU, или даже действие злоумышленника – в любом случае, обычно такие удаления происходят за несколько секунд или минут.
2. При случайном удалении нескольких объектов, обычно все эти объекты удаляются с одного контроллера домена.
3. Данные в 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: и используйте скрипт, как показано в примерах. Не требуется включать корзину, чтобы скрипт работал.

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

Оригинал

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

1. Заходим на сайт https://connect.microsoft.com и вводим код приглашения ADWS-FDBT-CVJK на главной странице.
2. Входим под своим live/hotmail ID
3. Сведения о загрузке Active Directory Management Gateway Service и инструкции доступны на сайте MS Connect - https://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 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

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

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

В своем предыдщем посте о Расширенных фильтрах я показал, как использовать переменные 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

Оригинал

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

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

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