How to Back Up Active Directory Objects Using LDIFDE
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 (https://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:
dn: OU=exptest,DC=GONDOR,DC=Local
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: exptest
distinguishedName: OU=exptest,DC=GONDOR,DC=Local
instanceType: 4
whenCreated: 20120108121610.0Z
whenChanged: 20120108121610.0Z
uSNCreated: 7883573
uSNChanged: 7883573
name: exptest
objectGUID:: L5X4DYfjZ0+qEni6sUXfNA==
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=GONDOR,DC=Local
dSCorePropagationData: 16010101000000.0Z
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"
Loading entries.
Add error on entry starting on line 1: Unwilling To Perform
The server side error is: 0x20e7 The modification was not permitted for security
reasons.
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"
Loading entries...
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:
dn: OU=exptest,DC=GONDOR,DC=Local
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: exptest
distinguishedName: OU=exptest,DC=GONDOR,DC=Local
instanceType: 4
whenCreated: 20120108124230.0Z
whenChanged: 20120108124230.0Z
uSNCreated: 7883664
uSNChanged: 7883664
name: exptest
objectGUID:: UvMzoOqTc0mX1fLEcD75BQ==
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=GONDOR,DC=Local
dSCorePropagationData: 16010101000000.0Z
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.
Comments
Anonymous
July 29, 2014
Very useful. Many thanks.Anonymous
November 06, 2014
Excellent Article.. Thank you.Anonymous
December 17, 2014
Thanks DC Baker. "The command below performs an export of the same OU but we exclude the system-owned objects (uSNCreated,uSNChanged,objectguid,whencreated,whenchanged):" did you mean explude from the syntax or exclude form the exported export-partial.ldf file ?. Look for those entries in the exported lfd file are missing whencreated,whenchanged etc etc. We need the right syntax for the export to get rid of the system type data.Anonymous
February 19, 2015
We need to keep the system attributes the same. What do you recommend?Anonymous
March 05, 2015
RE: "Missing Syntax" I'm not sure I understand your question. The purpose of the revised command is to exclude the system owned attributes so that the objects in the LDIF file could be imported successfully.Anonymous
March 05, 2015
@Brian, I'm not sure what you mean by keep them the same. You can perform an export and dump all attributes. I'm not aware of any way to import an LDF file and create system owned attributes. If you need a way to backup and restore objects and preserve the system owned attributes you need to use normal Active Directory backup/restores methods.Anonymous
August 09, 2015
that is one of the best Active directory articles i have read ever :) thanks a lot