I’m currently on a client site that was experiencing a rather strange issue with the Active Directory connector for Oracle Identity Manager. They had just created a new UAT environment, and copied all the data from Development into UAT for both OIM and AD, assuming that all the links between the two systems would still be intact.

Then we started testing…

We would find a user in OIM that was already provisioned into Active Directory and try to change their password. Every time, it would fail. The error in the Web Admin was this:

AD.USER_DOES_NOT_EXIST

Seems pretty straight forward. Except that the user does exist. We doubled checked the IT Resource to make sure the hostname, login credentials and everything else was correct. We also made sure that the admin account we were using had the proper permissions. In the OIM WebSphere logs, we saw this:

[18 Sep 2009 11:52:02 ERROR] [WebContainer : 6] OIMCP.ADCS – Does not exist

Ok, so this matches up with the error in the Web Console, so it seems we’re still struggling with the fact that AD thinks the user we’re requesting doesn’t exist… arg!

Next test: Create a user in OIM, provision them to AD, and then check the domain to see if they’re there. Result? Success! The new user is right next to all the other users that AD says doesn’t exist. And when we try to change the password for the new user, it works without a hitch. Dang it!

Ok, by this point I was getting pretty frustrated, and I turned to the Oracle Forums, and even started decompiling the AD Connector classes to see exactly what was going on. I read one comment in the forums that I agreed with and ran with: “I never trust my logs, but I always trust my sniffer”.

Next test: Turn off SSL for the AD Connector and then run the Change Password request for an existing user and see what’s sent across the wire. Here’s the command I issued in case you would like to do the same (10.0.0.1 being the AD server):

# tcpdump -x -s 0 host 10.0.0.1

Low an behold, I see this:

11:15:00.826547 IP test.ad.edu.48961 > 10.0.0.1.ldap: P 52:161(109) ack 23 win 1460 <nop,nop,timestamp 1253190463 74116905>
0×0000:  4500 00a1 310b 4000 4006 f437 ac10 ceba  E…1.@.@..7….
0×0010:  0a01 9048 bf41 0185 c3d5 1a6d 5663 89aa  …H.A…..mVc..
0×0020:  8018 05b4 15a8 0000 0101 080a 4ab2 2b3f  …………J.+?
0×0030:  046a ef29 306b 0201 0263 4904 1664 633d  .j.)0k…cI..dc=
0×0040:  0254 6e45 6669 354t 742c 6542 1245 6573  ad,dc=edu
0×0050:  7461 640a 0102 0a01 0302 0100 0201 0001  ……………..
0×0060:  0100 a31e 040a 6f62 6a65 6374 4755 4944  ……objectGUID
0×0070:  0410 65f5 c2c3 4515 ca4f a092 0b6c d324  ..e…E..O…l.$
0×0080:  d0ea 3000 a01b 3019 0417 322e 3136 2e38  ..0…0…2.16.8
0×0090:  3430 2e31 2e31 3133 3733 302e 332e 342e  40.1.113730.3.4.
0x00a0:  32

Bingo! It wasn’t trying to find users based on the user’s samAccountName or their DN (which I assumed). It was looking up users by their objectGUID. And here is where my problem lay. The user information from OIM was imported directly to the database from the Development environment, which means that all the users in OIM have objectGUID values that match to the Development AD environment. When they imported all the users into AD, they used an AD migration tool, which assigned new objectGUID’s to all the users as they were being imported. This is why OIM couldn’t “find” the users… all the objectGUID’s were completely out of sync. Fix? Not sure yet. Still working on that part. This has turned out to be a much more complicated process than I imagined, because we cannot just do an LDIF export / import with the objectGUIDs. AD will just ignore the values and create it’s own. When I figure out a fix for this, I will let you know.

Piece,

.: Adam

Depending on your configuration (both software and hardware), you may wind up with an issue with the AD Connector when running a Non-Trusted reconciliation and receiving a “No Match Found” error. This tends to be due to the use of parallel processing. To fix this, I would suggest you use 2 Scheduled Tasks for AD reconciliations using the same schedule class:

Class Name: com.thortech.xl.schedule.tasks.ActiveDirectoryReconTask

Use a separate IT Resource for each of them to maintain their respective Last Modified Time Stamp values (this is the key to the whole solution).

For Example, a Trusted Recon against “Xellerate User” Resource Object:

1) Create a Scheduled Task called “ActiveDirectory_TrustedReconTask” using class com.thortech.xl.schedule.tasks.ActiveDirectoryReconTask and having the same Task Attributes and values as in the original out of the box schedule task.
2) Create a new IT Resource called “AD Server IT Res_Trusted”. Provide the same values for the IT Resource Parameters that you have been using previously.
3) In the Task Attributes of schedule task created in Step 1, change the value of Task attribute “Server” to “AD Server IT Res_Trusted”.
4) Also set Task Attribute “Object” to “Xellerate User” and “XellerateObject” to “false”

Similarly for a Non-Trusted Recon against “AD User” Resource Object

1) Create a Scheduled Task called “ActiveDirectory_NonTrustedReconTask” using class com.thortech.xl.schedule.tasks.ActiveDirectoryReconTask and having the same Task Attributes and values as in the original out of the box schedule task.
2) Create a new IT Resource called “AD Server IT Res_NonTrusted”. Provide the same values for the IT Resource Parameters that you have been using previously.
3) In the Task Attributes of schedule task created in Step 1, change the value of Task attribute “Server” to “AD Server IT Res_NonTrusted”.
4) Also set Task Attribute “Object” to “AD User” and “XellerateObject” to “false”

Run the Trusted Recon first and then run the Non-Trusted Recon task. These scheduled tasks will update their respective IT Resources with separate Last Modified Time Stamps.

.: Adam