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
http://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, 3
rd
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
