Late blooming blogger - beginning of our LDAP saga

I don't know if anyone else is like this, but I, at least, don't follow blogs. I search them. That is, when I'm interested in a specific topic, I'll google it. Often, I find an interesting blog post or two which I'll read, but I never bother to go back and scan those blogs again.

Ergo, I'd never bothered to blog before largely because I'd not anything to say worth anyone's time. I'd always thought that, to be worth reading, I should have something informative to say.

Well, I do.

Specifically, I thought it'd be helpful if I were to document a bunch of what I've gone through to create our heterogeneous unix LDAP environment at work. There was a pretty fair amount of patching stuff together in ways that weren't documented anywhere. So, I'm going to start a series of blog posts, titled, roughly:

LDAP in a heterogeneous environment - What they don't tell you.

First up, some background on our situation.

I work as a unix admin for a medium sized company - we have about 600 unix servers split roughtly in thirds between AIX, Linux, and Solaris, with a few oddball HP-UX and VMS boxes. There's also about 3000 Windows servers, some Tandem non-stop, a pair of IBM mainframes, some IBM eSeries, a few racks of OS-X high performance compute cluster boxes, and lots of other odds and drabbles I'm only periferally involved in, if at all.

When I transfered to the Unix admin spot from a DBA team about 4 years ago, we had a partial LDAP infrastructure, consisting of a OpenLDAP master server and two slaves. However this was only used for our Linux boxes, so it had limited penetration, and was in other ways a bit of a mess:

• Uids and gids were pretty much all over the map, including some duplications;
  
• There was no automation of provisioning, users had to be manually created in LDAP, and home directories had to be manually created for users wherever they had a login;
  
• Worse, there was not automation of account de-provisioning for when people transfered or left
  
• Password changes were haphazard, didn't always work, and weren't synchronized with our institutional password management infrastructure
• The schema loaded on the server just plain didn't work with most AIX and Solaris clients.

In short, I could make a few patches to limp this system along, but in the end I was looking at a complete replacement. To start with, I came up with the following set of goals and requirements:

1. Central Authentication and Authorization database/repository


1. All client platforms & os's can use (AIX, Solaris, Linux, HP-UX)
2. Highly available
3. Meets institution security and access policies
4. Uses same username, passwords, and unix specific identifiers (uids, gids) across all systems


2. Repository information is replicated from core sources, including:


1. Username will be the historical Unix and Mainframe format, not Active Directory
2. Real name & information (office, phone#...)
3. Password
4. Account disable and account removal


3. Automation, application access and authorization functions offloaded from unix team


4. Meets auditing requirements for user management


1. Determine for each account what level of access and authorization it has across all systems
2. Maintain access history for each account
• security changes
• access level history


5. Only those accounts valid for the application(s) hosted on a specific machine are presented on that machine.


6. Client machines can be configured without reference to user accounts contained in the repository. E.g. if account 'foo' is to be used on machine 'bar', no configuration file on 'bar' must have a specific entry for 'foo'.


7. Secure on the wire network transactions between client machines and repository server

In later posts, I'll give more detailed information about our old LDAP setup, explain these goals a bit more and talk about the process we used to design and select our new architecture.

Bye for now.
-- Pat