Using LDIFDE to Perform Post-Migration Clean-up Tasks

  • Article

Hi, Rusty here to discuss a recent problem that we resolved using the export and import features of Ldifde.exe.

During the usability testing phase of an inter-forest migration to a new forest of the same name, our customer discovered that smart card users in the new forest could not logon. They were receiving “Access Denied” after entering their PINs.

Prior to calling us, the customer discovered his own fix. He found that exporting the migrated user's AD Certificate to a file and then re-importing it back via the Security Identity Mapping GUI corrected the issue. Unfortunately, he had 12,000 accounts to manage - that’s when he called us.

ADMT has no problem migrating the “userCertificate” attribute, attributeCertificateAttribute. The Data Protection API prevents ADMT from migrating the altSecurityIdentities attribute which contains the X.509 mapping information. No X.509 mapping info = Smart Card Access Denied.

We needed to automate the collection and population of the altSecurityIdentities attribute for 12,000+ users. Using the:

Step-by-Step Guide to Bulk Import and Export to Active Directory
https://technet.microsoft.com/en-us/library/bb727091.aspx

as a reference, we came up with an ldifde.exe export which specifically called out the “list of attributes” switch. This allows us to export only the attribute data we need to correct the problem. By using the lower case –l option and specifying only the altSecurityIdentities attribute, we’ll return the user’s distinguished name and the attribute we want in the export file:

Ldifde –d “DC=fabrikam,DC=Com” –r “(objectCategory=user)” –p Subtree –l altSecurityIdentities –f oldDomainUsers.ldf

    • -d sets search scope – in this case, fabrikam.com
    • -r sets an ldap search filter, use an indexed object when you can
    • -p details how deep in the directory to search, subtree searches all of the specified scope, fabrikam.com
    • -l sets the list of attributes to return from the search, in this case the altSecurityIdentities attribute of each user
    • -f sets the filename we export the data to

We then massaged the export file to remove users that were not smartcard enabled (altSecurityIndentities attribute not populated) to create an LDIFDE import file for the target domain:

dn: CN=CraigsUsername,CN=Users,DC=fabrikam,DC=Com
changetype: modify
replace: altSecurityIdentities
altSecurityIdentities:
X509:<I>C=XX,O=XX. XXXXX,OU=XXX,OU=PKI,CN=Certificate CLASS 3 CA-5<S>C=XX,O=XX
XX,OU=XXX,OU=PKI,OU=User'sOU,CN=Username.Craig.SomeNumericValue
-
dn: CN=NedsUsername,CN=Users,DC=fabrikam,DC=com
changetype: modify
replace: altSecurityIdentities
altSecurityIdentities:
X509:<I>C=XX,O=XX. XXXXX,OU=XXX,OU=PKI,CN=Certificate CLASS 3 CA-5<S>C=XX,O=XX
XX,OU=XXX,OU=PKI,OU=User'sOU,CN=Username.Ned.SomeNumericValue
-

It is important to note that the "-" is a separator between changetype: modify operations. It must be there for each attribute to be modified.

Notes: Migration to a new forest of the same name is made possible by using a temporary, 3rd forest in-between the old and new. To learn more about certificate mapping, read Designing a Public Key Infrastructure in the Windows Server 2003 Deployment Guide. ADMT 3.1 documentation indicates that there is no guarantee all user attributes, data, and certificates will migrate successfully.

Hopefully this gives you some insight into more advanced usages of ldifde.exe. Keep in mind that csvde.exe delivers the same functionality with the advanced data manipulation features of MS Excel.

- Russell “Spaniard” Despain