☰

In die Datei „Get-ACL“ für AD-Computerobjekt exportieren und später mit „Set-ACL“ importieren

tag-icon • tag-icon active-directory powershell exchange
In die Datei „Get-ACL“ für AD-Computerobjekt exportieren und später mit „Set-ACL“ importieren

Ich könnte etwas Hilfe gebrauchen. Mein Active Directory ist 20 Jahre alt, es wird bald legal Alkohol kaufen und Gott weiß, wie es dann weitergeht ...

Spaß beiseite, Exchange hat meine AD DACLs verwüstet. Bis zu dem Punkt, dass Exchange nicht einmal mehr richtig funktioniert. Ich habe ein Labor mit einer identischen AD-Struktur, aber neu auf 2022-OS/2019-EX-CU12, aufgebaut, nur damit ich sehen kann, wie die richtigen Berechtigungen aussehen.

GROSSARTIG! Ich sehe alle fehlenden DACLS, die ich für den ordnungsgemäßen Betrieb benötige, noch einmal. Das Problem? Haben Sie schon einmal versucht, Advanced Native Permission Tooling für komplizierte Dinge wie Exchange-Sachen zu verwenden? Es hängt sich einfach auf, Gott weiß, ob ich es überhaupt richtig mache, pfui...

Was ich lieber tun würde, ist Folgendes auf der sauberen Seite:

$acl = get-acl -path "AD:DC=prod,DC=widgets,DC=corp"
$acl.Access | ? {$_.IdentityReference -like "*Exchange*" -or $_.IdentityReference -like "*Organization*"} | export-CliXml -Path c:\temp\ftw.xml

Entfernen Sie dann die Zeilendatensätze aus der Textdatei, die ich nicht importieren muss. Für die Datensätze, die ich importieren muss, würde ich den Domänennamen in der XML-Datei so ändern, dass er mit der Produktionsseite übereinstimmt:

$CleanACLs = Import-Clixml C:\temp\ftw.xml
$TestVictom = "AD:CN=Poor User,OU=Employees,DC=prod,DC=myCompany,DC=corp"
$acl = get-acl -path $TestVictom
#Testing just one ACL
$NewACE = ($CleanACLs)[0]
$acl.AddAccessRule($newACE)
Set-Acl -Path $TestVictom -AclObject $acl

Allerdings wurden meine Träume durch diesen Fehler in der Zeile „$acl.AddAccessRule($newACE)“ zerstört:

MethodException: Argument „rule“ mit Wert: „System.DirectoryServices.ActiveDirectoryAccessRule“ für „AddAccessRule“ kann nicht in Typ „System.DirectoryServices.ActiveDirectoryAccessRule“ konvertiert werden: „Der Wert „System.DirectoryServices.ActiveDirectoryAccessRule“ vom Typ „Deserialized.System.DirectoryServices.ActiveDirectoryAccessRule“ kann nicht in Typ „System.DirectoryServices.ActiveDirectoryAccessRule“ konvertiert werden.“

Es scheint etwas so Dummes zu sein wie die Tatsache, dass import-clixml ALLE Objekte ändert, um die deserialisierten hinzuzufügen. das Problem ist. Ich bin ziemlich sicher, dass die Objekte ansonsten identisch sind. Ironischerweise habe ich clixml verwendet, um den Objekttyp beizubehalten.

Kennt jemand einen Zaubertrick, mit dem man diesen Objekten das Präfix „deserialisiert“ entziehen kann?

Ansonsten: Kennt jemand eine vernünftige Methode, um ein AD-Objekt DACL in eine editierbare Textdatei zu exportieren, mit der man es wieder importieren kann? Das Einzige, was ich in der Textdatei tun muss, ist, nicht benötigte Zeilen zu entfernen (die ich technisch auf der Quellseite filtern kann) und den Domänennamen der IdentityReference zu ändern.

Prost!

Antwort1

Sie können das Cmdlet Get-Acl in PowerShell verwenden, um die DACL eines AD-Objekts abzurufen. Hier ist ein Beispielbefehl, der die DACL eines AD-Objekts in eine CSV-Datei exportiert:

Get-Acl -Path "AD:\CN=ObjectDN,DC=DomainName,DC=com" | Select-Object -ExpandProperty Access | Export-Csv -Path "C:\Pfad\Zur\Datei.csv" -NoTypeInformation

Um die bearbeitete DACL erneut zu importieren, können Sie das Cmdlet Set-Acl in PowerShell verwenden. Hier ist ein Beispielbefehl, der die DACL eines AD-Objekts aus einer CSV-Datei festlegt:

Set-Acl -Path "AD:\CN=ObjectDN,DC=DomainName,DC=com" -AclObject (Import-Csv -Path "C:\Pfad\Zur\Datei.csv" | ForEach-Object {New-Object System.Security.AccessControl.FileSystemAccessRule($.Identitätsreferenz,$.FileSystemRights,$.InheritanceFlags,$.PropagationFlags,$_.AccessControlType)})

Antwort2

Sie können es nicht beheben, nativ also. Das Problem ist, dass ein Objekt serialisiert wird, wenn es auf der Festplatte gespeichert wird (beim Importieren/Exportieren). Wenn Sie es dann von der Festplatte zurücklesen, wird es deserialisiert. Obwohl die Objekte aus Ihrer Sicht identisch sind (d. h. dieselben Eigenschaften usw.), ist das neue Objekt, wie Sie gesehen haben, vom gleichen Typ, wurde aber am Ende deserialisiert. Aus diesem Grund sind es technisch gesehen unterschiedliche Objekte.

Ich hatte das gleiche Problem eine Weile mit völlig anderen Befehlen und habe mir selbst eine Frage gestellt. Ich habe mit jemandem zusammengearbeitet, um es herauszufinden und mehr zu verstehen. Schauen Sie mal reinHier. Für Sie besteht die einzige Lösung jedoch darin, das Objekt manuell neu zu erstellen :-( Oder es nicht auf der Festplatte zu speichern.

EDIT: Wenn Sie noch ein bisschen darüber nachdenken, sollten Sie dies erreichen können, indem Sie alles in einem Prozess erledigen. Anstatt zuerst den DCAL zu exportieren (wir können nicht sehen, wie Sie das gemacht haben, aber Sie können Powershell verwenden), führen Sie einfach diese Codezeilen aus und speichern Sie das DACL-Objekt in einer Variablen und NICHT in einer Datei. Dadurch bleibt es in seinem ursprünglichen Format und Sie können es erfolgreich weitergeben.

verwandte Informationen