Skip to content

Part 1: Windows Server 2008 Active Directory Kerberos and LDAP Integration — Preface

This is the first post in a series on AD integration; the next post covers installing and configuring Active Directory


Systems administrators who work in heterogeneous environments understand both the value and the challenges of integrating user account information for the variety of platforms that they manage into a single system. My goal is to provide a series of technical notes detailing the processes I’m using to provide a single identity management system based on Active Directory that supports authentication for Linux, Solaris, and Mac systems — in addition to Windows clients, of course. I’m hoping also to provide information on our use of CIFS and NFS to provide home directories to all of these platforms as well.

To start out with a bit of background, my employer has been maintaining dual account systems for many years for Solaris and Windows clients. Initially we used separate NIS and Active Directory accounts, both accounts had to be set up separately, and users were responsible for remembering both passwords, or for manually synchronizing them if desired. Shortly after I was hired, a coworker and myself were asked to look into tying together these two systems. At the time, Sun had just released version 1.0 of their Identity Synchronization product, which tied together Active Directory with Sun Directory Server. After a lot of communication with Sun’s engineers we were able to put together a system that allowed us to create accounts in LDAP, and have them automatically populated to Active Directory, and to have password changes populate immediately in either direction. This solved most of our problems, most importantly simplifying our users’ situation — from their perspective, there was only one account that they had to deal with. This system matured over the years, going through various upgrades of the products involved, and expanding to support Linux systems.

Behind the scenes, however, there were still two account systems. The illusion of a single account would be occasionally shattered when a user’s password didn’t get synchronized properly; the system was pretty robust, but subtle differences in password strength and expiration policies, or unnoticed PKI issues would crop up, causing headaches for users and for me. As these problems continued to crop up at infrequent intervals, I began to do some research into what would be required to take the next step in evolving our network infrastructure, by truly consolidating to a single user directory.

I was initially encouraged by the number Google results that came up when I started looking at the problem — dozens of HOWTOs, forum threads, and blog posting describing the process of authenticating all of the platforms I used against Active Directory. When I actually started setting up a test lab, however, reality hit me hard. As is often the case in this kind of situation, things that ‘just worked’ for other people ‘just didn’t’ for me — I tried many different scenarios, tweaking the suggestions in HOWTO and attempting to mix in fixes from the forum posts. When I finally made some progress, I promised myself that rather than sticking to my usual documentation procedure of writing a cookbook that worked for my exact situation and limiting it to our internal documentation, I’d try to write my own heuristic HOWTO, with enough depth and detail to hopefully be useful to others who are trying to accomplish similar goals. So, my first post is going to detail the setup of the Active Directory server, then I’ll talk about setting up the various clients systems. I’ll consider posting some info on ancillary processes such as account provisioning, home directory management, etc.

Categories: Random.

Tags: , , , , , , , , , ,

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.