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

A lot of clients that install an Identity Management suite are looking for a major functionality with their reconciliation from their authoritative source(s)… Real-time data flow.

This has always been a hinderance on the OIM side of things because it relies so heavily on Scheduled Tasks to do all of it’s data processing and marshaling. I am currently working with a Higher Education client in the NYC area that expressed this concern and I’m happy to say that OIM has a solution. (Other Universities, please take note!)

Here’s a quick diagram of an example OIM Architecture using PeopleSoft and provisioning to a couple resources (RAC is being used here as OIM’s backend data repository).

PeopleSoft has a tool (configured through PeopleTools) called an Integration Broker. This can be configured to create an XML file that is pushed to the OIM system for immediate reconciliation. There are no scheduled tasks that need to be run, and it does not have to be performed as a batch process. You will need to have access to the PeopleTools, and have some knowledge of it, but the Oracle documentation is pretty detailed on getting this thing setup properly.

You can read the doc here: http://download.oracle.com/docs/cd/E11223_01/doc.904/e10437/custom.htm

On a bit of the technical side of this, you need to make sure that the Task Scheduler is running. If not, you’ll experience this: Users will be reconciled from PeopleSoft through the Integration Broker fine. You will see in the logs that the users were brought over and all the details are there. You’ll even see recon events in the Reconciliation Manager. The problem is that the users won’t actually be added into OIM (or provisioned to it’s resources obviously). If you’re experiencing this, you can check the status of the OIM Scheduler here:

http(s)://oimhost:port/xlScheduler/admin/

It’s a super basic page (that I didn’t even knew existed until a couple days ago lol!) that shows that status, a username / password box, and 2 buttons (Start/Stop and Reinit). You need to provide the OIM admin credentials (xelsysadm). You’re also not going to “login” to anything. Just pushing the buttons is all that happens.

I would love to hear your experiences with the Integration Broker if you have any!

Later!

.: Adam

One of the major, and commonly over-looked areas of identity management is that of complex multi-campus higher education implementations. There are some similarities to enterprise and government implementations, but there are some major differences. While most identity management solutions are put in place to conform to governance or lower help desk calls, multi-campus identity management implementations are focused around unifying the higher education institution and provide a single repository for all students, staff, and faculty. Multi-affiliation roles in them selves are something that is very unique to higher-ed Identity management projects. The various use-cases that are specific to universities are common among them all. For most companies working on a high-ed contract for the first time, will find this a very challenging and daunting task.  Another topic that is very familiar to these types of engagements are implementors have to work with a governance committee. These committees are comprised of representatives from each institution that have decision making capabilities and are recognized by the high-level corporate sponsor of the project in its entirety. A lot of the time, these committees are formed initially for these projects, so there is also a need to work with them and educate them on how and why these committees work. They are needed, but cause a great deal of delay in a project. Knowing how to work with these committees are necessary for creating a realistic project timeline and for managing expectations with the client on the increased time of deployment. 

One area also that needs to be focused on when working on a University Identity Management deployment is that of software choice. Most companies have a set standard for their software, especially when it comes to Operating Systems (OS’s). You’ll hear of a certain company being regarded as a “Blue company” if they are a big IBM investor. This will mean that you’re servers will most likely be AIX boxes. Others are Wintel (Windows / Intel), so look out for Windows 2003 Server / Active Directory. You’ll also see some Sun or HP companies as well. Higher Education on the other hand doesn’t necessary have the strong hardware tie to a specific vendor. More often than not, you will work with a lot of open-source systems. This means you will be installing on Linux boxes (Redhat’s a biggie), possibly work with OpenLDAP, and all kinds of other fun systems that need a ton of libraries and perl scripts to get to interact with your IdM architecture.

Licensing is another area that’s big with Higher Ed. Most universities get much greater discounts on software than corporations do. This means that when a university purchases an IdM product, they’ve most likely purchased the entire suite. Or rather, they bought Sun Identity Manager and then they just gave them the access control product, there federation tool, and a massive discount to run their SunONE LDAP.

Hopefully this will help some of you out that are starting out on your first higher education identity management deployment. Even if you’ve done them before, I’m sure you can find a little nugget of information that can be beneficial.

If you have any questions, please feel free to leave a comment, or send me an email.

Thanks!

.: Adam