upstream directory to your AD?

Reply to topic
5 posts
Does anyone here have a directory one level above your AD that feeds info to AD (and possibly other directories?)

This seems most common in really big organizations with a lot of legacy processes around another directory, especially if a lot of large systems are unix based.

This seems especially common at universities where the AD is a consumer of feeds from a much larger directory service.

One university I used to work at was starting to talk about possibly using AD for everything, but it would be a major project.

I don't remember the details, but I believe most of the user data originated in a series of Oracle databases, which fed an IBM LDAP server, which in turn fed information to several different Active Directory domains, an LDAP server for white pages/pubic directory info, a Novell eDirectory, and a legacy Unix authentication environment. If you wanted to make changes to any user objects it had to be done way up the chain since changes would get wiped out by anything done manually when data was reloaded on a nightly basis.
We operate multiple ADs with a Unix based LDAP and entitlement app for enterprise application access. We use a SAML tool to give some of the AD users SSO into the Unix environment.

IMO, integration is really expensive, both in terms of licensing/infrastructure and the smart people whom you need. It isn't the "best value" from a $ perspective for internal users. Just take the political hit and consolidate to a single AD (at least for users), which will make everything simpler in the end.

But, if you have lots of external users, AD probably isn't the optimal platform to handle those folks with.

In any scenario, you need a coherent provisioning process, preferably one that is integrated with your HR.
I've been at a lot of places that do this. It's not too difficult to set up OpenLDAP as either a master server (holding the authoritative piece of information for any given object & it's attributes) or as a caching box that maps queries back to what ever system *does* hold the authoritative object.

Implementation is a pretty big undertaking though, you need to understand the schema's themselves pretty well and have a good grasp of MDM. The tech is simple, the implementation is tricky as hell & ideally you have a 3rd method used for authentication like Kerberos.
I've seen many deployments where AD is the authoritative directory, or a child to a higher directory which existed long before AD exist. Universities are where I have personally seen it the most, trying to find a way to merge their various colleges into some kind of global directory. It certainly isn't the easiest way to do things, but sometimes there are no other options when you're dealing with hundreds of legacy applications and history itself.
As hinted-at here, you're going to have to figure out if you want to do federation of directories via stuff like Kerberos integration, or synchronization, typically from a single system. They both have a lot of trade-offs, and synchronization can make password management a hassle unless you also have a good SSO product. ... And there are architectures that will do both federation and synchronization.
5 posts