Ask Identigral (Issue 3)
by Deborah Volk on May 15th, 2009

Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.
We want to use Oracle Identity Manager (OIM) to manage Active Directory (AD) passwords. However, an error message is only displayed if changing the user's OIM password fails. No error message is displayed when a failure occurs when changing the user's Active Directory password.
When you change a password through the OIM web UI (aka "web client"), it calls the tcUserOperationsIntf updateUser API. This goes and fires all of the pre-update entity adapters and then performs a transaction that involves update of the USR table. From the web client's perspective, the transaction is complete if it has been successfully committed all the way to the database. Once it's committed,all the post-update entity adapters fire. Since you are using the Trigger processes to propagate the password change to Active Directory, the error message is outside the initial updateUser transaction. This is why the error message is not seen on the web client.

Typical of OIM, there area number of ways to solve the problem. I would put your update to AD inside the updateUser call by using a pre-update entity adapter. The best approach would be to take the AD Adapter that changes the user password (ADCS Set User Password adapter in the 9.1 version of the adapter) and re-create it as an entity adapter. (You probably want to keep the process task adapter around too). Once you have the entity adapter done,you need to do the following in order to have the error message show up on the web client:

1) Create an Error Message Definition for the failure to change AD.(Remember the code has to start with ADAPTER. So the code of the EMD should be something like ADAPTER.ADPasswordNotChanged). Make the Action be Fatal Rejection. This will roll-back the transaction and will not write the new password to the USR table.

2) Put a check in your new entity adapter for the appropriate response and add a Logic task to handle the error. Pick your error code if the Java task returns the appropriate code.

3) Take out the Change User Password task in the AD workflow. You can do this in two ways: Remove the task name from the lookup (as long as AD is your only resource), or rename the task in the process to something that does not look like "Change User Password"

4) Also, since we don't want to write to AD for every change to the user profile (Xellerate User object), there should be a check at the beginning to make sure that the password has in fact changed.

Here is a screenshot of what this looks like after it's been implemented in web client:
If you take this approach, you will have to make sure your adapter gets updated if the ADSC Set User Password adapter gets updated by Oracle in the next rev of the AD connector. However, this will typically not happen too much, unless they are trying to support different Active Directory versions. The other downside of this approach is that the process form for the Active Directory resource does not get updated. If there is a reason for the process form to get updated, instead of having the entity adapter go to AD directly, you could write some Java code to update the process form using the tcFormInstanceOperationsIntf API.
Have a Question?

Send your questions to and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc.

Posted in Oracle Identity Manager, Ask Identigral    Tagged with active directory, passwords


Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)