title: Taking a DIP: Oracle's answer to directory interoperability link: https://onemoretech.wordpress.com/2008/06/05/taking-a-dip-oracles-answer-to-directory-interoperability/ author: lembobro description: post_id: 514 created: 2008/06/05 19:15:44 created_gmt: 2008/06/05 19:15:44 comment_status: open post_name: taking-a-dip-oracles-answer-to-directory-interoperability status: publish post_type: post

Taking a DIP: Oracle's answer to directory interoperability

All this week I’ve been at an undisclosed location attending the Oracle Directory Services: Administration class.

The last 3 days have been working with the DIP, “Directory Integration Platform”, component of Oracle’s Identity Management Infrastructure that includes Oracle Internet Directory (OID) and Oracle SSO (OSSO). The class is based on 10g Release 3 (10.1.4.0.1) of the product.

Two days ago we got synchronization going between an Oracle database and OID, and yesterday did the same thing with OID and Microsoft’s Active Directory (AD). We also installed and configured a Windows authentication plugin for OID that basically redirects authentication requests to AD.

DIP is a pretty neat facility, but difficult to configure, debug and operate (maintain) mostly due to really poor documentation by Oracle. There are a set of standard connector profiles that come with OID out of the box, for Active Directory, iPlanet (Sun or Red Hat Directory), and (new to Release 3) OpenLDAP, as well as for LDIF, csv and a generic Oracle database. As with most things the devil is in the details, which in the case of DIP are the profile configuration and entry mapping files. Of course, earlier rumors heard some time ago had DIP being deprecated in future versions, but that has not been confirmed by anyone at Oracle.

Today we’re covering integration with Windows Native Authentication, among other things. After going through the noble history of the kerberos protocol, with a few snarky comments by yours truly on how it was mangled by Microsoft so that it won’t interoperate with “standard” kerberos keyservers out of the box, we dove right into how Oracle’s single sign-on infrastructure can be modified so that it will transparently authenticate an Internet Explorer user who is already authenticated to an Active Directory domain.

After that, we moved on to discussing how to deploy Oracle’s Windows password filter to allow synchronization of passwords between Active Directory and Oracle Internet Directory. Making password changes from OID to AD involves doing a userpassword update over LDAPS, which requires that AD be SSL-enabled. Going from AD to OID is a problem, because once a new password is committed to AD, it can’t be decrypted. Oracle’s solution is basically the same one everyone else uses (e.g. Sun, Novell, IBM). An agent riding up on the user’s local AD domain controller intercepts the new password before its committed to AD and sends that cleartext value over to the DIP so it can update userpassword on OID. In real life you’d need this agent on every domain controller because password changes are potentially services by any one of them (in my work environment we’re talking 100’s of domain controller machines).

Right now I’m waiting for my class AD domain controller to reboot after installing the agent. Since the system is remote from the training center I’m in, and the hardware is apparently somewhat dated, I’m told it’s going to take awhile.

P.S.: Now we’re moved into covering Advanced (ASR) database-based and LDAP based replication. Release 3 has beefed up the latter to the point that it makes you wonder whay anyone would use ASR. Rumor of the day is that ASR will not be available in 11g. Ha!

Copyright 2004-2019 Phil Lembo