Я хочу запустить Set-ACL
на объекте AD DS1 с участием "Администраторы домена" установлен как владелец в моем созданном объекте ACL. Код выглядит примерно так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)"
}
Но вызов Set-ACL возвращает эту ошибку, когда код выполняется на DC Server 2008 R2 (Powershell v5):
Set-ACL : This security ID may not be assigned as the owner of this object
или более общее исключение «Доступ запрещен» при использовании того же участника безопасности для его запуска со станции управления Server 2012 R2 (Powershell v4):
Set-ACL : Access is denied
Я даже не изменение владелец в данном конкретном случае, но очевидно, что Set-ACL просто переписывает весь дескриптор безопасности.
«Изменить разрешения» и "Изменить владельца" были явно установлены для целевого объекта, и я вполне могу изменить владельца этого самого объекта с помощью графического интерфейса gpmc.msc на все, что захочу, как на DC, так и на управляющей станции, так что это не очевидная проблема с разрешениями. С другой стороны, я также вижу, что код работает, как только он запускается пользователем, который является членом Администраторы домена группа.
У учетной записи, которую я использую, намеренно отсутствует членство в «Администраторах домена» (вместо этого она является членом группы «BUILTIN \ Server Admins»), но она должна иметь возможность свободно устанавливать владельца объекта. Я вижу что Статья MSDN, посвященная этому сообщению об ошибке предлагает "узнайте, каких пользователей и группы вы можете назначить владельцем", что в моем случае бесполезно.
Так что я делаю не так?
1 в моем случае это GPO, но тип объекта не имеет большого значения, я также видел, как это происходит, например, с OU.
2 В Set-Acl -AclObject $targetAcl -Path "AD:\$($targetObject.DistinguishedName)"
вызов выглядит как взлом, и это действительно так. Я не могу просто пройти -InputObject $targetObject
к Set-ACL
так как InputObject
ожидает объектный тип, реализующий SetSecurityDescriptor
метод, который [Microsoft.ActiveDirectory.Management.ADObject] не выполняет по какой-то загадочной причине.
Поскольку я решил, что наблюдаемый мной эффект может быть специфическим для реализации Set-ACL, я попытался получить вместо этого класс [System.DirectoryServices.ActiveDirectorySecurity] и использовать его метод .SetOwner:
$adsiTarget = [adsi]"LDAP://$($targetObject.DistinguishedName)"
$idRef = New-Object System.Security.Principal.NTAccount("CONTOSO", "Domain Admins")
$adsiTarget.PSBase.ObjectSecurity.SetOwner($idRef)
$adsiTarget.PSBase.CommitChanges()
В моих первоначальных тестах, запускающих код на DC, я был поражен тем фактом, что он работал, если я хотел установить владельца себе (принять владение), но снова не смог установить владельца в Администраторы домена:
Exception calling "CommitChanges" with "0" argument(s): "A constraint violation occurred.
К счастью для меня, я наткнулся на ответ на вопрос "Set-ACL fails" здесь на SF, который связан как «Связанный». В этом ответе упоминаются ограничения привилегий для конкретных токенов.1 в качестве возможной причины проблемы, поэтому я продолжил тестировать тот же подход на станции управления, где ограничения токена локально-интерактивного контроллера домена не применялись. Это сработало - теперь я могу устанавливать владельцев объектов DS в Powershell по своему вкусу (если я не пытаюсь сделать это на DC).
Еще одна ветка на форумах TechNet предоставляет решение на основе классов .NET для добавления этой привилегии к текущему токену процесса без необходимости использования командлетов сторонних производителей, таких как PSCX, но я еще не нашел способа заставить его работать в моем конкретном случае.
1 соответствующая привилегия здесь, вероятно, будет SeRestorePrivilege - по умолчанию он отключен для токенов процесса интерактивного входа.
Это также означает, что учетной записи, которой необходимо изменить владельца объекта AD DS, потребуется назначить эту привилегию либо через членство в группе в группах BUILTIN по умолчанию, таких как операторы сервера и операторы резервного копирования на контроллерах домена, либо через изменение назначения политики контроллеров домена по умолчанию. права пользователя «Восстановить файлы и каталоги».