The first part of this series on OID 11g focused on purchasing and licensing OID. Now we are ready to focus on what you is needed for a functional OID implementation. Before we get into the details, it is useful to explain what is OID and some of its components.
What is OID?
OID, a component of Fusion Middleware, is a general purpose LDAPv3 compliant directory store. Based on configuration it can scale, be highly available and secure. Most would initially use it for Directory Naming, as a central store for database connectivity details. This would alleviate clients from requiring a local TNSNAMES.ORA file (reduces management and improves efficiency), though instead they would typically require an LDAP.ORA file. This file stores the LDAP connection details, i.e. the OID hostname/IP, connection ports, and realm.
OID can also serve as the central repository for user identification and role information which again reduces management and improves efficiencies. You may think this sounds like Microsoft Active Directory (MSAD) and you would be right! They are both LDAP directories, however, Oracle does not speak with MSAD (or any other LDAP directory) out-of-box directly and this is where OID comes into play. There is also Oracle Virtual Directory (OVD) which acts as a virtual directory service, being a front-end to any LDAP directory and is a valid alternative if you don't have OID or you have multiple directory servers and are okay with extending the directories schema to support the Oracle meta-data. However, you may run into organization constraints extending your MSAD schema which in my case is what occured.
How does OID integrate with MSAD?
There are a few options when integrating OID to your existing LDAP directory store and in this post I'll focus on MSAD though the concepts are similar to other LDAP directory stores with only the details being different. Reviewing the options in the arcticle here (this is rather dated but seems still relevant and its not like Oracle has anything more recent) lead to me to several thoughts. Originally I thought to use the Directory Integration Platform (DIP) tool to synchronize passwords between MSAD and OID but that required installing the Active Directory Password Filter on each domain controller. This of course is simply not practical given the number of AD controllers and corporate policies and was immediately rejected by the Windows Admins. Another option I explored was Server Chaining but that would only work with one AD controller and required a plug-in for password change notification. Even with some creative workarounds such as using a round-robin or LB front end for some of the MSAD controllers, the plug-in had to exist on each domain controller. Again, not practical and rejected.
To take a step back, MSAD and Oracle do not use compatible hashing algorithyms for their passwords so when a user changes their AD password Oracle needs a way to capture that password, and hash it in its own format for transmission to OID. This is why the Password Filter and even the plug-in are required, and on each domain controller since the change may occur on any controller. To be fair we are currently trying to implement an IDM product from another vendor as well and it has run into the same problems so this is not anything specific to OID and MSAD.
At this point it seems my only option is using a combination of Kerberos and Server Chaining. We already use Kerberos via QAS (Quest Authentication Services) for our UNIX/Linux integration to MSAD so their is some experience. Kerberos is rather difficult I've been told and I'll just have to see how things go when I start the detailed implementation in the lab. If anyone has thoughts, experiences or details around how they successfully integrated OID and MSAD please do contact me, I would love to discuss. Such details seem to be not exact in the blogosphere, forums and definitely documentation. My vision is below:
OID Components and requirements
The basic components are:
Database Repository - This database is where OID stores all its information and can be Standard Edition (SE) or Enterprise Edition (EE). Directory Services Plus comes with a restricted use license for SE (as seen here), iAS comes with restricted use of SE and EE (or so it would seem here), though complicating all this is the statement mentiond in my Part I of this series (so I've no idea but am going with what Oracle has stated). You can visit MOS for the current listing of certified versions, I chose 18.104.22.168 EE (single instance). The basic requirements are listed in MOS note 872885.1 and documentation here:
Character Set = AL32UTF8
open_cursors>=500 (800 for RAC)
processes>=500 (2500 for RAC)
WebLogic Server (WLS) - I am using OID 22.214.171.124.0 so the certified WLS version is 10.3.5. Note that this is not required if you don't need a nice interface such as ODSM and Fusion Middleware Control to OID. I would recommend though that you install WLS as you lose nothing since you still have command-line and gain a nice interface for those times when you need a pretty face.
Following the installaton of the above required components, you can proceed with the installation of OID itself which, for my own installation consisted of:
Oracle Directory Services Manager (ODSM) - This is a web-based interface for managing instances of OID and OVD and replaces Oracle Directory Manager (ODM) which is now deprecated.
Oracle Enterprise Manager Fusion Middleware Control - This is a graphical interface that provides comprehensive systems management for Oracle Fusion Middleware including OID (target ype). Based on the name you would think you could just use regular OEM but thus far I've not had time to investigate this thoroughly.
Oracle Directory Integration Platform (DIP) - Provides directory synchronization capabilities which includes connectors for out-of-the-box synchronization with Novel eDirectory, and MSAD. This of course is only required if you are seeking such functionality.
Oracle Internet Directory (OID) - The internet directory component itself. Note that I am using version 126.96.36.199.0 which is actually a patchset and requires installation of 188.8.131.52.0 and then the application of the patch ontop. This is a bit strange since there are components within Fusion Middleware 184.108.40.206.0 which are self-contained installations and not patches, much like the Oracle Database 11.2.0.x software. I'm hoping Oracle will give this, along with every Oracle product, similar treatment to be installed as self-contained units instead of patches. I find this leads to clearner, more streamlined and less error-prone installations along with better out-of-place patching.
Note about High Availability
There are many options for HA with OID. The one I've chosen, as shown in my diagram, uses two OID servers each running separate OID and database instances; synchronized via LDAP multi-master replication (MMR), and optional fan-out replicas. Unless you are planning a single OID instance, I do not believe RAC makes a lot of business sense given you get the same features (availability, scalability and performance) along with others (rolling upgrades) from MMR. Using LDAP instead of database MMR provides better granular control over the replication process as an option (security, and performance) though if using SSO you will need to use database MMR. The fan-out replication is essentially just LDAP MMR with the synch process being down stream read only (and possibly filtered).