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?"
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~
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
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.
The living have better things to do than to continue hating the dead.
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
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
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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?
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.