Using Bi-directional Password Synchronization with Oracle Internet Directory
Novell Cool Solutions: Feature
By Uwe Krause
Digg This -
Posted: 18 Oct 2006
We know from the past that there are certain applications where we cannot synchronize password in a bi-directional manner. Oracle Internet Directory (OID) is one of these applications. OID has different passwords inside; they are synchronized within OID but normally not accessible from outside, because they are hashed or encrypted.
In one project, I had the requirement to synchronize the OID password into the Metadirectory (the reverse process was never a problem). Unfortunately this was a "no-go" criteria for the customer, so we had to investigate a while. Thanks to Michael Bluteau, who pointed me in the right direction, we found an interesting article from Oracle regarding their passwords.
"Beginning with Release 9.0.4, Oracle Internet Directory stores the user password in a reversible encrypted format in an operational attribute called orclrevpwd. This attribute is generated only if the attribute orclpwdencryptionenable in the password policy entry is set to TRUE. The orclrevpwd attribute can be queried only by using the SSL one-way and two-way authentication mechanisms. This attribute cannot be queried over non-SSL sessions."
(See more here:
So we had one starting point. After setting "orclpwdencryptionenable" to true, we needed to set the driver to SSL Authentication. The objective is to create Certificates in Oracle (called Wallet ... http://www.oracle.com/technology/products/oid/oidhtml/sec_idm_training/html_masters/view01.htm) and export them. The steps for doing this are described below.
Getting an SSL connection with OID, from IDM on Linux
First, you need to add Oracle and Novell certificates to java keystore (cacerts) in /java_home/jre/lib/security.
1. Go to a Terminal Window, then go to /java_home/jre/lib/security and type the following commands:
keytool -import -alias ssop1root -keystore cacerts -file ssop1_root.crt keytool -import -alias ssop1user -keystore cacerts -file ssop1_user.crt keytool -import -alias novell -keystore cacerts -file Kunovell.crt
It will prompt you for a password (you specified during the OID Creation process).
2. In OID Driver, specify the location as /java_home/jre/lib/security/cacerts
3. Set Mutual Authentication = No in Driver
The driver should now work in SSL mode. Some tricky parts are coming, because the original documents coming from OID will not contain the orclrevpwd. This has to be queried later.
The original document looks like this:
<nds dtdversion="2.0"> <source> <product build="20060630_1616 " instance="OID Secure1" version="1.9.2">Identity Manager Driver for LDAP</product> <contact>Novell, Inc.</contact> </source> <input> <modify class-name="inetOrgPerson" event-id="1" src- dn="cn=OIDUser,cn=users,dc=Test,dc=edu,dc=de"> <association state="associated"> cn=OIDUser,cn=users,dc=Test,dc=edu,dc=de </association> <modify-attr attr-name="authpassword^9^20061008081731z^ssop1_asdb"> <remove-all-values/> </modify-attr> </modify> <init-params event-id="chgLogNum"> <publisher-state> <change-log-number>816089</change-log-number> </publisher-state> </init-params> </input> </nds>
Note: You should check your trace to see the actual input document from OID, to verify the usage of authpassword. Some installations may send different attribute names.
As you can see, there is a cryptic attr-name containing authpassword, a timestamp and the database name. This statement will be filtered out, because we cannot put this in the filter (since the timestamp will be changing). And because this is the one and only attribute for the user, the whole modify part will be filtered out. For this reason, all password policies we have in the Command Transformation Policy Set will not work. To overcome this, I decided to insert a synthetic event: I added a new value to description to check for a modify of the authpassword stuff. But how would I do the test on the operation attribute, because this always changes? Thanks to Xpath we have a solution. I created the following Input Transformation Policy:
The change of Description will ensure that the Modify statement of this user is not completely filtered out. We keep a remaining fragment of modify and filter out only the authpassword stuff.
In the last step, we have to modify our existing password policies in the Command Transformation a bit. The original rules will consume the password Token to populate the nspmdistributionPassword field. The has to be changed, so that we can read the orclrevpwd from OID and use this.
Don't forget to set the global variable publish-password-to-dp to true and block all synchronization to the NDS password.
I would suggest stripping the operation attribute description as the last action in the Command Transformation. Just do a test to see if it contains "Password changed" and then strip it.
Thats it. Now we have a bi-directional password sync up and running for OID. If you have any questions you may contact me at firstname.lastname@example.org.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com