Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
It is not clear by the question if AD/Sun are choices you're evaluating for a new system, or if you have already something in place you need to mantain/connect to/interop with. Can you clarify? – Massimo Sep 1 '09 at 19:18
Can you expand a bit on your 4th paragraph a bit. Not sure what you mean by old affiliates etc. – Dayton Brown Sep 1 '09 at 19:20
An old affiliate would be someone who was active for a time then moved on -- as happens often with students. Later they may say "I'll pay my alumni fees" and we grant access to more resources for that account, so at no point can we simply remove old accounts. – chris Sep 1 '09 at 20:21
@Massimo -- We've got a typical higher-ed's worth of wacky obnoxious old applications and grungy old silos of identity. Some ldap servers and clients here, AD domains there, and so on. – chris Sep 1 '09 at 20:29
up vote 4 down vote accepted

This is a good place to start:

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.

share|improve this answer
It's really interesting to see how few 933mhz xeons I need to support what I would consider to be a pretty big (for today) environment. Thanks for the link to the tool. – chris Sep 1 '09 at 20:30
And bear in mind that Windows Server 2003 performs a lot better; have a look at the AD section in this whitepaper:…. – Massimo Sep 1 '09 at 21:16

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.

share|improve this answer
Hey Brian, I can tell by your answers that you are quite well versed in AD and can be a very valuable member of the SF community, so please don't take this the wrong way, but signature/tag lines at the end of posts are frowned upon here. People (not me) will likely down vote you just because of this.… – MDMarra Sep 5 '09 at 22:06
Ditto on both - feel free to put any sig-type information in your user profile. – Kara Marfia Sep 18 '09 at 20:18

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.

share|improve this answer
Oh, we've got an openldap directory (everyone) and an independent AD infrastructure (faculty / staff). The current plan is to put all students in ldap and all faculty / staff in AD and sun ldap. I'd like to propose that we have the sun ldap get the passwords from AD (or even skip having sun ldap at all), but that's contingent on having AD not explode in weird ways. – chris Sep 2 '09 at 0:23
Oh -- and thanks for recounting your experiences! – chris Sep 2 '09 at 0:24

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...

share|improve this answer
My primary concern is where to store the passwords... Some models have the passwords in both places (and it gets changed in a third place that feeds the ldap and AD silos) and other models just stuff all the passwords into kerberos (AD) and make everything else either speak to the kerberos domain directly or via a proxy like ldap or radius. I'm more partial to that model, though it makes the ldap implementation a bit more complex with gss-api. Would such a hybrid (sunldap + AD for storing passwords) be reasonable? – chris Sep 2 '09 at 3:03
I think that's reasonable. We're looking at doing that by using Ping Federate to provide authentication to external users (business partners, etc) hitting a SharePoint farm. Ping uses SAML for communication between the AD and LDAP. I think using kerberos would work as well (and would be cheaper!), but would be very challenging in my environment. – duffbeer703 Sep 2 '09 at 12:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.