Directory Service Implementation From Scratch? 149
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?"
Novell.......no seriously (Score:4, Insightful)
A side benefit of Active Directory: (Score:2, Insightful)
Support (Score:3, Insightful)
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.
Re:Just go with AD (Score:5, Insightful)
I've looked into LDAP/Kerberos authentication for my home LAN several times, and basically given up every time. There appears to be a software mix that will do the job, but each piece needs to be configured *just so* in order to work with all of the others. Furthermore, there appear to be a few people out there who really know their stuff, and to them I'll bet this is all easy.
But it appears that those people all work for companies that sell Directory Server services. They're quite willing to be helpful on specific questions, but the overall integration is still not well documented, from what I can see. As near as I can tell, it's like the Bad Old Unix days, when everyone wanted to be The Solution - for a price. I haven't really looked at the RedHat Directory server or similar products, wishing to use the pieces, and wishing for integration documentation.
Why this on a home LAN? For some odd reason, I've tried to run my LAN on industrial-strength software - BIND, ISC DHCP, etc. I'm used to single-sign-in at work, and would really like it at home, given that $HOME is shared over NFSv4. I also usually am too busy doing other things, which is another reason why there's been no progress in years.
Maybe an integrated OSS Directory Server will make it into my house, but there's no way I'm footing the bill it would take to add AD, here.
Re:My choices (Score:3, Insightful)
would it not be possible to configure a single server, that proxies or delegates queries to all the other servers he has set up.
I asked about proxying openLDAP to AD, so I could have users in both, yet query them all just by asking the openLDAP server. If this was possible for multiple delegated servers, then this is the approach I'd take - start with 1+all the old ones, then gradually migrate them into just a few servers.
and yes, I'd probably go for RHDS, Active Directory seems to be one of those products that starts off with just a windows 2008 server, then requires more CALS, then needs a SQL Server licence, and then really expensive backup software, and then needs all printers to be connected to it, and then needs Sharepoint adding to the mix, and then... you get the idea :)
Re:Easy (Score:5, Insightful)
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.
Re:Stick with OpenLDAP ... (Score:4, Insightful)
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.
Re:Twilight Zone? (Score:5, Insightful)
Not really, you can make OpenLDAP have the required schema for windows.
Of course, then you need to add a kerberos server since OpenLDAP doesn't do that.
Then you need to add Samba so you can get the RPC calls that go along with Windows Clients.
Its not that it can't be done, its that its just FAR easier and more reliable to just pay the money for Windows.
Re:Twilight Zone? (Score:4, Insightful)
Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??
But of course - did you not realize that the majority of slashdot readers are microsoft windows users?
Re:Choose AD (Score:2, Insightful)
>>All of hte other solutions require massive hand holding
Your experience of these is what exactly?
Personally I'd use eDirectory. I have 15 year experience of eDir, AD and OpenLDAP. My experience of eDir is that it is worth the cash compared to the rest.
Re:Easy (Score:2, Insightful)
Authenticating against AD is hard? I didn't realize that, I mean, I've been writing apps that authenticate against kerberos since before AD existed, and since those same apps authenticate against ActiveDirectory the exact same way, I must have missed the hard part.
Hard to authenticate against AD, WTF are you talking about? Do you know how it even works? If you're using some retarded fucking bind against ldap for verifying authentication to your apps? If you use the bind to allow the user to authenticate and authorize like a standard user to the ldap server thats one thing, but if you're pulling some bullshit like using an ldap auth to allow them into your webapp which stores everything in a mysql database than you need to be took out and shot. You use kerberos to authenticate and the directory to pull user DIRECTORY type information out of, you know, uid/gid/homedir/name/emailaddress. I highly expect that you don't understand what directories are for and how to properly use them.
So lets even assume you're trying to be an idiot and do an auth using an ldap bind. Its different how? Because an out of the box server expects working SSL for authenticating? Considering openldaps utilities will bind to AD just as well as they will to an openldap server I think you might want to consider switching to a ldap library that doesn't suck ass. Try openldap as a start, it works flawlessly with ActiveDirectory.
Are you bitching about Schema? I hope not, cause if your schema expectations are hard coded into the application than you're only going to work on ONE server type, since no one shares the same default schema for the same attributes.
I'm not really sure what your problem was since you didn't specify, but you have to write a pretty shitty app if you have problems using ActiveDirectory server with it, and its a safe bet your apps will only work against one specific ldap schema if thats the case.
I'm not sure how easy it is with RHDS, but installing AD is rather trivial if you can click 'Next' several times in a row and enter a little info in some text boxes. How well does kerberos work after an out of the box RHDS install? I wasn't aware that it included kerberos support? Kerberos is the PROPER way to authenticate clients you know, not binding to the server with clear text passwords.
Don't get me wrong, I'm not knocking OpenLDAP, or any other implementation. I'm a big fan of OpenLDAP, but if you have a problem connecting and working with the ActiveDirectory LDAP service, you fucked up, likely not it. The only exception to this I can see is that you're doing something rather complex that has specific sorts of support or ADS doesn't implement (standard or otherwise) due to its obscurity. Either way, you're probably having issues working with servers other than AD. LDAP may be a standard, but so is HTML, no one has the perfect implementation.
Stop hating, AD may be from MS, but its actually not shitty. Credit where credit is due.
Re:Easy (Score:4, Insightful)
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.
Microsoft Hostility (Score:3, Insightful)
Uh huh. So what's wrong with AD?
Microsoft seems to design their protocols to be as hostile as possible to 'other' OSs (without being openly anti-competitive). This is good for their business plan but bad for users. A side effect of this is (like another comment in this thread noted), that it's really difficult to expand the system beyond what Microsoft wants you to be able to do.
Given that you're using mostly 'other' operating systems, I think it would be a big mistake to make the bulk of your systems beholden to a hostile mistress.
Re:Start with SQL (Score:3, Insightful)
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.
slapcat > myldaptree.ldiff
Done. You now have an Ldiff file that can be re-imported directly, or parsed quite easily, not sure why Exporting seems difficult?
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.
gssapi/SASL, or if its a horribly broken ap that doesnt do that either, its trivial to write an authorize/authenticate plugin for it, just about everything supports LDAP though, or "AD" which is usually LDAP with the MS schema in mind that can be bent to use a normal LDAP directory instead. Password sync (to get the broken NT4/LANMAN and KRB5 passwords) is as simple as compiling smbk5pwd (for openldap) and making sure the things allowed to change user passwords only use the passwd exop in LDAP, which pam and most other items that can allow that have an option for. Its not a hack, though you do end up with several different hashes of the same thing, as intended, but you can thank MS and MIT for using their own standard for hashing instead of plug-in cryptos, and pushing that for use in certain standards (WPA2 and Kerberos) .
The idea is to put raw user info in SQL, including their clear-text password.
Um, no. All it takes is one rogue admin with the access to "Manage" that database, and suddenly they can pull the CEO's password without anyone noticing, or a misconfigured SQL server running a non-ssl connection leaking that plain-text across the wire. If you are properly implementing a two-factor system (rsa securid or some equiv) this isnt as big a deal, but still... no.
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.
You should do this with any machine regardless. Lock it down so only those that need it can get in, and they only have access to what needs to be worked on... standard policy
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.
Why? You end up with multiple copies of the same data spread across a multitude of disparate systems. OpenLDAP plugs directly into SASL, Kerberos, Samba, Securid, FreeRadius and many other systems that are NOT really directories and therefore should not have the data themselves. Instead they query LDAP for what they need, and LDAP is configured to let them read only what they need, securely (access to attrs=BLAH by ssf=128 dn.exact="cn=someapp,dc=example,dc=com" read). The ssl certs required are trivial to setup, just use CA.pl a few times, create a CA and a few test certs and you quickly get the hang of it. Setting up LDAPS is generally easier than trying to make sure all your SQL connections are secure as well (only start the ldaps service instead of ldap+ldaps, and use ssf=128 for all acls). With that in place, there is absolutely no risk of sending plain-text passwords in the clear over the wire, where your sql implementation seems ready and willing to do exactly that.
-T