ADAM/AD LDS import fails with error 0×20e7

April 13, 2009 · Filed Under Active Directory | 630 views

We’ve got an ADAM instance setup that provide proxy authentication for an application. In one partition of the ADAM instance are the userProxy objects and in another partition objects exist specific to the application that contain security and role information, thus determining what permissions each user has in that application. I use a scheduled VBScript to synchronize the contents of the “ADUSERS” partition with those of the application container. The application support personnel use the built-in vendor provided security management tools to manage the data in the “application” partition, including adding new user entries. My VBScript just created the required userProxy objects when needed in the “ADUSERS” partition…without a corresponding entry in both partitions, i.e. without the userProxy object, there can be no proxy authentication for the user to that application. Simple, standard ADAM usage.

Anyhow, I had been alerted by the applications teams that a certain user that was provisioned within the application security tools hadn’t had a userProxy object created accordingly. Upon further investigation, I found that the scheduled synchronization process, which relies on an ADAM LDIFDE import to create the new userProxy objects had been failing for several days. Running the scripted LDIFDE import command manually, so I could see the exact error, yielded the following output:

C:\WINDOWS\ADAM>ldifde -b <account, domain and password> -s <server> -t <port> -i -k -f <import.ldif file>
Connecting to “<server>”
Logging in as “<user>” in domain “<domain>” using SSPI
Importing directory from file “<import.ldif file>”
Loading entries..
Add error on line 7: Unwilling To Perform
The server side error is: 0×20e7 The modification was not permitted for security reasons.
The extended server error is:
000020E7: SvcErr: DSID-03152AA9, problem 5003 (WILL_NOT_PERFORM), data 8471

0 entries modified successfully.
An error has occurred in the program

When looking at the import file, there were no issues noted…nothing out of the normal.

dn: CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectclass: container
objectclass: top
cn: adusers

dn: cn=someuser,CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectSID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx
objectclass: userProxy
cn: someuser

The key part of that error is actually the data field, 8471. A check of that error code on the System Error Codes (Windows) site of MSDN reveals the following information:

ERROR_DS_NAME_ERROR_NOT_UNIQUE
8471 (0×2117)

Name translation: Input name mapped to more than one output name.

So, a duplicate SID exists (the SID is the unique identifier and I’d already verified that this specific CN did not exist in the “ADUSERS” partition of the ADAM instance. Now knowing that this userProxy cannot be created due to a duplicate SID problem, things are getting clearer…but how to determine what existing userProxy object has that SID? And how did another userProxy object get the same SID?

First things first, to determine what existing userProxy object has that SID already, an export of the ADAM “ADUSERS” partition is required. Use a command similar to the following to get it:

C:\WINDOWS\ADAM>ldifde -s <server> -t <port> -d CN=adusers,CN=application,
CN=adam,DC=company,DC=local -f e:\output.ldif

Now that you have the ldif file, the next step is to find the Base64 value of the SID for the user account in question. The easiest way is to look up the objectSID value in ADSIEDIT, targeted at Active Directory (not the ADAM instance) and get the Hexadecimal value of the objectSID attribute for the user account in question. Then convert that Hex value into Base64 using your favorite converter. A really nice one can be found here at TRANSLATOR, BINARY. Simply copy the Hex value into the Hex input box and click Decode. Your Base64 value appears below. Copy this Base64 value and use it to search the exported ldif file. You’ll find the userProxy object with the duplicated SID in no time.

In my case, the problem tracked back to a name change on the user object, changing the first name. The userProxy object had previously been created for the user account before the name change (and with the same SID obviously), but the application administrators had not deleted the old (incorrect) userProxy object manually as they needed to. Thus when the LDIFDE import process tried to create a new userProxy object for the newly renamed user account, the import process failed. Once the incorrect userProxy object was deleted, the import process was able to complete again successfully.