web-dev-qa-db-ja.com

Powershell：ADの所有者の設定DSオブジェクトが失敗する

ADで_Set-ACL_を実行したいDSオブジェクト1 "Domain Admins"を、作成した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)"
}
_

ただし、コードがServer 2008 R2で実行されると、Set-ACL呼び出しはこのエラーを返しますDC（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 GUIを使用して、DCと管理ステーションの両方で必要なものにこのオブジェクトを追加するので、明らかな権限の問題ではありません。一方、それもわかります。コードは、Domain Adminsグループのメンバーであるユーザーによって実行されるとすぐに機能します。

私が使用しているアカウントには、意図的に "Domain Admins"メンバーシップ（代わりに "BUILTIN\Server Admins"グループのメンバー）がありませんが、オブジェクトの所有者を自由に設定できる必要があります。 このエラーメッセージをカバーするMSDNの記事 が「所有者として割り当てる権利があるユーザーとグループを学習する」を示唆していることがわかります。私の場合は役に立ちません。

だから私は何が間違っているのですか？

1 a GPOですが、オブジェクトのタイプはそれほど重要ではありません。たとえば、OUで発生することもあります。

2Set-Acl -AclObject $targetAcl -Path "AD:\$($targetObject.DistinguishedName)"呼び出しはハックのように見えますが、実際にはハックです。 _-InputObject $targetObject_を_Set-ACL_に単に渡すことはできません。InputObjectは、[Microsoft.ActiveDirectory.Management.ADObject]が実行していないSetSecurityDescriptorメソッドを実装するオブジェクトタイプを想定しているためです。いくつかの不思議な理由。

active-directorypowershellaccess-control-list
4
the-wabbit

私が見ている効果は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-ACLfails」の質問に対する答えに出くわしました ここで「関連」としてリンクされているSFについて。この回答は、トークン固有の特権制限について言及しています1 問題の考えられる原因として、ローカルインタラクティブDCトークン制限が適用されない管理ステーションで同じアプローチをテストしました。それは機能しました-設定できますDS Powershell内のオブジェクトの所有者は、今のところ私の好みに合っています（DCでそうしようとしない限り）。

TechNetフォーラムの別のスレッド は、PSCXのようなサードパーティのコマンドレットを必要とせずに現在のプロセストークンにこの特権を追加するための.NETクラスベースのソリューションを提供していますが、私はまだその方法を見つけていません私の特定のケースでそれを機能させます。

1 ここで関連する特権はおそらく SeRestorePrivilege -対話型ログオンプロセストークンではデフォルトで無効になっています。

これは、AD DSオブジェクトの所有権を変更する必要があるアカウントは、DC上のサーバーオペレーターやバックアップオペレーターなどのデフォルトのBUILTINグループのグループメンバーシップを通じて、または「ファイルとディレクトリの復元」ユーザー権限のデフォルトドメインコントローラーポリシー割り当ての変更。

0
the-wabbit