Giant active directory deployment vs giant Sun LDAP

At work we're in the early phases of an identity management project. This is all in the context of higher ed where we have a couple thousand faculty / staff and about twenty thousand students.

Has anyone used the Sun LDAP server with an AD domain (kerberos realm) for password storage? Has anyone run an AD domain with a quarter million entries in it before?

One option we have for our identity management is to push active staff onto AD and another copy of the password / identity information to LDAP. We'd need to have a central place to change passwords if we did this so that if you change your AD (or ldap) password the change gets synchronized to the other (or they're allowed to diverge)

The other choice is to have AD be the single authority on passwords, and then we have to have principals for all affiliates (as well as all old affiliates) for a decade or two so we may have a quarter million entities in AD, of which only 20-30k would be accessed with any frequency.

Would AD explode under the load? Are there other ways to keep the passwords between Sun's LDAP and AD synchronized? What are other people's experiences?

Solution 1:

This is a good place to start: http://technet.microsoft.com/en-us/library/cc756101(WS.10).aspx.

This tool is quite outdated (it was made for Windows 2000 and only knows about < 1 Ghz CPUs), yet still says that 3-4 DCs will be more than enough for 500,000 users of which 50,000 are active daily. I don't think you should have any problem managing such a database with today's hardware.

Solution 2:

I work with higher-ed customers all the time discussing exactly the scenario you're investigating.

AD will have no problem with that many objects. I've worked on customer environments which have several multiples of that.

Many of the customers I work with in your scenario end up disabling password changes natively through AD and forcing people through a portal of some sort which talks to a tool of some sort which feeds the password into all the systems that need an independent copy. This is fine unless it breaks and things get out of sync. I've also worked with the Kerb scenario and while it works, it's not something many people know how to run or support so you're probably asking for trouble there in terms of operational staffing.

You could also look at something like ILM from Microsoft which will capture password changes in AD and let you forward them to other systems (e.g. Sun LDAP, etc). This allows people to use the native password change functionality in AD over a homegrown app.

Having folks with affiliations like alumni, application, community, etc is fine. The one thing I caution folks about here is keeping in mind that default permissions like Everyone/Authenticated Users casts a much wider net so you need to ACL things with groups that represent affiliations which represent the actual users you want to permit access for (e.g. Active students, faculty, staff, etc). I also try to get folks to regularly cleanup accounts for folks who are application affiliates.

In general I push really hard not to have parallel LDAP directories. It's really just a waste of time and money generally speaking to have two (or more) services doing the same thing.

Solution 3:

Would AD explode under the load?

I was an ASP.NET portal developer for over 80 online/ground vocational schools mostly in the US with well over 250,000 AD objects and with probably an active account usage in the 60k area (to my knowledge). I never saw any production issues with AD. Bear in mind we also had the second largest Exchange/AD object in the world at the time. AD can hold up under load when properly designed and configured to do so. I used to be skeptical of Microsoft's AD or as I used to think of it as M$LDAP, but it seems fairly stable, reliable if configured to your use case/environment.

Are there other ways to keep the passwords between Sun's LDAP and AD synchronized?

I can't speak for Sun LDAP, nor syncronization. AD replication (by itself) was reliable and timely. At think we had a total between 4 to 6 AD servers and I can't recall a single issue.

Are you already implementing AD and looking to append Sun LDAP or is it the other way around? Perhaps it would be better to stick with one solution (Sun or Microsoft, I have no preference) as managing numerous accounts could become an issue. I often find that when creating a hybrid solution, I may or may not have the tools to make things manageable. I'm in no way an LDAP/AD master, but even programming AD accounts and using AD MMC snap-in tools to find accounts was fairly tedious.

Solution 4:

There's ups and downs to each approach.

The nice part about using Sun LDAP for application authentication and authorization is that its easy to support across networks and in DMZs. In a university environment with lots of silos, this might be a real advantage as you could set flexible standards that are likely to actually be adhered to... LDAP is easy to manage across firewalls, flexible, and you have a variety of ways to protect your apps, from simple LDAP bind to SSO solutions like Siteminder.

The big downside are that you're buying alot of software, and now you need Unix/LDAP people.

If you really want single-password integration, you can use a meta-directory like ILM or a Federation tool like Ping to keep your active, AD users synced with the LDAP. The upside with a Microsoft solution is that it's easier to "graduate" MCSE types, and you get the "one throat to choke" capability when things go bump in the night.

Going for the AD model is doable -- AD can scale that high. The big problem IMO is that you're going to need more servers with more resources, and supporting a central AD in DMZs can be a less than pleasant experience. In my world, with the network design philosophy and security policies that we deal with, delivering AD services outside of the client computing environment is a nightmare.

If I were in your shoes, given the information in your question, I'd look at a hybrid LDAP/AD approach. Let the AD service the 20-30k active users, and get the other 250k into the Sun system. The best answer is probably heavily dependent on how you provision...