Export to file Get-ACL for AD Computer Object then import later using Set-ACL

I could use some help. My Active Directory is 20 year old, its about to start buying legal alcohol and god knows where it's going from there...

All joking aside, Exchange has ravaged my AD DACLs. To the point Exchange isn't even working right. I built a lab with an identical AD structure but fresh on 2022-OS/2019-EX-CU12 just so I can see what the correct permissions look like.

GREAT! I see all the missing DACLS I need for proper operation once more. The problem? Have you ever tried to use Advanced Native Permission tooling for squirly stuff like Exchange stuff? It just locks up, god knows if I am even doing it right, ugh...

What I would rather do is this on the clean side:

$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

Then remove row records from the text file I don't need to import, for those I do I would modify the domain name in the xml file to match the production side:

$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

However, my dreams were busted by this error on the "$acl.AddAccessRule($newACE)" line:

MethodException: Cannot convert argument "rule", with value: "System.DirectoryServices.ActiveDirectoryAccessRule", for "AddAccessRule" to type "System.DirectoryServices.ActiveDirectoryAccessRule": "Cannot convert the "System.DirectoryServices.ActiveDirectoryAccessRule" value of type "Deserialized.System.DirectoryServices.ActiveDirectoryAccessRule" to type "System.DirectoryServices.ActiveDirectoryAccessRule"."

It seems something as silly as the fact the import-clixml changing ALL of the objects to add the deserialized. is the issue. I am fairly sure the objects are identical otherwise. Ironically, I was using clixml to preserve object type.

Anyone got any magic to get these objects to not have the prefix of deserialized?

Otherwise, anyone have a decent way to export an AD object DACL to an editable text file, with a way to re-import? The only thing I need to do in the text file is remove unneeded rows (which I can technically filter on the source side) as well change the domain name of the IdentityReference).

Cheers!

You can use the Get-Acl cmdlet in PowerShell to retrieve the DACL of an AD object. Here’s an example command that exports the DACL of an AD object to a CSV file:

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

To re-import the edited DACL, you can use the Set-Acl cmdlet in PowerShell. Here’s an example command that sets the DACL of an AD object from a CSV file:

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

You can't fix it, natively that is. The issue is that when an object is saved to disk (on your import/export) it gets serialised. When you then read that back from disk, it gets deserialised. Although the objects are identical from your perspective (as in same properties etc), as you will have seen, the new object is of same type but has deserialised on the end. Because of this they are technically different objects.

I had the same issue a while with completely different commands, and raised a question on myself actually. I worked with someone to figure it out and To understand moreTake a look here. But for you, the only fix is to rebuild the object manually :-( Or don't save it to disk.

EDIT: After thinking a bit more, you should be able to achieve this by doing it all in one process. Instead of exporting the DCAL first (we cannot see how you got this, but you can use powershell), just run those lines of code and save the DACL object to a variable and NOT a file. This will keep it in it's original format, and you will be ablel to pass it through succesfully.