Active Directory vs OpenLDAP

Question

This is for a small company (12 developers) who haven't implemented any centralized user database - they've grown organically and just created accounts on computers as they needed.

From a management point of view, its a nightmare - 10 computers all with different user accounts. If a user is added to one computer, they manually need to be added on all the others(that they need to access). This is far from ideal. Moving forward and growing the business will mean exponentially more work as more computers/users are added/hired.

I know that some kind of centralized user management is sorely needed. However, I'm debating between Active Directory and OpenLDAP. Two current servers function as simple backup and file-sharing servers, both running Ubuntu 8.04LTS. The computers are a mix of Windows XP and Ubuntu 9.04.

I don't have experience with Active Directory (or really OpenLDAP for that matter, but I'm comfortable with Linux), but if one solution outweighs the other then its warranted that I learn that.

Upfront cost isn't really an issue, TCO is. If Windows (SBS I'm assuming?) will save me enough time to make up for the increased upfront cost, then I think I should go with that solution.

For my needs, what solution should I be looking at implementing?

edit: Email is hosted off-site, so Exchange isn't necessary.

Answer 1

You're going to get a lot of nice features from Active Directory that you're not getting with OpenLDAP. Chief among them being both single-sign on (i.e. one user account that works on all client and server computers), and Group Policy.

I love open source software, but until Samba 4 matures, Active Directory provides the very best administrative experience with Windows 2000 and newer client computers.

Without using third-party software there is no standards-based LDAP authentication with Windows XP clients. Read my answer here re: Kerberos integration with Windows XP-- the experience using OpenLDAP will be very similiar (except that you will need third-party software like pGINA up front to make LDAP authentication work): How to get windows xp to authenticate against kerberos or heimdal

Whether or not to go with Windows Small Business Server depends on what you want to spend (initial cost and cost of client access licenses for SBS is more than "plain vanilla" Windows) and whether or not you will get value out of the additional "features". I prefer to think of Windows SBS as an inexpensive Windows and Exchange bundle (with an overly complicated setup and cruddy admin tools that I never use.) I tend to administer Windows SBS like a "normal" Windows and Exchange Server machine, and it works very well as such.

A Windows Server with Active Directory, Microsoft DHCP/DNS, WSUS (to provide updates to client computers), and some Group Policy objects to handle configuring user / computer environments and installing software will lighten your administrative load tremendously and make adding future computers easy. Exchange isn't that difficult to get up and running (the biggest problems being related to getting your mail to flow to it from the Internet-- so many people don't seem to understand how DNS and SMTP work together).

Assuming your install is performed by someone who knows what they're doing, and that you treat everything well after-the-fact it will run fine for you w/o a lot of administrative headache. I write off people who bemoan the unreliabilty of Windows and Exchange, because typically they are having problems because they either (a) used inferior hardware and are paying the price in the long run, or (b) are not competent to administer the software. I have Windows SBS installations going all the way back to the version 4.0 time-frame that are running fine years after the installation-- you can have one, too.

If you don't have any experience with these products, I'd recommend working with a reputable consultant to perform the install and get you started with being self-sufficient on administration. I'd recommend a good book if I knew one, but I've been fairly displeased with nearly all of them that I've read (they all seem to be lacking in real-life examples and case studies, typically).

There are plenty of consultants that can get you off the ground inexpensively (the setup you're talking about, assuming that you're going to do the "bulk" work yourself, feels like about a day and a half to two days for a basic Windows and Exchange install, to me) and can help you "learn the ropes". The majority of labor is going to go into migrating your existing user environments (migrating their existing documents and profiles into their new AD account's roaming user profile and redirected "My Docuemnts" folders, etc) if you choose to do that. (I would, just because it will make the users happier and more productive in the long-run.)

You should plan on some kind of backup device and backup management software, a server computer with redundant disks (minimum RAID-1), and some kind of power protection (UPS). I would expect, with a low-end server, licensing costs, and the power protection hardware that you could get in the door w/ Windows SBS for roughly $3500.00 - $4000.00. Personally, I'd spec you roughly 10 - 20 hours of setup labor, depending on how familiar you are with your needs and how much of the work you want to be taught to do, versus having the installer do it.

Here's a high-level list of the typical kinds of installation tasks I see in a deployment like yours:

• Physically setup server computer, UPS, etc.
• Install Windows, Exchange, WSUS, infrastructure services, service packs, backup management software, UPS management software, etc.
• Discuss file sharing (permissions, shared file locations, directory hierarchy).
• Create user accounts (roaming profile folders, "My Documents" folders, etc), security groups, distribution groups, basic GPO's.
• Discuss migration of existing email data and formulate strategy, changes to DNS to bring email directly to Exchange.
• Discuss migration of user environments to new AD accounts. Develop procedure for migration if training to perform migration is desired.
• Perform pilot migration(s) of client computers and user profiles into domain.
• Discuss day-to-day sysadmin tasks (password resets, changing user group memberships, reviewing backup success/failure notifications, monitoring WSUS and update installation), discuss common issues, troubleshooting, and resolution, conduct Q&A session.
• Make recommendations for future activities (automating software installations, VPN connectivity, etc)

Answer 2

Stick with the open-source, if I'm reading your question correctly:

• You don't care about Exchange
• You don't have a huge need for minute control of XP settings - I love group policy primarily to save the admin/sales staff from themselves, the developers mostly need me to stay out of their hair
• You're more comfortable with *nix than windows

AD is great at managing windows to a fine degree, but if you don't need that, you're buying yourself a learning curve that won't likely bring a great deal of benefit.

2 caveats

• If you've got the time/interest to push yourself more on the MS side of things, this is a good way to provide that.
• WSUS is a good way to control workstation/server patches. If you can't just flip the "automatic" switch on all machines, this might push the balance over to SBS (if SBS does WSUS?)

Answer 3

OpenLDAP can be used for checking passwords but it is mostly a centralized way to manage identities. AD integrates ldap, kerberos, DNS, and DHCP. It is a much more comprehensive system than just OpenLDAP by itself.

From a management perspective, you could simply install AD on a pair of win2k3 servers and point all the unix systems at it and use the AD servers only for password checking. It is super trivial to make a unix system with pam use kerberos for password checking and local password files for authorization. It isn't quite as good as full AD integration but is also trivial to implement.

pros and cons of AD linux integration

using AD as a kerberos server to authenticate local accounts

Answer 4

You should also have a look at Fedora directory server (which apparently is now officially "389 directory server"), based on the Netscape LDAP codebase. It's sold by RedHat under their brand, and so is actively maintained. I've heard it's nicer than OpenLDAP in some respects, although I've never used it myself. It's probably closer to AD in functionality than OpenLdap by itself, which is really only the core of a fully fledged directory system.

There is also Apache Directory Server, which is pure Java and also looks like it's actively developed.

Answer 5

Since you have no experience with either, there will be costs (mainly in time) associated with the learning curve. From a maintenance standpoint, the only time you ever really have to touch LDAP is when you add/remove accounts or modify their attributes (name/address changes). This is done easily enough with both. From an implementation standpoint, it's the directory that you want to be able to have the easiest time allowing the clients to communicate with: Active Directory is easier since Windows clients can natively 'talk' to domain controllers and documentation for allowing Ubuntu/other Linuxes to authenticate from AD is readily available. If you want your Windows clients to be able to authenticate off of openLDAP, you will need a SAMBA server listening for requests (openLDAP does not do this natively). Samba will allow you use openLDAP for authentication while allowing for windows-like file sharing.

Answer 6

AD offers things like Group Policies and other management stuff you won't get very easy with an openLDAP solution, it's a snap to install a basic deployment of Windows Server and integrate it with XP/Vista/7 clients, and integration of Ubuntu clients is of comparable difficulty with AD and openLDAP.

Products like Suse SLES and Redhat Enterprise Server (or CentOS) make integrating Win and Linux easier than, say Ubuntu or Debian Servers, but it's still a lot to learn.

If cost would be an issue, you could create a setup with Linux and some additional software, like Nitrobit Group policy, that would allow a comparable amount of functionality, but with a steep learning curve.