Que direitos “Replicing Directory Changes” realmente concedem no Active Directory?

Question

Precisamos conceder a ID de serviço Replicating Directory Changes no Active Directory. As pessoas estão preocupadas que possamos acidentalmente deixar a ID do serviço gravar dados no Active Directory, ou fazer com que alguém abuse do ID do serviço e alterar os dados do Active Directory.

Alguém sabe quais direitos fazem parte de "Replicando alterações no diretório?"

    

Answer 1

link

Note Using either method, setting the Replicating Directory Changes permission for each domain within your forest enables the discovery of objects in the domain within the Active Directory forest. However, enabling discovery of the connected directory does not imply that other operations can be performed.

To create, modify, and delete objects within Active Directory using a non-administrative account, you may need to add additional permissions as appropriate. For example, for Microsoft Metadirectory Services (MMS) to create new user objects in an Organizational Unit (OU) or container, the account that is being used must be explicitly granted the Create All Child Objects permission, as the Replicating Directory Changes permission is not sufficient to allow the creation of objects.

In a similar fashion, the deletion of objects requires the Delete All Child Objects permission.

It is possible that there are limitations on other operations, such as attribute flow, depending on the specific security settings that are assigned to the object in question, and whether or not inheritance is a factor.

    

Answer 2

A resposta existente não satisfez minha curiosidade e eu não queria que as pessoas conseguissem mais do que precisavam no meu diretório. Então eu fiz um pouco mais de escavação.

Informações principais aqui:

link

Repartição:

Se você quiser sincronizar o banco de dados do seu programa com o AD (como o sharepoint / FIM), você tem duas maneiras de perguntar ao AD o que mudou desde sua última consulta.

Você pode usar o controle "DirSync" (extensão do protocolo LDAP) OR , você pode ficar meio ghetto e apenas usar o comando uSNChanged - mas existem limitações nele.

"Uma pesquisa de controle DirSync retorna todas as alterações feitas em um objeto do Active Directory, independentemente das permissões definidas no objeto." Ele até retornará objetos tombstoned.

Portanto, para usar o controle LDAP do DirSync, você precisa de "Replicando alterações de diretório" ou ser um administrador de domínio.

Pelo que consegui reunir, a única coisa assustadora é que eles podem praticamente ler qualquer coisa na partição de diretório, independentemente das permissões padrão. Eles não podem alterar nada.

No entanto - você pode ter alguns atributos que são senstivite em seu diretório.

Mais sobre a extensão de controle DirSync aqui:

link

True Test: Conectando-se ao AD usando o controle DirSync

E aqui está o verdadeiro caminho para você descobrir por si mesmo. Esse cara é o cara. Se você quiser ver por si mesmo - adapte este exemplo do PowerShell, execute-o como o usuário ao qual você concedeu o direito e consulte um objeto de usuário (ou qualquer outra coisa).

link

Eu verifiquei com a nossa conta do Sharepoint para ver o que eu poderia receber de volta. Antes de conceder a permissão, recebi uma exceção de acesso negado ao tentar usar o controle DirSync.

Depois disso, recebi quase tudo em uma conta de usuário:

Atributos notáveis relacionados à segurança que retornaram em uma consulta de usuário que eu tenho certeza que você normalmente não consegue ver sem permissões elevadas:

• userAccountControl
• userparameters
• msexchuseraccountcontrol
• pwdlastset
• unicodePwd (BLANK. Portanto, nenhum domínio hash pw é retornado)
• tempo de bloqueio
• accountexpires
• unixuserpassword (YIKES. Se você estiver usando isto - ele IS visível mas com hash. Faça algumas leituras aqui se você estiver paranóico ou use serviços para unix password sync.)

Também verifiquei uma conta de computador que tinha uma senha de recuperação de bitlocker anexada a ela e esse atributo não estava disponível nos resultados retornados.

Se você já teve o Services for Unix em seu ambiente e pws sincronizados - você pode ter dados de sobra aqui. Um dos nossos usuários que estavam por aí há muito tempo tinha isso definido em sua conta. É possível que quebrar esse pw possa levar a uma senha do dia atual apenas experimentando variações nele.

Isso foi removido do nosso ambiente, por isso os usuários mais novos não tinham dados aqui.

    

Answer 3

Na verdade, a permissão "Replicating Directory Changes" não concede direitos DCPROMO nem é possível usar essa permissão para recuperar os valores com hash da senha do usuário.

Para obter acesso aos hashes de senha do usuário, é necessário conceder "Replicate Directory Changes All ". Para obter mais informações, consulte link

    

Answer 4

Para delegar o serviço para replicar no Active Directory, é necessário ativar o envio como e receber como delegação .

    

Answer 5

O maior risco de abuso (IMO) é que ele pode ser usado para representar um DCPROMO. Parece ser possível usar essa permissão para recuperar os valores da senha com hash, o que está a um passo de todos os tipos de ataques.

Há um bom exemplo que demonstra o uso indevido da permissão Replicating Directory Changes em dsinternals.com:

link

    

Answer 6

Caso seja útil para alguém, eu reescrevi o script referenciado para consultar um domínio separado, diferente daquele em que a máquina atual está:

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 
}