Início / server / Perguntas / 831330
Accepted
the-wabbit
Asked: 2017-02-09 05:24:18 +0800 CST

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

  • 772

Desejo executar um Set-ACLem um objeto AD DS 1 com "Administradores de domínio" definidos como o proprietário em meu objeto ACL construído. O código se parece basicamente com este 2 :

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 este erro quando o código é executado em um Server 2008 R2 DC (Powershell v5):

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

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

Set-ACL : Access is denied

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

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

A conta que estou usando não possui deliberadamente a associação "Administradores do domínio" (em vez disso, é um membro do grupo "BUILTIN\Administradores do servidor"), mas precisa ser capaz de definir livremente o proprietário do objeto. Vejo que o artigo do MSDN que cobre esta mensagem de erro está sugerindo "saber quais usuários e grupos 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?

1 um GPO no meu caso, mas o tipo de objeto não importa tanto, também já vi isso acontecendo para OUs, por exemplo.

2 A Set-Acl -AclObject $targetAcl -Path "AD:\$($targetObject.DistinguishedName)"chamada parece um hack e realmente é. Não posso simplesmente passar como esperado -InputObject $targetObjectpara um tipo de objeto que implementa o método, o que [Microsoft.ActiveDirectory.Management.ADObject] não está fazendo por algum motivo misterioso.Set-ACLInputObjectSetSecurityDescriptor

powershell active-directory access-control-list

1 respostas

  1. Best Answer

    Como percebi que o efeito que estou vendo pode ser específico da implementação para 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()

    Em meus testes iniciais executando o código em um controlador de domínio, fiquei impressionado com o fato de que funcionou se eu desejasse definir o proprietário para mim mesmo (assumir a propriedade), mas novamente não consegui definir o proprietário como Admins. do domínio :

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

    Felizmente para mim, encontrei uma resposta para a pergunta "Set-ACL failed" aqui no SF, que está vinculada como "Related". Esta resposta está mencionando restrições de privilégio específicas de token 1 como a possível causa do problema, então testei a mesma abordagem na estação de gerenciamento, onde as restrições de token DC interativo local não se aplicariam. Funcionou - agora posso definir os proprietários dos objetos do DS no Powershell ao meu gosto (desde que não esteja tentando fazê-lo em um DC).

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

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

    O que também significa que uma conta que precisa alterar a propriedade em um objeto AD DS precisaria obter esse privilégio atribuído por meio de 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 na atribuição de política de controladores de domínio padrão do direito de usuário "Restaurar arquivos e diretórios".

    • 0

relate perguntas