Powershell: o proprietário da configuração para objetos do AD DS falha

Question

Eu quero executar um Set-ACL em um objeto do AD DS ¹ com "Administradores do domínio" definido como o proprietário em meu objeto ACL construído. O código parece basicamente assim ² :

Function SetDSAcl {
       Param (
        [Microsoft.ActiveDirectory.Management.ADObject]$targetObject   # target object
    )

    $targetACL = Get-Acl "AD:\$($targetObject.DistinguishedName)"
    # [some voodoo to get the values for my new ACE]
    # Create a new AccessRule using the object constructor
    # $newAce = New-Object System.DirectoryServices.ActiveDirectoryAccessRule([...])

    # Add the generated ACE to target's ACL
    $targetAcl.AddAccessRule($newAce)

    # Persist the changed ACL to the object
    Set-ACL -AclObject $targetAcl "AD:\$($targetObject.DistinguishedName)"
}

Mas a chamada Set-ACL retorna esse erro quando o código é executado em um DC do Server 2008 R2 (Powershell v5):

Set-ACL : This security ID may not be assigned as the owner of this object

ou uma exceção "Acesso negado" mais genérico ao usar a mesma entidade de segurança para executá-lo a partir de uma estação de gerenciamento do Server 2012 R2 (Powershell v4):

Set-ACL : Access is denied

Eu nem estou alterando o proprietário neste caso em particular, mas aparentemente o Set-ACL simplesmente está reescrevendo todo o descritor de segurança.

"Modificar permissões" e "Modificar proprietário" foram explicitamente definidas no objeto de destino e posso perfeitamente alterar o proprietário deste mesmo objeto usando o gpmc .msc GUI para qualquer coisa que eu quero no DC e na estação de gerenciamento, então não é um problema óbvio de permissão. Por outro lado, também vejo que o código está funcionando assim que é executado por um usuário que é membro do grupo Domain Admins .

A conta que estou usando está deliberadamente sem a associação "Domain Admins" (é um membro do grupo "BUILTIN \ Server Admins"), mas precisa definir livremente o proprietário do objeto. Vejo que o artigo do MSDN sobre essa mensagem de erro está sugerindo a "saber quais usuários e grupos que você tem o direito de atribuir como proprietário ", o que não é útil no meu caso.

Então, o que estou fazendo de errado?

¹ um GPO no meu caso, mas o tipo de objeto não importa tanto, eu também vi isso acontecer para UOs, por exemplo.

² A chamada Set-Acl -AclObject $targetAcl -Path "AD:\$($targetObject.DistinguishedName)" parece um hack e de fato é. Eu não posso apenas passar -InputObject $targetObject para Set-ACL as InputObject espera um tipo de objeto implementando o método SetSecurityDescriptor , que [Microsoft.ActiveDirectory.Management.ADObject] não está fazendo por algum motivo misterioso.

    

Answer 1

Como percebi que o efeito que estou vendo pode ser específico da implementação do Set-ACL, tentei buscar a classe [System.DirectoryServices.ActiveDirectorySecurity] e usar seu método .SetOwner:

$adsiTarget = [adsi]"LDAP://$($targetObject.DistinguishedName)"
$idRef = New-Object System.Security.Principal.NTAccount("CONTOSO", "Domain Admins")
$adsiTarget.PSBase.ObjectSecurity.SetOwner($idRef)
$adsiTarget.PSBase.CommitChanges()

Nos meus testes iniciais executando o código em um controlador de domínio, fui acionado pelo fato de que funcionava se eu quisesse definir o proprietário para mim (assumir a propriedade), mas falhava novamente em definir o proprietário como Admins. do domínio :

Exception calling "CommitChanges" with "0" argument(s): "A constraint violation occurred.

Para minha sorte, deparei-me com uma resposta à pergunta "Set-ACL failed" aqui no SF que está vinculado como "Relacionado". Essa resposta está mencionando as restrições de privilégio específicas do token ¹ como a possível causa do problema, então testei a mesma abordagem na estação de gerenciamento, onde restrições de token CC interativas locais não se aplicariam. Funcionou - eu sou capaz de definir os proprietários de objetos DS no Powershell para o meu gosto agora (contanto que eu não esteja tentando fazer isso em um CD).

Outro tópico nos fóruns do TechNet está fornecendo uma solução baseada em classe .NET para adicionar esse privilégio ao processo atual token sem a necessidade de cmdlets de terceiros como o PSCX, mas ainda não encontrei uma maneira de fazê-lo funcionar no meu caso particular.

¹ o privilégio relevante aqui provavelmente é SeRestorePrivilege - está desabilitado por tokens de processo de logon interativo por padrão.

Isso também significa que uma conta que precise alterar a propriedade de um objeto do AD DS precisaria obter esse privilégio por meio da associação de grupo nos grupos BUILTIN padrão, como Operadores de Servidor e Operadores de Backup em DCs ou por meio de uma alteração no Domínio Padrão. Atribuição de diretiva de controladores do direito de usuário "Restaurar arquivos e diretórios".