Posted on April 2, 2013 by Marc Boorshtein
“And it must follow, as the night the day, thou canst not then avoid Active Directory” – paraphrased from Hamlet: Act I, Scene III.
Who would have thought Shakespeare was such a visionary? He's right though; you pretty much always need to plan for integrating Active Directory.
First, some background: During the legendary Directory Wars of 2002 – 2006, IT departments all around the world were locked in a brutal civil war over a simple question - “Should Active Directory be the enterprise directory?” Should the Windows identity store be THE identity store for all enterprise systems? On its face, the question seemed easy to answer: “Of course!!!” AD is an LDAP directory that could just drop in to an environment, it could manage user policies and since EVERYONE uses Windows (I type this in Libre Office running on Fedora Linux, by the way) there's already an easy interface for resetting your password and configuring policies. The dissenters cried that AD didn't conform to LDAP standards and that using AD as the enterprise directory would put too much load on the Windows authentication system (this is still when Hotmail was run on Unix, not Windows). Well, after they saw the toll on IT departments-and budgets-of these battles, the directory admins put down their arms and, while they never truly accepted Active Directory, at least they learned to live with it.
Which brings us to today. It’s been many generations (of ants) since the Directory Wars ended, but the scars still remain. Nearly every large organization uses Active Directory. An entire industry has risen to integrate the “standard LDAP” Active Directory into non-Microsoft systems as well as managing AD and filling the gaps between a Windows authentication system and an Enterprise directory.
Over the past 13 years since Windows 2000 and Active Directory's release Microsoft has pushed certain design patterns onto IT departments:
I'm not going to debate the merits of these design patterns. I only point them out since most IT departments follow them in one form or another and so we must understand how to handle them.
So how does this relate to your Fusion Middleware deployment? Oracle has built Fusion Middleware around Oracle Platform Security Services, which is an identity layer that allows for Fusion Middleware to not be tied to a particular application server's security platform. Even with this abstraction, FMW still can only be reliably used with a single LDAP directory. This directory can be any one of Oracle's products (OID, OVD, OUD, DSEE, etc.).
So how does one work in a multi-domain, multi-forest environment? There are two options:
Which option is best? That really depends on your particular organization and circumstance. There are several things to consider however:
Either way, it’s important to plan for this at the conception of a FMW deployment. Because of both the technical and organizational challenges Active Directory can bring to FMW it’s important to plan up front rather then trying to bolt on after the fact. Just as with SSO, a discussion about buying OVD or other directory products will likely become a distraction if not planned for in the beginning and take away from the value being provided to the business by the Fusion Middleware.
Director, Identity Management & Security