Slashdot Mirror
Directory Service Implementation From Scratch?
An anonymous reader writes "I work at a small but growing startup company. Currently, our directory and authentication information is scattered across many systems and wikis, and is becoming increasingly difficult to manage. We are looking at centralizing this information in a directory service to minimize administrative overhead as we continue to grow. The service must support basic directory searches, as well as user authentication for Linux and Windows hosts. Although we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain. Most directory servers seem to support integration with other directory servers, however it seems like it may be easiest to just use Active Directory for everything. Are there any pitfalls with this approach? If you had the chance to redesign your enterprise directory service without regard for legacy services, how would you do it?"
I really hate to say it, but I think Active Directory is most definitely the way to go. No other directory systems allows for as simple administration of a large number of windows computers, your windows clients will "Just Work" with it, and it isn't difficult to make windows boxes, wikis, etc authenticate against it (I've had to do this many times...).
Active directory lets you access it via LDAP which a lot of software packages understand (a note here, structure the LDAP binds such that the username is in the form of SAMACCOUNTNAME@WINDOWSDOMAINFQDN, this has worked almost every time for me).
The free version of Likewise Open will make it very easy for the linux boxes themselves to authenticate against AD without having to mess with any pam conf yourself, and if you pay them money you can even deploy GP's to linux boxes (disclaimer, I've never tried this part).
In sum, while I hate to say it, you can make almost any client solution work with AD either directly or via LDAP or Kerberos, and it's the best possible solution for windows client management, so I'd go with that.
Just my .02
This. AD's management tools are brutally efficient and understandable. The newest versions of Samba+KB5 make it trivial to authenticate *nix systems against it and have fully integrated, cross-platform user & privilege management with consistent uid's/gid's across all hosts. Assuming you throw the right amount of resources at it (at least 2 AD servers per tree in the forest, per site), and take advantage of the DDNS services, you'll have a really scalable, easily managed infrastructure for years to come.
Even Jesus hates listening to Creed.
use Novell's eDirectory, it may cost, but they have a product called "Identity Manager" which allows you to interconnect many different systems to a central ID vault. Password changes are transparent, and management is extremely easy. Best of all it runs on Linux. You don't need the "netware" component to use it. It scales like a dream and is very robust
~corporate tool, but employed~
1.) RHDS - Red Hat Directory Server
2.) Active Directory
3.) OpenLDAP
4.) Novell eDirectory (personally my least favorite)
I would probably jump for RHDS first, then AD. The only problem with OpenLDAP might be getting a similar level of support to the first two. Support is exactly why I would never choose eDirectory. I have (personally) had abysmal experiences dealing with Novell. Others may disagree though. And of course there probably are other options.
Likewise, Centrify, Quest and others (Centrify especially) provide tools for all flavors of Linux, JBOSS Servers, Apache servers, and Oracle databases to all use AD for directory services. Centrify has tools for audit and command control that piggyback on restricted shell.
It's hard to argue against AD - even in your situation where the Microsoft boxes comprise the minority of systems.
Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??
You can configure a Samba server against LDAP and have everything authenticate agaist that. Your biggest pitfall is going to be finding support for the configuration. You have to consider "what if the IT Admin get's hit by a bus, who's going to support this configuration". With Active Directory you can flip open a phonebook and find a dozen local places that will support it; that's not the case with the Samba/LDAP configuration.
FreeBSD.org - The power to serve
Use AD.
Even though folks will fuss and whine about AD being not pure LDAP...
You're not a developer, are you? Whether or not AD is a dream to work with depends heavily on what your job description is. If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy. If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD. It's not an unsolvable problem mind you, just a really annoying one.
... It's simple enough that MCSEs can run it.
So is RHDS / Fedora Directory Server. I knew exactly nothing about LDAP or directory servers when I got my first directory server related project years ago. I still I got the thing set up and running inside of a couple of hours. Even an MCSE should be able to manage setting it up, hardening it and administrating it in a very short period of time.
Only to idiots, are orders laws.
-- Henning von Tresckow
Yes, SQL. If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future. LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it. The result is horrible password sync hacks, multiple passwords per user, etc.
The idea is to put raw user info in SQL, including their clear-text password. Of course, lock down that SQL server like you've never locked down anything before! It should have a very limited interface for updating user data. Next, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.
An implementation of this scheme is running on many of the biggest universities in Norway, and is called Cerebrum, http://www.cerebrum.usit.uio.no/english.html. User administration happens through a frontend interface appropriately named BOFH, where users and admins can change data in a secure manner. Users can change certain of their own attributes, while admins have more power. It's worth checking out (although their sf.net wiki seems to be down at the moment, unfortunately).
Its going to sound like blasphemy here on slashdot, but I strongly recommend one master ActiveDirectory server with Services for Unix installed. You can manage everything from the nice pretty windows GUI, have perfect windows support and using pam_krb5 and nss_ldap (I use them in FreeBSD, I believe both of which were originally for linux, not sure they would be the best for it) for pulling all your user information from AD. Services for UNIX adds tabs to the important objects in the ActiveDirectory UI to let you edit the unix attributes.
Combine nss_ldap, pam_krb5, sasl with kerberose auth, and samba 3 or newer, the kerberos auth module for Apache and you can have complete and total authentication based on ActiveDirectory with a very nice GUI, and you can still use standard ldap tools to work with the directory if you want. Samba will do kerberos with windows beautifully at this point, just make sure you keep eveything time synced. Even does all the 'single signon' stuff for websites.
You end up using a great authentication mechanism on your unix AND windows hosts (kerberos is king). The only catch that may or may not apply to other OSes, but it definately bit me in FreeBSD 6, FBSD wants to use UDP for all its kerberos communications which is normally fine, but once you get a user with a large collection of kerberos data, in my case, lots of groups either directly or via nesting, then the packets become too large for a single UDP datagram and FBSD is too stupid to switch to TCP on its on. My solution was simply to block all UDP port 88 requests in and out of my FBSD boxes so they immediately fail over to TCP (not, you have to return ICMP errors, not just drop packets or it'll just hang as it doesn't know the packet can't be sent).
Not sure if Linux's kerberos implementation supports forcing TCP in krb5.conf. FreeBSD is SUPPOSED to, but older version certainly don't.
I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD. We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language. Works awesome. If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.
With far less effort than any other directory server you can have full single sign on support, good authentication, and an easy to use interface in which you can delegate control to various folks outside your IT department and let them use the AD manager for windows (on xp or whatever) to manage the department they need to if you want. You can auth pretty much EVERY modern OS this way. Hell if you want to you can run the servers on Unix (OpenLDAP/MIT Kerberos) for backup or for serving client requests and just isolate the windows machine as the master if you want.
Okay, now I sound like a total fanboy, please don't hate, but it really is a good setup. The main reason being, from my point of view, the setup and most importantly, the administration of ActiveDirectory and Services for UNIX are FAR above and beyond anything the F/OSS world offers. Sad, but true. I imagine you could probably get good support from Novell eDirectory as its tools are pretty good when they work, haven't used them since 6.0 when all their Java apps were asstastic, but I was only admining the leaf node of a tree with a few hundred thousand accounts in it (State of Georgia was using eDirectory a few years back, all their employees are in it, may have changed by now), so it may work better in smaller setups. All things considered it didn't do bad there, was just far too slow for editing my own subtree as we had to wait on updates to be pushed back up the tree bef
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The other thing you can consider is whether to split the directory services and the authentication.
At my last job we did the following:
- Use Windows AD for all windows machines
- Use NIS for passwd, group, automounter maps... everything but authentication.
- And then key the Linux machines to use Kerberos off the Active Directory
Now if I was doing it again, I'd do the following:
- Use Windows AD for all windows machines
- Setup up a UNIX/Linux based Kerberos domain that "trusted" by the AD Kerberos
- Use NIS, NIS+ or LDAP from Windows AD for directory services for UNIX/Linux
- Setup all the UNIX/Linux machines on the UNIX/Linux Kerberos domain and have them use the windows domain for user authentication.
The adavantage to this would be that once you have a valid ticket you can securely log into any of the machines. Plus then you could securely setup NFS v4.
As for which NIS, NIS+ or LDAP to use, I haven't looked into recently.
And why I would use two Kerberos domains is that the Windows AD says it should play nice with Linux machines and allow you at keys onto them. But the commands from Microsoft never worked. I used a simple utility from some consulting company that worked well, but it wasn't supported and there it seemed to be hitting some hard limits. Since I'd hate to wait for Microsoft to fix their setup, I'd use two domains but setup a trust between them.
First off, AD does provide LDAP services, it is ActiveDIRECTORY after all.
Second, every OSS app out there pretty much lets you modify the schema it expects from the server, meaning making it talk to an ActiveDirectory server is just a matter of properly setting up the schema. Hell most apps now days already have an example config for talking to a stock ActiveDirectory, but you're better off with AD + Services for Unix so you get AD and Unix UID/GID administration in one pretty point and clicky interface.
Other than having a more flexible schema, since it doesn't assume you need to talk to windows, its inferior to AD in just about every other way, excluding price, where of course it beats the shit out of AD :)
If your last two startups were made easier by not using AD, you have incompetent admins who don't actually understand ldap or kerberos.
With openldap you get a directory, which CAN be used to authenticate, but thats not what you should be doing. Kerberos is accepted everywhere as the best authentication system to use in an organization, hands down, Unix OR windows. With AD you get both. Which means instead of using your crappy 'bind to auth' or 'bind as someone then query to auth' and 'hopefully we remembered to use SSL everywhere that needs auth', with AD you get LDAP + kerberos for auth, best of both worlds.
AD allows you to manage users with those same applications, host or web based as it support LDAP perfectly so OpenLDAP doesn't have anything on it there.
Fourth, you can just make samba join your activedirectory server instead of making it pretend to be one and dealing with all the quirks that goes with that if you have anything beyond the most simple of setups.
Want samba to join ads? Install samba 3 or newer, install a time sync utility if you don't already have one, type:
net ads join
Follow prompts, done.
Go the next step and tell samba to generate a keytab for kerberos for you and be happy as now you can start using kerberos for other services rather a cobbled together bunch of hacks to bindauth or queryauth off the ldap server.
Me thinks you don't really have any actual experience with or an idea what AD is. AD is NOT NTDOMAINS, even though an AD server is capable of providing backwards compatibility, it is not required and if you're using not using anything older than XP and unix machines it should be turned off.
OpenLDAP is only a partial replacement for ActiveDirectory, and really is the WRONG way to do authentication. MS didn't invent kerberos, but switching to it was one of those 'Okay, you win, we're on the bandwagon with your protocols' moments that you should actually thank them for and look into. Stop hating and educate yourself.
What OpenLDAP wins at, hands down, is of course, cost. But its really silly to say that its more flexible or more reliable (which, btw availability and uptime mean the same thing here).
Do you want to use a bunch of hacks to make your windows machines authenticate, or would you rather use a system that supports everyone natively and completely, Windows AND Unix (including OSX)? Personally I went with AD so I can just do everything natively, with Services for UNIX the thing will even function as a NIS (maybe NIS+, I don't use that part) server if you've got old boxes that you need to pull into the group.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Uh huh. So what's wrong with AD?
At least part of the lock-in from Active Directory is the simple fact that it's a comprehensive system that can be managed by someone with very little experience. You ever tried teaching yourself in a week of on-the-job "how the f**k do I do this" how to run a mid-sized office network? I have. Using Active Directory and with no prior sysadmin experience it was possible, if a little rough. Trying to do the same thing using open source software would probably have taken me six weeks rather than six hours to start getting results. And even then, I'd have spent weeks looking up obscure config problems and installation how-tos.
To someone equally fluent in both OS and MS systems, sure, an open source solution is fine, probably even superior. But the business case for using MS software is undeniable.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.