There are times when you need to modify or delete objects in Active Directory (AD) in order to perform some level of cleanup. In a perfect world, you would always have a good backup and the restore would work flawlessly. Just in case, I always export the objects I’m about to delete or modify so I can quickly perform a rollback of the change in case problems arise. The following is an example of a recent case.
I helped one of my customers perform a manual cleanup of some obsolete PKI objects in AD. At some point in the past there had been a Certificate Server that had become obsolete and was turned off. Unfortunately the Certificate services were never uninstalled leaving a number of orphaned objects in AD. We needed to deploy a new PKI infrastructure so the old objects had to be removed before we could install the new systems. The original server was no longer available so to perform the cleanup we had to manually delete a number of PKI related objects from the directory. To add one more layer of complexity we had to make sure we did not break Smart Card Logon, a feature that relies on some of the existing PKI objects, by removing the wrong PKI objects accidentally. The cleanup process is documented in a Microsoft KB article (http://support.microsoft.com/kb/555151) but I like to have a “B” plan just in case things do not go as expected.
The LDIFDE utility can be used to export and import Active Directory objects. By default when you export AD objects all attributes of the object are exported. The problem with a default export is if you try to import the file, the import will fail. The following command will export an Organizational Unit (OU) named EXPTEST:
ldifde -d “OU=exptest,DC=gondor,DC=local” -p subtree -f export-full.ldf
Here is an excerpt from the LDF file:
If we try to import the file to restore the objects we will get an error:
ldifde -i -f export-full.ldf
Connecting to “DC1.GONDOR.Local”
Logging in as current user using SSPI
Importing directory from file “export-full.ldf”
Add error on entry starting on line 1: Unwilling To Perform
The server side error is: 0x20e7 The modification was not permitted for security
The extended server error is:
000020E7: SvcErr: DSID-03152EE8, problem 5003 (WILL_NOT_PERFORM), data 0
The error is caused by trying to import data values that are owned and controlled by the system. Values like “whenCreated” and “objectGUID” are system generated values that cannot be imported. To get around the problem you need to only export the values needed to create the objects. The command below performs an export of the same OU but we exclude the system-owned objects (uSNCreated,uSNChanged,objectguid,whencreated,whenchanged):
ldifde -d “OU=exptest,DC=gondor,DC=local” -p subtree -o “uSNCreated,uSNChanged,objectguid,whencreated,whenchanged” -f export-partial.ldf
Now if we import the export-partial.ldf file created in the step above we will successfully create the deleted objects:
ldifde -i -k -f export-partial.ldf
Connecting to “VDC01.GONDOR.Local”
Logging in as current user using SSPI
Importing directory from file “export-partial.ldf”
2 entries modified successfully.
The command has completed successfully
Now if we export the objects recreated by importing our backup file you will notice the system attributes discussed above have changed values:
Always make sure you have a good backup of Active Directory before making changes. You can also use LDIF exports and imports to move objects from one directory to another (e.g. production to lab) by creating an export file, doing a search and replace on domain DistinguishedName and importing. As always TEST, TEST, TEST in a lab environment before attempting any of this on the production Active Directory.