Глава 16. Расширенное управление Active Directory с помощью PowerShell

Модуль PowerShell содержит сборки, сценарии и функциональные возможности. Для применения имеющихся функциональных возможностей нам требуется импортировать этот модуль. После этого мы получаем способность вызова содержимого данного модуля для управления относящимися к делу ролями сервера, службами или свойствами. Прежде чем мы приступим к управлению AD при помощи PowerShell, для начала нам требуется импортировать соответствующий модуль ActiveDirectory.

Для осуществления этого имеется несколько способов. Они включают установку надлежащей роли сервера AD DS или производятся через RSAT (Remote Server Administration Tools, инструменты удалённого администрирования сервером):

После установки необходимого модуля AD DS мы имеем возможность перечислить все доступные в этом модуле команды воспользовавшись такой командой:

Get-Command -Module ActiveDirectory
		

В данном модуле имеется примерно 147команд. Полный синтаксис для любой из команд можно просмотреть воспользовавшись следующей командой:

Get-Command commandname -Syntax
		

В качестве примера, приводимая ниже команда перечислит необходимый синтаксис для команды New-ADUser:

Get-Command New-ADUser -Syntax
		

Следующий снимок экрана отображает вывод для приведённой выше команды:

Для любой из команд команда Get-Help предоставляет подсказку. В качестве примера, приводимая далее команда предоставляет подсказку для команды New-ADUser:

Get-Help New-ADUser
		

Приводимый ниже снимок экрана отображает вывод приведённой выше команды:

Также мы имеем возможность просмотреть некий образец для своей команды New-ADUser при помощи следующего:

Get-Help New-ADUser -Example
		

отображаемый далее снимок экрана показывает вывод для нашей предыдущей команды:

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

Get-Help New-ADUser -Detailed
		

Технические сведения по определённой команде можно просмотреть воспользовавшись командой таким образом:

Get-Help New-ADUser -Full
		

Сведения о выбранной команде в реальном режиме времени можно просмотреть при помощи такого варианта:

Get-Help New-ADUser -Online
		

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

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

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

Get-ADRootDSE
		

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

Наш следующий шаг состоит в поиске контроллеров домена в своём домене. Для перечисления значений имени контроллера домена, состояния его сервера глобального каталога и установленных ролей FSMO (Flexible Single Master Operation, Гибких операций единственного хозяина) мы можем применить следующее:

Get-ADDomainController -Filter * | Select-Object Name,IPv4Address,IsGlobalCatalog,OperationMasterRoles
		

Также важно иметь сведения относительно значения площадки AD, так как оно поясняет имеющуюся физическую топологию данного AD:

Get-ADDomainController -Filter * | Select-Object Name,IPv4Address,Site
		

Некий лес AD способен обладать множеством доменов. Наша следующая команла перечислит значения имён лесов, имён доменов, названий контроллеров доменов, IP адресов и площадки AD:

$Forestwide = (Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ }
write-output $Forestwide -Filter * | Select-Object Name,Forest,Domain,IPv4Address,Site
		

Когда нам известны значения имён доменов, мы способны перечислить соответствующие контроллеры домена и RODC (read-only domain controller), воспользовавшись такой командой:

$Domain = Read-Host 'What is your Domain Name ?'
Get-ADDomain -Identity $Domain | select ReplicaDirectoryServers,ReadOnlyReplicaDirectoryServer
		

При помощи этой команды его система запросит у своего пользователя ввод значения имени домена. После отклика пользователя она перечислит все контроллеры домена.

В нашей предыдущей команде, ReplicaDirectoryServers представит контроллеры домена с доступом на чтение и запись, а ReadOnlyReplicaDirectoryServer снабдит лишь контроллерами домена, доступными только для чтения.

Репликация

Для жизнеспособности некой среды AD критически важна репликация сведений. Для некого заданного контроллера домена мы можем найти его входящих партнёров реплик при помощи следующего:

Get-ADReplicationPartnerMetadata -Target REBEL-SRV01.rebeladmin.com
		

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

Воспользовавшись своей следующей командой мы можем перечислить всех имеющихся входных партнёров для заданной репликации:

Get-ADReplicationPartnerMetadata -Target "rebeladmin.com" -Scope Domain
		

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

Соответствующие связанные отказы репликаций для площадки, домена и контроллера домена можно найти при помощи cmdlet Get-ADReplicationFailure:

Get-ADReplicationFailure -Target REBEL-SRV01.rebeladmin.com
		

Наша предыдущая команда перечислит все отказы репликаций для заданного контроллера домена.

Отказы репликаций для определённого домена могут быть найдены при помощи следующего:

Get-ADReplicationFailure -Target rebeladmin.com -Scope Domain
		

отказы репликаций для конкретного леса могут быть определены с применением такой команды:

Get-ADReplicationFailure -Target rebeladmin.com -Scope Forest
		

Отказы репликаций для заданной площадки можно отыскать воспользовавшись приводимой ниже команды:

Get-ADReplicationFailure -Target LondonSite -Scope Site
		

В приведённой выше команде LondonSite можно заменить необходимым вам названием площадки.

Воспользовавшись как Get-ADReplicationPartnerMetadata, так и Get-GetADReplicationFailure, я создал свой следующий сценарий PowerShell для выработки отчёта о жизнеспособности репликации для конкретного контроллера домена.

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

## Active Directory Domain Controller Replication Status##
 $domaincontroller = Read-Host 'What is your Domain Controller?'
 ## Define Objects ##
 $report = New-Object PSObject -Property @{
 ReplicationPartners = $null
 LastReplication = $null
 FailureCount = $null
 FailureType = $null
 FirstFailure = $null
 }
 	   

В своём предыдущем сценарии я задал некий параметр для того чтобы конкретный инженер определил значение имени необходимого контроллера домена:

$domaincontroller = Read-Host 'What is your Domain Controller?'
		

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

## Replication Partners ##
 $report.ReplicationPartners = (Get-ADReplicationPartnerMetadata -Target $domaincontroller).Partner
 $report.LastReplication = (Get-ADReplicationPartnerMetadata -Target $domaincontroller).LastReplicationSuccess
 	   

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

## Replication Faliures ~##
 $report.FailureCount = (Get-ADReplicationFailure -Target $domaincontroller).FailureCount
 $report.FailureType = (Get-ADReplicationFailure -Target $domaincontroller).FailureType
 $report.FirstFailure = (Get-ADReplicationFailure -Target $domaincontroller).FirstFailureTime
 	   

Самая последняя часть моего сценария форматирует получаемый вывод для всех собранных сведений:

## Format Output ##
 $report | select ReplicationPartners,LastReplication,FirstFailure,FailureCount,FailureType | Out-GridView
 	   

Последующий снимок экрана отображает получаемый вывод для нашего предыдущего сценария.

Далее в топологиях репликаций AD имеются два типа репликаций:

С помощью cmdlet Get-ADReplicationSite мы имеем возможность просмотра объектов реплицируемых площадок AD. Наша следующая команда вернёт все значения реплицируемых площадок определённого AD в заданном лесу AD:

Get-ADReplicationSite -Filter *
		

При помощи приводимой далее команды мы имеем возможность просмотра соединений реплицируемой площадки AD в определённом лесу AD:

Get-ADReplicationSiteLink -Filter *
		

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

приводимая далее команда перечисляет все имеющиеся связи реплицируемой площадки, которые содержат CanadaSite, совместно со значениями названия соединения, стоимостью соединения и частоты соединения:

Get-ADReplicationSiteLink -Filter {SitesIncluded -eq "CanadaSite"} | Format-Table Name,Cost,ReplicationFrequencyInMinutes -AutoSize
		

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

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

Get-ADReplicationSiteLinkBridge -Filter *
		

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

Приводимая далее команда выдаст список всех подсетей в данном лесу в виде некой таблицы со значениями названий подсети и площадки AD:

Get-ADReplicationSubnet -Filter * | Format-Table Name,Site -AutoSize
		

Серверы плацдарма работают в качестве соответствующей первичной точки взаимодействия для обработки поступающих и уходящих прочь из данной площадки AD реплицируемых сведений.

Мы имеем возможность перечислить все имеющиеся в неком домене серверы плацдарма:

$BHservers = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com").bridgeheadServerListBL
$BHservers | Out-GridView
		

В нашей предыдущей команде необходимое значение атрибута bridgeheadServerListBL получается через имеющееся соединение ADSI.

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

Как обычно, самая первая часть нашего сценария посвящается определению объектов:

## Script to gather information about Replication Topology ##
 ## Define Objects ##
 $replreport = New-Object PSObject -Property @{
 Domain = $null
 }
 	   

Прежде чем мы перейдём к самой репликации, неплохо собрать сведения о своём домене Active Directory. Это важно когда некая организация пользуется множеством доменов, ибо мы способны запросто разделять отчёты:

## Find Domain Information ##
 $replreport.Domain = (Get-ADDomain).DNSroot
 	   

Для перечисления имеющихся площадок Active Directory я воспользовался следующей частью своего сценария:

## List down the AD sites in the Domain ##
 $a = (Get-ADReplicationSite -Filter *)
 Write-Host "########" $replreport.Domain "Domain AD Sites" "########"
 $a | Format-Table Description,Name -AutoSize
 	   

Затем я намерен собрать сведения относительно имеющихся соединений реплицируемых площадок Active Directory и мосте соединений реплицируемых площадок Active Directory таким образом:

## List down Replication Site link Information ##
 $b = (Get-ADReplicationSiteLink -Filter *)
 Write-Host "########" $replreport.Domain "Domain AD Replication SiteLink Information" "########"
 $b | Format-Table Name,Cost,ReplicationFrequencyInMinutes -AutoSize
 ## List down SiteLink Bridge Information ##
 $c = (Get-ADReplicationSiteLinkBridge -Filter *)
 Write-Host "########" $replreport.Domain "Domain AD SiteLink Bridge Information" "########"
 $c | select Name,SiteLinksIncluded | Format-List
 	   

В вычислительных сетях существует множество подсетей IP. Эти подсети надлежит назначать должным образом площадкам Active Directory. Тем самым, компьютеры контроллеров домена Active Directory узнают к каким площадкам они относятся. Это также оказывает непосредственное воздействие на репликацию Active Directory. В своём следующем разделе мы намерены собрать сведения о подсети Active Directory и предпочтительных главных серверах мостов для данного домена:

## List down Subnet Information ##
 $d = (Get-ADReplicationSubnet -Filter * | select Name,Site)
 Write-Host "########" $replreport.Domain "Domain Subnet Information" "########"
 $d | Format-Table Name,Site -AutoSize
 ## List down Prefered BridgeHead Servers ##
 $e = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com").bridgeheadServerListBL
 Write-Host "########" $replreport.Domain "Domain Prefered BridgeHead Servers" "########"
 $e
 ## End of the Script ##
 	   

В своём предыдущем сценарии нам требуется заменить значение соединения ADSI относящимся к делу DN домена:

$e = ([adsi]"LDAP://CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com")
		

Репликация конкретного объекта

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

## Replicate Object to From Domain Controller to Another ##
$myobject = Read-Host 'What is your AD Object Includes ?'
$sourcedc = Read-Host 'What is the Source DC ?'
$destinationdc = Read-Host 'What is the Destination DC ?'
$passobject = (Get-ADObject -Filter {Name -Like $myobject})
Sync-ADObject -object $passobject -source $sourcedc -destination $destinationdc
Write-Host "Given Object Replicated to" $destinationdc
 	   

Наш предыдущий сценарий задаст несколько вопросов:

После предоставления надлежащих сведений указанный объект будет принудительно реплицирован:

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

В этом разделе давайте взглянем на команды и сценарии PowerShell, которые мы можем применять для управления пользователями и группами AD.

Время последней регистрации

при определённых обстоятельствах нам необходимо отыскивать когда какой- то пользователь выполнял успешную регистрацию в домене. Это может служить целям аудита или поиска неисправностей:

$username = Read-Host 'What is the User account you looking for ?'
   $dcs = Get-ADDomainController -Filter {Name -like "*"}
      foreach($dc in $dcs)
   { 
     $hostname = $dc.HostName
     $user = Get-ADUser $userName -Server $hostname -Properties lastLogon
     $lngexpires = $user.lastLogon
     if (-not ($lngexpires)) {$lngexpires = 0 }
     If (($lngexpires -eq 0) -or ($lngexpires -gt [DateTime]::MaxValue.Ticks))
     {
       $LastLogon = "User Never Logged In"
     }
      Else
     {
       $Date = [DateTime]$lngexpires
       $LastLogon = $Date.AddYears(1600).ToLocalTime()
     }
  }
  Write-Host $username "last logged on at:" $LastLogon
 	   

Наш предыдущий сценарий запросит имя пользователя определённой учётной записи и, после его предоставления, наша система отыщет необходимое значение атрибута lastLogon во всех доступных контроллерах домена. Если его нельзя найти, он возвратит User Never Logged In , или, в случае обнаружения, он вернёт значение временной метки последней регистрации.

Отчёт о дате последней регистрации

Для целостности требуется периодическая чистка в AD. Могут существовать объекты пользователей, которые не использовались на протяжении лет. Если бы мы могли создать некий общий отчёт с самыми последними датами входа в систему, мы бы могли применять их в качестве справочника для очистки объектов:

## Script For Filter user with Last logon Time ##
$htmlformat = "<style>BODY{background-color:LightBlue;}</style>"
Get-ADUser -Filter * -Properties "LastLogonDate" | sort-object -property lastlogondate -descending | Select-Object Name,LastLogonDate | ConvertTo-HTML -head $htmlformat -body "<H2>AD Accounts Last Login Date</H2>"| Out-File C:\lastlogon.html
Invoke-Expression C:\lastlogon.html
 	   

Этот сценарий создаёт некий отчёт HTML, который содержит все учётные записи пользователей с их временными отметками самой последней даты входа в систему:

Отчёт о об отказах регистрации

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

Приводимый ниже сценарий создаст некий отчёт для указания отказов во входе в систему в неком заданном контроллере домена:

## Report for DC login Failures ##
$failedevent = $null
$Date= Get-date 
$dc = Read-Host 'What is the Domain Controller ?'
$Report= "C:\auditreport.html"
$HTML=@"
<title>Failed Login Report for $dc</title>
<style>
BODY{background-color :LightBlue}
</style>
"@
 $failedevent = Get-Eventlog security -Computer $dc -InstanceId 4625 -After (Get-Date).AddDays(-7) |
 Select TimeGenerated,ReplacementStrings |
 % {
 New-Object PSObject -Property @{
 SourceComputer = $_.ReplacementStrings[13]
 UserName = $_.ReplacementStrings[5]
 SourceIPAddress = $_.ReplacementStrings[19]
 Date = $_.TimeGenerated
 }
 }
 $failedevent | ConvertTo-Html -Property SourceComputer,UserName,SourceIPAddress,Date -head $HTML -body "<H2>Failed Login Report for $dc</H2>"|
 Out-File $Report
 Invoke-Expression C:\auditreport.html
 	   

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

Приводимый далее снимок экрана показывает отчёт отказов для REBEL-PDC-01:

Поиск блокированной учётной записи

При назначенных политиках пароля, учётные записи с большим числом отказов во входе в систему будут заблокированы. Заблокированные учётные записи в некой среде AD можно отыскать при помощи такой команды:

Search-ADAccount -Lockedout | Select name,samAccountName,Lockedout
		

Когда кто- то из этого списка должен быть разблокирован, мы можем воспользоваться для разблокирования учётной записи имеющимся cmdlet Unlock-ADAccount.

Для некой индивидуальной учётной записи выполните следующую команду:

Unlock-ADAccount tuser4
		

Для всех учётных записей из полученного списка выполните такую команду:

Search-ADAccount -Lockedout | Unlock-ADAccount
		

Отчёт об истечении срока действия пароля

Распространённым обращением в службу поддержки являются проблемы, вызванные истечением срока паролей. Приводимый ниже сценарий способен выработать некий отчёт относительно паролей с истекшей датой:

## Password Expire Report ##
$passwordreport = $null
$dc = (Get-ADDomain | Select DNSRoot).DNSRoot
$Report= "C:\passwordreport.html"
$HTML=@"
<title>Password Expire Report For $dc</title>
<style>
BODY{background-color :LightBlue}
</style>
"@
$passwordreport = Get-ADUser -filter * –Properties "SamAccountName","pwdLastSet","msDS-UserPasswordExpiryTimeComputed" | Select-Object -Property "SamAccountName",@{Name="Last Password Change";Expression={[datetime]::FromFileTime($_."pwdLastSet")}},@{Name="Next Password Change";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}
$passwordreport | ConvertTo-Html -Property "SamAccountName","Last Password Change","Next Password Change"-head $HTML -body "<H2>Password Expire Report For $dc</H2>"|
Out-File $Report
Invoke-Expression C:\passwordreport.html
 	   

Данный сценарий отыщет необходимые значения атрибутов для SamAccountName, pwdLastSet и msDS-UserPasswordExpiryTimeComputed во всех объектах пользователей. Далее они будут представлены в отчёте HTML:

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

Как и было обещано в нашей предыдущей главе, давайте теперь рассмотрим как получить установленными и настроенными JEA.

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

Install-Module xJEA
		

После его установки мы способны убедиться в этом при помощи такой команды:

Find-Module –Name xJEA | fl
		

Настройка JEA

Теперь, когда мы обладаем установленным модулем JEA, наш следующий шаг состоит в подготовке необходимой среды для применения JEA. Это можно осуществить при помощи сценария, который поступает с самим модулем JEA. Он располагается в C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples\SetupJEA.ps1.

Этот сценарий осуществит следующее:

Configuration SetupJea
    {
      Import-DscResource -module xjea Node localhost
      {
        xJeaEndPoint CleanAll
        {
          Name     = 'CleanALL'
          CleanAll = $true
        }
        LocalConfigurationManager
        {
          RefreshFrequencyMins = 30
          ConfigurationMode    = "ApplyAndAutoCorrect"
          DebugMode            = "ForceModuleImport"  
          #This disables provider caching
        }
      }
    }
    SetupJea -OutputPath C:\JeaDemo
    Set-DscLocalConfigurationManager -Path C:\JeaDemo -Verbose
    Start-DscConfiguration -Path c:\JeaDemo -Wait -Verbose
    #EOF
 	   

Для запуска этого сценария перейдите в каталог C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples\ и запустите .\SetupJEA.ps1, как это показано на следующем снимке экрана:

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

Проверка

JEA поставляется с тремя демонстрационными настройками конечных точек, которыми можно пользоваться в качестве руководства для создания некой конечной точки. Эти демонстрационные файлы расположены в C:\ProgramFiles\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples, а также Demo1.ps1, который содержит следующее:

cls configuration Demo1
{
  Import-DscResource -module xjea
  xJeaToolKit Process
  {
    Name         = 'Process'
    CommandSpecs = @"Name,Parameter,ValidateSet,ValidatePattern Get-Process 
    Get-Service Stop-Process,Name,calc;notepad 
    Restart-Service,Name,,^A"@
  }
  xJeaEndPoint Demo1EP
  {
    Name                   = 'Demo1EP'
    Toolkit                = 'Process'
    SecurityDescriptorSddl = 
      'O:NSG:BAD:P(A;;GX;;;WD)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)'                     
    DependsOn              = '[xJeaToolKit]Process'
  }
}
Demo1 -OutputPath C:\JeaDemo

Start-DscConfiguration -Path C:\JeaDemo -ComputerName localhost -Verbose -wait -debug -ErrorAction SilentlyContinue -ErrorVariable errors
if($errors | ? FullyQualifiedErrorId -ne 'HRESULT 0x803381fa')
{
    $errors | Write-Error    
}

start-sleep -Seconds 30 #Wait for WINRM to restart

$s = New-PSSession -cn . -ConfigurationName Demo1EP
Invoke-command $s {get-command} |out-string
Invoke-Command $s {get-command stop-process -Syntax}
# Enter-pssession $s
Remove-PSSession $s
#EOF
 	   

Что касается настроек такой конечной точки, пользователям разрешается применять лишь такие cmdlet:

Наш предыдущий cmdlet Stop-Process может применяться только для останова калькулятора. Однако он также позволяет вам применять без ограничений Restart-Service, Get-Process и Get-Service.

Для развёртывания этой конечной точки мы можем применить .\Demo1.ps1.

После успешного выполнения этого мы можем проверить настройку полученного нового сеанса PowerShell при помощи следующего:

Get-PSSessionConfiguration
		

Следующий снимок экрана отображает вывод нашей предыдущей команды:

Наш следующий этап состоит в подключении к новой конечной точке. Это можно сделать при помощи такой команды:

Enter-PSSession –ComputerName localhost –ConfigurationName demo1ep
		

В нашей предыдущей команде –ConfigurationName задаёт значение названия конечной точки.

Как только мы выполним эту команду, наша система подключается к соответствующей конечной точке и изменяет значение пути на C:\Users\JSA-Demo1EP\Documents:

Этот пользователь устанавливается в качестве части общего процесса установки со стороны JEA. Он выступает в качестве учётной записи данного сеанса PowerShell. Также эта учётная запись является частью группы локальных администраторов:

Наш следующий снимок экрана подтверждает такое участие в локальной группе безопасности Administrators:

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

Тот пользователь, под которым я вошёл в данный компьютер является локальным администратором. Поэтому я обладаю достаточными полномочиями для перезапуска этого компьютера при помощи cmdlet Restart-Computer. Однако когда я применяю эту команду через созданную конечную точку, это должно мне быть запрещено в соответствии с настройкой этой конечной точки.

Как мы можем видеть из предыдущего снимка экрана, всё работает как мы и ожидали. Пользователям дозволено работать исключительно с командами, допускаемыми конфигурацией этой конечной точки. Эти настройки не будут допустимыми для иного компьютера пока не применяются те же самые настройки конечной точки.

Настройки конечной точки Demo2.ps1 сосредоточены вокруг соответствующего администратора файлового сервера:

cls
configuration Demo2
{
  Import-DscResource -module xjea

  xJeaToolKit SMBGet
  {
    Name = 'SMBGet'
    CommandSpecs = @" Module,Name,Parameter,ValidateSet,ValidatePattern
      SMBShare,get-* "@
  }
  xJeaEndPoint Demo2EP
  {
    Name = 'Demo2EP'
    Toolkit = 'SMBGet'
    SecurityDescriptorSddl = 'O:NSG:BAD:P(A;;GX;;;WD)S:P(AU;FA;GA;;;WD)
      (AU;SA;GXGW;;;WD)' 
    DependsOn = '[xJeaToolKit]SMBGet'
  }
}

Demo2 -OutputPath C:\JeaDemo
Start-DscConfiguration -Path C:\JeaDemo -ComputerName localhost -Verbose ` -wait -debug -ErrorAction SilentlyContinue -ErrorVariable errors
if($errors | ? FullyQualifiedErrorId -ne 'HRESULT 0x803381fa')
{
 $errors | Write-Error 
}

start-sleep -Seconds 30 #Wait for WINRM to restart

$s = New-PSSession -cn . -ConfigurationName Demo2EP
Invoke-command $s {get-command} |out-string
# Enter-pssession $s

Remove-PSSession $s
#EOF
 	   

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

Наш следующий снимок экрана отображает вывод для команды Get-PSSessionConfiguration.

Мы можем подключиться ко своей второй конечной точке при помощи такой команды:

Enter-PSSession –ComputerName localhost –ConfigurationName demo2ep
		

После подключения Get-Command перечислит все доступные в этой конечной точке команды:

Как и ожидалось, она допускает для нас запуск исключительно разрешённых cmdlet. В данной проверке мы воспользуемся cmdlet Get-SMBshare, который разрешён и Restart-Computer, который запрещён:

Demo3.ps1 предоставляет свою конечную точку для управления файловой системой и навигации по ней:

cls configuration Demo3
{
  Import-DscResource -module xjea
  xJeaToolKit FileSystem
  {
    Name = 'FileSystem'
    CommandSpecs = @" Module,name,Parameter,ValidateSet,ValidatePattern,
      Get-ChildItem,Get-Item,Copy-Item,Move-Item,Rename-Item,
      Remove-Item,Copy-ItemProperty,Clear-ItemProperty,Move-ItemProperty,
      New-ItemProperty,Remove-ItemProperty,Rename-ItemProperty,Set-ItemProperty,
      Get-Location,Pop-Location,Push-Location,Set-Location,Convert-Path,
      Join-Path,Resolve-Path,Split-Path,Test-Path,Get-PSDrive,New-PSDrive,
      out-file "@
    Ensure = 'Present' 
  }
 
  xJeaEndPoint Demo3EP
  {
     Name = 'Demo3EP'
     ToolKit = 'FileSystem'
     Ensure = 'Present'
     DependsOn = '[xJeaToolKit]FileSystem'
  }
}

Demo3 -OutputPath C:\JeaDemo

Start-DscConfiguration -Path C:JeaDemo -ComputerName localhost -Verbose ` -wait -debug -ErrorAction SilentlyContinue -ErrorVariable errors
if($errors | ? FullyQualifiedErrorId -ne 'HRESULT 0x803381fa')
{
 $errors | Write-Error 
}

start-sleep -Seconds 30 #Wait for WINRM to restart
# This endpoint allows you to navigate the filesystem but not see 
# the CONTENTS of any of the files
$s = New-PSSession -cn . -ConfigurationName Demo3EP
Invoke-command $s {dir 'C:\Program Files\Jea\Activity\ActivityLog.csv'} 
Invoke-Command $s {get-content ` 'C:Program FilesJeaActivityActivityLog.csv'}
# Enter-pssession $s

Remove-PSSession $s
#EOF
 	   

Настройки его конечной точки позволяют нам применять такие cmdlet:

Это объясняет как мы можем применять конечные точки JEA для ограничения полномочий конкретного использования на определённые задачи. Данный сценарий может использоваться для сборки вашей собственной конфигурации. Имеется множество примеров, которые вы можете отыскать в GitHub. Вы можете выполнить доступ к странице GitHub JEA через https:/​/​github.​com/​PowerShell/​JEA.

До сих пор в этой главе мы изучали то как мы можем применять модуль Powershell Active Directory для управления неким окружением Active Directory. Однако когда дело доходит до некой гибридной среды, мы не можем воспользоваться тем же самым модулем и для управления AD Azure. Для управления объектами Azure AD (исключительно облачными и синхронизированными) нам придётся применять модуль PowerShell Azure Active Directory. В своём следующем разделе этой главы мы намерены исследовать модуль PowerShell Azure Active Directory и его возможности.

Аналогично локальному Active Directory, мы можем также применять PowerShell и в Azure Active Directory. Давайте рассмотрим зачем нам следует применять PowerShell для управления Azure Active Directory:

В этой главе для управления Azure AD я буду применять Azure Active Directory PowerShell for Graph.

Необходимый нам модуль Azure Active Directory PowerShell for Graph поставляется в двух версиях. Имеющаяся в общем доступе версия предварительного просмотра является наиболее распространённой, но не рекомендуется для промышленного применения. Основные шаги для установки данной версии можно отыскать в https://www.powershellgallery.com/packages/AzureADPreview.

Общедоступная версия является стабильной, рекомендуемой для промышленных сред. Её можно установить на любой компьютер, запущенный под Windows Server 2008 R2 или выше с самыми последними обновлениями. Также необходим Microsoft .NET Framework 4.5 или выше.

После выполнения всех предварительных требований, осуществите такие шаги:

Теперь у нас имеется установленный модуль Azure Active Directory PowerShell for Graph. Давайте рассмотрим как мы можем при помощи этого модуля управлять гибридной средой Azure AD.

Мы можем начать с перечисления всех доступных в нашем модуле Azure AD команд, что можно сделать таким образом:

Get-Command -module AzureAD
		

При помощи команды Get-Help мы можем просматривать полный синтаксис команд. Например, пр помощи следующей команды мы способны увидеть полный синтаксис для команды Get-AzureADUser:

Get-Help Get-AzureADUser
		

Воспользовавшись своей следующей командой мы способны проверить состояние доменов Azure AD:

Get-AzureADDomain | fl
		

Наша предыдущая команда помогает идентифицировать состояние проверки нашего домена по ссылке на значение атрибута IsVerified.

Когда вы применяете в Azure AD некий индивидуально настроенный домен, нам требуется проверить владельца этого домена с применением записей DNS. Если эта проверка не прошла, мы можем выполнить выборку необходимых записей DNS, воспользовавшись такой командой:

Get-AzureADDomainVerificationDnsRecord -Name M365x562652.onmicrosoft.com | fl
		

В нашем предыдущем примере, M365x562652.onmicrosoft.com представляет имя нашего домена:

Мы можем просмотреть подробности аренды Azure AD применив следующее:

Get-AzureADTenantDetail | fl
		

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

Get-AzureADTenantDetail | select CompanyLastDirSyncTime
		

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

Get-AzureADUser -ObjectId AdeleV@M365x562652.OnMicrosoft.com | fl
		

А нашей предыдущей команде AdeleV@M365x562652.OnMicrosoft.com представляет собой значение UPN для указанного пользователя.

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

Get-AzureADUser -Filter "startswith(GivenName,'Adele')"
		

Наша предыдущая команда отфильтрует пользователей Azure AD по GivenName при помощи Adele.

Мы также можем фильтровать пользователей на основании значения некого особого атрибута:

Get-AzureADUser -Filter "GivenName eq 'Adele'"
		

Эта предыдущая команда найдёт всех пользователей в точности имеющих именем значение Adele.

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

Get-AzureADUser -All $true -Filter 'accountEnabled eq false'
		

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

Get-AzureADUser -All $true -Filter 'accountEnabled eq false' | select DisplayName,UserPrincipalName,Department
		

Наша приводимая выше команда отобразит значения атрибутов DisplayName, UserPrincipalName и Department для отфильтрованных учётных записей.

В некой гибридной среде мы можем фильтровать синхронизированные с локальным AD учётные записи воспользовавшись следующим:

Get-AzureADUser -All $true -Filter 'DirSyncEnabled eq true'
		

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

Мы также можем проверить значение самой последней синхронизации для своих синхронизируемых учётных записей:

Get-AzureADUser  -All $true -Filter 'DirSyncEnabled eq true' | select DisplayName,UserPrincipalName,LastDirSyncTime
		

В нашей предыдущей команде значение LastDirSyncTime определяет время самой последней синхронизации указанного объекта.

Также мы обладаем возможностью экспорта получаемого вывода в некий CSV при помощи имеющейся команды Export-CSV:

Get-AzureADUser  -All $true -Filter 'DirSyncEnabled eq true' | select DisplayName,UserPrincipalName,LastDirSyncTime | Export-CSV -Path .\syncaccount.csv
		

Указываемое значение ImmutableID некой учётной записи пользователя применяется для установления соответствия объекта пользователя Azure AD с объектом пользователя на локальной площадке. ImmutableID не обладает никакой связью с ObjectGUID учётной записи пользователя на локальной площадке. Мы можем применять его лишь для идентификации только пользователей в облаке. Когда этот пользователь присутствует только в облаке, значением ImmutableID должно быть null:

Get-AzureADUser -All $true | where-Object {$_.ImmutableId -eq $null}
		

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

Get-AzureADUser -All $true | where-Object {$_.ImmutableId -eq $null} | select DisplayName,UserPrincipalName | Export-CSV -Path .\cloudaccount.csv
		

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

Для просмотра связанных с некой учётной записью лицензий мы можем применить такую команду:

Get-AzureADUserLicenseDetail -ObjectId MeganB@M365x562652.OnMicrosoft.com | fl
		

Наша приведённая выше команда возвратит те лицензии, которые привязаны к нашему пользователю MeganB@M365x562652.OnMicrosoft.com.

Мы также можем просмотреть SKU своих подписок при помощи следующей команды:

Get-AzureADSubscribedSku | fl
		

Приведённая выше команда перечислит все сведения относительно лицензий, связанных с данной арендой. Но по большей части, нам требуется лишь знать сколько лицензий применяется и сколько лицензий доступно. Мы можем выполнить это при помощи такой команды:

Get-AzureADSubscribedSku | select SkuPartNumber,ConsumedUnits -ExpandProperty PrepaidUnits
		

В приводимом примере значение SkuPartNumber представляет код компонента имеющейся лицензии. Получаемое значение разрешённого поля представляет собой общее число приобретённых лицензий. ConsumedUnits предоставляет общее число задействованных лицензий.

Давайте проследуем далее и рассмотрим как мы можем назначать какую- то новую лицензию некому пользователю.

В моей среде имеются два пользователя Azure AD, синхронизированных с локальной площадкой, которые не обладают назначенными им лицензиями:

Get-AzureADUserLicenseDetail -ObjectId ADJellison@M365x562652.onmicrosoft.com | fl
		

Приводимый ниже снимок экрана отображает вывод нашей предыдущей команды:

В качестве некого первичного этапа, давайте создадим объекты для их применения в процессе выделения соответствующей лицензии:

$newlicence = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$newlicenceadd = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
		

Далее нам требуется отыскать значение SkuId для рассматриваемой лицензии.

Я намерен выделить такому пользователю имеющуюся лицензию ENTERPRISEPREMIUM:

$newlicenceadd.AddLicenses = $newlicence
		

После этого нам требуется назначить полученные лицензии соответствующему объекту:

$newlicence.SkuId = (Get-AzureADSubscribedSku | Where-Object -Property SkuPartNumber -Value "ENTERPRISEPREMIUM" -EQ).SkuId
		

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

Set-AzureADUserLicense -ObjectId "ADJellison@M365x562652.onmicrosoft.com" -AssignedLicenses $newlicenceadd
		

Наша предыдущая команда выделяет лицензии ENTERPRISEPREMIUM нашему пользователю ADJellison@M365x562652.onmicrosoft.com:

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

$licenseB = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$licenseB.RemoveLicenses =  (Get-AzureADSubscribedSku | Where-Object {$_.SkuPartNumber -eq 'ENTERPRISEPREMIUM'}).SkuId
Set-AzureADUserLicense -ObjectId "ADJellison@M365x562652.onmicrosoft.com" -AssignedLicenses $licenseB
		

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

#######Script to Assign Licences to Synced Users from On-Permises AD#############
Import-Module AzureAD
Connect-AzureAD
###Filter Synced Users who doesn't have licence assigned#######
$ADusers = Get-AzureADUser -All $true -Filter 'DirSyncEnabled eq true'
$notlicenced = Get-AzureADUser -All $true | Where-Object {$ADusers.AssignedLicenses -ne $null} | select ObjectId | Out-File -FilePath C:\users.txt
#####Set UsageLocation value to sync users#########
(Get-Content "C:\users.txt" | select-object -skip 3) | ForEach { Set-AzureADUser -ObjectId $_ -UsageLocation "US" }
#####Set User Licecnes############
$newlicence = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$newlicenceadd = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$newlicence.SkuId = (Get-
AzureADSubscribedSku | Where-Object -Property SkuPartNumber -Value "ENTERPRISEPREMIUM" -EQ).SkuId
$newlicenceadd.AddLicenses = $newlicence
(Get-Content "C:\users.txt" | select-object -skip 3) | ForEach { Set-AzureADUserLicense -ObjectId $_ -AssignedLicenses $newlicenceadd }
 	   

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

Воспользовавшись следующей командой, мы можем создать некого нового пользователя:

$Userpassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$Userpassword.Password = "London@1234"
New-AzureADUser -DisplayName "Andrew Xavier" -PasswordProfile $Userpassword -UserPrincipalName "Andrew.Xavier@M365x562652.onmicrosoft.com" -AccountEnabled $true -MailNickName "AndrewXavier"
		

В приводимой выше команде -PasswordProfile используется для определения значения пароля профиля для соответствующей учётной записи нового пользователя. -MailNickName определяет краткое имя в электронной почте данного пользователя. В нашем предыдущем примере добавлена учётная запись нового пользователя, Andrew.Xavier@M365x562652.onmicrosoft.com со значением пароля London@1234.

Применяя файлы CSV мы можем создавать множество учётных записей пользователей. В своём следующем примере для создания пользователей я пользуюсь неким файлом CSV. Это файл CSV содержит:

vfs.zfs.vdev.cache.size=<10M>UserPrincipalName, DisplayName,MailNickName
DishanM@M365x562652.onmicrosoft.com, Dishan Melroy,DishanMel
JackM@M365x562652.onmicrosoft.com,Jack May,JackMay
RicahrdP@M365x562652.onmicrosoft.com,Richard Parker,RichardPar
 	   

Затем применяя приводимое ниже я могу создать этих новых пользователей::

$Userpassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$Userpassword.Password = "London@1234"
Import-Csv -Path C:\newuser.csv | foreach {New-AzureADUser -UserPrincipalName $_.UserPrincipalName -DisplayName $_.DisplayName -MailNickName $_.MailNickName -PasswordProfile $Userpassword -AccountEnabled $true}
		

При помощи приведённых выше команд я создал сценарий для выполнения следующего:

########A Script to create new users and assign Azure AD licences#######
Import-Module AzureAD
Connect-AzureAD
###########Create New Users using CSV ###################
$Userpassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$Userpassword.Password = "London@1234"
Import-Csv -Path C:\newuser.csv | foreach {New-AzureADUser -UserPrincipalName $_.UserPrincipalName -DisplayName $_.DisplayName -MailNickName $_.MailNickName -PasswordProfile $Userpassword -UsageLocation "US" -AccountEnabled $true} | select ObjectId | Out-File -FilePath C:\users.txt
###########Assign Licences#################
$newlicence = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
$newlicenceadd = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
$newlicence.SkuId = (Get-AzureADSubscribedSku | Where-Object -Property SkuPartNumber -Value "ENTERPRISEPREMIUM" -EQ).SkuId
$newlicenceadd.AddLicenses = $newlicence
(Get-Content "C:\users.txt" | select-object -skip 3) | ForEach { Set-AzureADUserLicense -ObjectId $_ -AssignedLicenses $newlicenceadd }
 	   

Для удаления некого пользователя Azure AD мы можем воспользоваться следующим:

Remove-AzureADUser -ObjectId "JDAllen@M365x562652.onmicrosoft.com"
		

Воспользовавшись приводимой далее командой мы можем объединить это с поиском пользователя:

Get-AzureADUser -Filter "startswith(DisplayName,'Dishan')" | Remove-AzureADUser
		

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

Группы Azure AD также работают схожим с локальными для AD группами образом. Их можно применять для управления полномочиями действенным способом. В некой гибридной среде будут иметься группы, применяемые только в облаке, а также группы, синхронизируемые с окружением AD локальной площадки. В этом разделе мы намерены рассмотреть управление группой при помощи модуля Azure Active Directory PowerShell for Graph.

Давайте начнём с перечисления групп. Мы можем найти некую группу воспользовавшись такой командой:

Get-AzureADGroup -SearchString "sg"
		

В приводимой выше команде SearchString используется для задания критерия поиска. Наш предыдущий пример перечислит все группы, содержащие sg в поле DisplayName:

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

Get-AzureADGroup -ObjectId 93291438-be19-472e-a1d6-9b178b7ac619 | fl
		

В некой гибридной среде будут иметься группы безопасности, которые были синхронизированы с Active Directory локальной площадки. Применяя следующее, мы способны отфильтровать такие группы:

Get-AzureADGroup -Filter 'DirSyncEnabled eq true' | select ObjectId,DisplayName,LastDirSyncTime
		

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

При помощи приводимой ниже команды мы можем отфильтровать группы, имеющиеся только в облаке:

Get-AzureADGroup -All $true | where-Object {$_.OnPremisesSecurityIdentifier -eq $null}
		

В приведённой команде для фильтрации таких групп мы воспользовались значением атрибута OnPremisesSecurityIdentifier. Этот атрибут обладает значением если он синхронизирован с AD локальной площадки.

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

Get-AzureADGroupMember -ObjectId 2a11d5ee-8383-44d1-9fbd-85cb4dcc2d5a
		

В своей предыдущей команде мы воспользовались ObjectId для уникальной идентификации интересующей нас группы.

При помощи cmdlet Add-AzureADGroupMember

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

Add-AzureADGroupMember -ObjectId 2a11d5ee-8383-44d1-9fbd-85cb4dcc2d5a -RefObjectId a6aeced9-909e-4684-8712-d0f242451338
		

В нашей приведённой выше команде значение ObjectId представляет рассматриваемую группу, а значение RefObjectId представляет добавляемого пользователя.

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

Remove-AzureADGroupMember -ObjectId 2a11d5ee-8383-44d1-9fbd-85cb4dcc2d5a -MemberId a6aeced9-909e-4684-8712-d0f242451338
		

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

Мы также можем сочетать cmdlet Add-AzureADGroupMember с cmdlet Get-AzureADUser для добавления в некую группу пачки пользователей.

В своём следующем сценарии я воспользовался cmdlet Get-AzureADUser для поиска пользователей в Marketing Department, а затем применил Add-AzureADGroupMember для добавления этих пользователей к Sales Group в качестве участников:

#######Script to Add Multiple users to Security Group#############
Import-Module AzureAD
Connect-AzureAD
##### Search for users in Marketing Department ##########
Get-AzureADUser -All $true -Filter "Department eq 'Marketing'" | select ObjectId | Out-File -FilePath C:\salesusers.txt
#####Add Users to Sales Group#########
(Get-Content "C:\salesusers.txt" | select-object -skip 3) | ForEach { Add-AzureADGroupMember -ObjectId f9f51d29-e093-4e57-ad79-2fc5ae3517db -RefObjectId $_ }
 	   

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

New-AzureADGroup -DisplayName "REBELADMIN Sales Team" -MailEnabled $false -MailNickName "salesteam" -SecurityEnabled $true
		

Приводимый ниже снимок экрана отображает получаемый в нашей предыдущей команде вывод:

Наша предыдущая команда создала некую группу безопасности с названием REBELADMIN Sales Team. Эта группа не является группой с включённым доступом через электронную почту.

при помощи своей следующей команды мы способны удалять группу Azure AD:

Remove-AzureADGroup -ObjectId 7592b555-343d-4f73-a6f1-2270d7cf014f
		

В приведённой выше команде значение ObjectId определяет удаляемую группу.

Помимо групп безопасности Azure AD также обладает предварительно заданными административными ролями, которые можно применять для назначения полномочий доступа к Azure AD и прочим облачным службам. Существует более 35 предварительно определённых административных ролей. Каждая из ролей обладает своим собственным набором полномочий. Дополнительные сведения об этих ролях можно найти на https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles.

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

Get-AzureADDirectoryRoleTemplate
		

По умолчанию включёнными являются лишь несколько административных ролей. Воспользовавшись приводимой ниже командой мы можем вывести список этих ролей:

Get-AzureADDirectoryRole
		

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

Enable-AzureADDirectoryRole -RoleTemplateId e6d1a23a-da11-4be4-9570-befc86d067a7
		

В нашей предыдущей команде значение RoleTemplateId представляет нужную нам административную роль.

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

Add-AzureADDirectoryRoleMember -ObjectId b63c1671-625a-4a80-8bae-6487423909ca -RefObjectId 581c7265-c8cc-493b-9686-771b2f10a77e
		

В приведённой команде значение ObjectId представляет необходимую административную роль. RefObjectId является значением идентификатора объекта соответствующего пользователя.

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

Get-AzureADDirectoryRoleMember -ObjectId 36b9ac02-9dfc-402a-8d44-ba2d8995dc06
		

В приводимой команде ObjectId представляет рассматриваемую нами административную роль.

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

Remove-AzureADDirectoryRoleMember -ObjectId 36b9ac02-9dfc-402a-8d44-ba2d8995dc06 -MemberId 165ebcb7-f07d-42d2-a52e-90f44e71e4a1
		

В предыдущей команде MemberId эквивалентен значению идентификатора объекта удаляемого пользователя.

Это обозначает окончание данного раздела. Имеется великое множество cmdlet которые всё ещё можно применять для управления Azure AD, но здесь я дал пояснения лишь для тех cmdlet, которые необходимы для повседневных операций.

PowerShell стал наиболее мощным языком сценариев для систем Windows. PowerShell является очень полезным для управления системами, но также может быть и невероятно мощным инструментом для управления инфраструктурами AD. На протяжении данной книги я применял PowerShell для настройки AD и управления им. Более того, я совместно применял различные команды и сценарии которые могут использоваться для действенного управления некой средой AD. Продвигаясь к окончанию данной главы вы изучили как реализовывать JEA и как его можно применять для защиты полномочий в неком окружении AD. Также мы изучили как управлять Azur AD с помощью имеющегося модуля Azure Active Directory PowerShell for Graph. В своей следующей главе мы рассмотрим Azure AD и изучим как управлять идентичностью в некой гибридной среде.