Назад | Перейти на главную страницу

Какие права фактически предоставляет «Репликация изменений каталога» в Active Directory?

Нам нужно предоставить идентификатор службы для репликации изменений каталога в Active Directory. Люди обеспокоены тем, что мы можем случайно позволить идентификатору службы записывать данные в Active Directory или что кто-то может злоупотребить идентификатором службы и изменить данные Active Directory.

Кто-нибудь знает, какие права являются частью «Репликации изменений каталога»?

active-directory permissions

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

Основная информация здесь:

http://support.microsoft.com/kb/891995

Сломать:

Если вы хотите синхронизировать базу данных вашей программы с AD (например, sharepoint / FIM), у вас есть два способа спросить AD, что изменилось с момента вашего последнего запроса.

Вы можете использовать элемент управления "DirSync" (расширение протокола LDAP) ИЛИ вы можете пойти в гетто и просто использовать опрос uSNChanged - но там есть ограничения.

«Поиск элемента управления DirSync возвращает все изменения, внесенные в объект Active Directory, независимо от разрешений, установленных для объекта». Он даже вернет объекты с надгробиями.

Итак, чтобы использовать элемент управления DirSync LDAP, вам потребуется «Репликация изменений каталога» или быть администратором домена.

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

Однако - у вас могут быть некоторые важные атрибуты в вашем каталоге.

Подробнее о расширении управления DirSync здесь:

https://msdn.microsoft.com/en-us/library/ms677626(v=vs.85).aspx

True Test: подключение к AD с помощью элемента управления DirSync

И вот верный способ узнать это для себя. Этот парень и есть мужчина. Если вы хотите убедиться в этом сами - адаптируйте этот пример PowerShell, запустите его от имени пользователя, которому вы предоставили права, и запросите объект пользователя (или что-то еще).

http://dloder.blogspot.com/2012/01/powershell-dirsync-sample.html

Я проверил нашу учетную запись Sharepoint, чтобы узнать, что я могу получить обратно. Прежде чем я предоставил разрешение, я получил исключение отказа в доступе при попытке использовать элемент управления DirSync.

Как только я это сделал, я получил обратно почти все в учетной записи пользователя:

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

userAccountControl
параметры пользователя
msexchuseraccountcontrol
pwdlastset
unicodePwd (ПУСТО. Таким образом, pw хешированного домена не возвращается)
время блокировки
счет
unixuserpassword (ДА. Если вы используете это - это ЯВЛЯЕТСЯ виден, но хеширован. Прочтите здесь, если вы параноик или используете службы для синхронизации паролей unix.)

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

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

Это было удалено из нашей среды, поэтому у новых пользователей здесь не было никаких данных.

http://support.microsoft.com/kb/303972

Примечание. При использовании любого из методов установка разрешения «Репликация изменений каталога» для каждого домена в лесу позволяет обнаруживать объекты в домене в лесу Active Directory. Однако включение обнаружения подключенного каталога не означает, что могут выполняться другие операции.

Чтобы создавать, изменять и удалять объекты в Active Directory с использованием неадминистративной учетной записи, вам может потребоваться добавить дополнительные разрешения, если это необходимо. Например, чтобы службы метакаталога Microsoft (MMS) создавали новые объекты пользователей в организационной единице (OU) или контейнере, используемой учетной записи необходимо явно предоставить разрешение на создание всех дочерних объектов, поскольку разрешение на репликацию изменений каталога не разрешено. достаточно, чтобы позволить создание объектов.

Аналогичным образом для удаления объектов требуется разрешение «Удалить все дочерние объекты».

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

На самом деле разрешение «Репликация изменений каталога» не дает ни права DCPROMO, ни возможности использовать это разрешение для получения хешированных значений пароля пользователя.

Чтобы получить доступ к хэшам паролей пользователей, необходимо предоставить «Реплицировать изменения каталога. Все". Для получения дополнительной информации см. https://social.technet.microsoft.com/Forums/windowsserver/en-US/cc72be66-30c4-420e-8de3-9085858037bc/difference-between-replicating-directory-changes-replicating-d

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

Самый большой риск злоупотребления (ИМО) этим правом заключается в том, что его можно использовать для выдачи себя за DCPROMO. Представляется возможным использовать это разрешение для получения хешированных значений пароля, что находится всего в нескольких шагах от всех видов атак.

Вот действительно хороший пример, демонстрирующий неправильное использование разрешения Replicating Directory Changes на dsinternals.com:

https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/

Если это кому-то поможет, я переписал указанный скрипт, чтобы запросить отдельный домен, отличный от того, на котором находится текущая машина:

Add-Type -AssemblyName System.DirectoryServices.Protocols

#defaults
$RootDSE = [ADSI]"LDAP://RootDSE"
$dcHostName = $RootDSE.dnsHostName
$distinguishedName = $RootDSE.defaultNamingContext

#or use the lines below for another DC on another domain
$dcHostName = "dc1.contoso.local"
$distinguishedName = (Get-ADDomain "contoso.local").DistinguishedName

$LDAPConnection = New-Object System.DirectoryServices.Protocols.LDAPConnection($dcHostName) 
$Request = New-Object System.DirectoryServices.Protocols.SearchRequest($distinguishedName, "(objectclass=*)", "Subtree", $null) 
$DirSyncRC = New-Object System.DirectoryServices.Protocols.DirSyncRequestControl($Cookie, [System.DirectoryServices.Protocols.DirectorySynchronizationOptions]::IncrementalValues, [System.Int32]::MaxValue) 
$Request.Controls.Add($DirSyncRC) | Out-Null 

$MoreData = $true

while ($MoreData) {

    $Response = $LDAPConnection.SendRequest($Request)

    $Response.Entries | ForEach-Object { 
        write-host $_.distinguishedName 
    }

    ForEach ($Control in $Response.Controls) { 
        If ($Control.GetType().Name -eq "DirSyncResponseControl") { 
            $Cookie = $Control.Cookie 
            $MoreData = $Control.MoreData 
        } 
    } 
    $DirSyncRC.Cookie = $Cookie 
}