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?"
Easy (Score:3, Informative)
Use AD.
Even though folks will fuss and whine about AD being not pure LDAP, for all intents and purposes it is, and we've got lots of Linux and other *nix boxes using it for authentication. And remember, you can always extend AD for your custom applications easy enough. It's simple enough that MCSEs can run it.
Just go with AD (Score:4, Informative)
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
Re:Easy (Score:4, Informative)
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.
My choices (Score:4, Informative)
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.
Re:Easy (Score:4, Informative)
It's hard to argue against AD - even in your situation where the Microsoft boxes comprise the minority of systems.
AD (Score:2, Informative)
Microsoft has really done well with developing AD.
It's just honestly the best product out there currently.
Re:Novell.......no seriously (Score:3, Informative)
+1 On Novell's IDM, it is *hands downs* the best Directory Services product out there.
Though if you don't want to spend the bucks for it (it's worth it, seriously), I would recommend just using AD.
As others have said, AD just sort of works, and everything can interact with it.
I'd personally recommend it over SAMBA/OpenLDAP, as I've beat my head against the wall one too many times trying to use SAMBA/OpenLDAP as a Windows Domain. It's just not worth the time or frustration.
Re:My choices (Score:2, Informative)
SunDS, FDS and Novell eDirectory are all based on Netscapes DS,
FDS and RHDS are the direct descendants of Netscape DS, which was purchased by AOL and then by Redhat who then Open Sourced it.
Re:Easy (Score:3, Informative)
While Unix boxes can authenticate to an Active Directory domain through the use of Samba and derivatives, the advantage of these services is that they can extend the LDAP schema with NIS attributes to provide native NIS authentication, and also, extend SMB sharing with NFS support to provide native NFS sharing. In both cases, the NIS/NFS support is fully integrated with the native Windows support, and data shared between the two; that is, Windows AD objects can be immediately used with NIS and NFS, they co-exist. I've personally found this a huge convenience as most Unix/Linux distros can authenticate to the domain out-of-the-box and with an absolute minimal amount of configuration, often during the initial installation without even having to dive into configuration files to get the basics done. With some extra work, you can also enable password synchronization in the Unix -> NIS direction and/or the Windows -> NIS direction through the use of a (closed-source) PAM module (the reason for this being that as far as the Unix boxes are concerned they are using NIS, but behind the scenes, it is fundamentally AD with a NIS front-end, and the intricacies of password management and the updating of are very different.)
As admittedly distasteful as it is that Microsoft has an inherent competitive advantage here in that much of their implementation is proprietary and their competitors is not, leaving them free to support NIS/NFS but not necessarily the other way around, my experience is that they have done their implementation quite well. Word to the wise: I've had a FAR better experience with IDMU on Server 2008 than SFU for Server 2003. The former requires a separate download for SFU while the latter has IDMU included as part of the OS and can be installed at any time as an optional component alongside AD/SMB, either at initial installation of those components or as a future addition post-installation. The result is a tighter coupling of the respective services: it feels like communication between the Unix support division and the Windows tech division was far better for Server 2008; I had to spend many hours getting NIS/NFS to work on 2003, but had it up and working perfectly in under an hour on 2008. That being said, both can be made to work fine and will get the job done well, my experience is purely limited to ease of setup and initial impression on the polish and integration of each, functionality wise, they are both almost identical.
Both are free of charge, provided of course you have a Windows licence, with IDMU effectively being a renamed and improved SFU.
Hear me out (Score:5, Informative)
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
Re:Twilight Zone? (Score:3, Informative)
FreeIPA, Apple OD, Gosa2, Novell eDirectory, FDS (Score:2, Informative)
I am with this task as well.
Since we need to support Kerberos, I had some difficulties to install OpenLDAP and manage the Kerberos and integrate with Samba and AFP.
Our servers are 80% Linux and 20% Windows,.
Our clients are 90% Mac, 9% Windows and 1% Linuxes
I have messing with the follwoing solutions without much sucesse. They are all good, but they are NOT READY yet. Maybe Novell eDirectory, but I think it is too big and kind of expensive.
I really don't like Microsoft, so we are avoiding AD and avoiding supporting M$ with our money.
So, we tried:
- Fedora Directory Server
- OpenLDAP + Kerberos (doesn't have a good admin interface)
- Gosa
- FreeIPA
But, we will keep investigating.
for now, our BEST OPTION and the easiest is:
Apple OD (Open Directory).
It integrate very well with Windows, Apple, Linux and has Kerberois and a great Admin UI
Ou ONLY problem with Apple is that we can't VMWare... so, that's the only issue for us!!!
In about 6 months we will try again the followings:
- FreeIPA
- Gosa2
- Fedora Directory Server
Re:Easy (Score:3, Informative)
I'd just like to point out that while you CAN use NIS with SFU and the like, unless its an old machine without Kerberos support and without NSS support, you really would want to use kerberos and nss_ldap to connect to an AD server with SFU installed. If you have old machines, sure, shoe horn them in with NIS, thats what its there for, but you should avoid it if possible, NIS is horribly insecure. The plus side of using kerberos is that no syncronization is required, AD will sync its kerberos server passwords on its own and you're not left worrying about things getting out of sync.
A better combination on your unix machines is pam_krb5 and nss_ldap if your OS supports PAM and NSS. At the bare minimum, pam_krb5 is the best way to go so your AD servers do the authentication directly and can fully apply group policy to handle brute force prevention and password length/complexity requirements.
I am interested to know what problems you have with SFU that IDMU didn't have. My only complaint with SFU so far is the way it assigns new UID/GIDs by default, seems to take highest + 1, which sucks since once I imported my unix accounts to AD, I now have a uid and gid of 65535, and the next one it wants to assign is 65536. Wish I could figure out a way to make it say 'find the next available one in this range'.
Would mind you elaborating on what you like better about IDMU for me?
Re:My choices (Score:3, Informative)
SunDS, FDS and Novell eDirectory are all based on Netscapes DS,
Uh, eDirectory is the current name for NDS, which came out with Netware 4 in 1993, before Netscape was even a company.
MDS - Mandriva Directory Server (Score:2, Informative)
Re:Just go with AD (Score:3, Informative)
The licensing for Windows Server doesn't necessarily have anything to do with the size of the directory.
With Server 2008, you have a matrix of options. You can choose whether you want to count licenses by computers or users by the type of CAL you buy (Device or User). Then, you can choose whether you want to license the number of simultaneous connections to a single server (per-server) or by the number of discrete users or devices that have accessed any server (per-user or per-device). Clearly, if you only have one server and it's only being used for authentication, per-server licensing with device CALs makes sense. You only need to purchase sufficient CALs to cover number of computers that will simultaneously authenticate. Another option would be to go with user CALs, but it's probably easier to calculate how many computers will be simultaneously authenticating against or querying the directory. Once you get multiple servers, however, per-server licensing quickly gets expensive. For example, if you have three shifts of 10 users and go with 10 device CALs, per-server licensing will require 30 CALs if you have 3 servers. In per-device mode, however, it only requires 10 CALs. So, in a large deployment with multiple servers, you'll typically go with per-device licensing with device CALs (if users share computers) or per-user licensing with user CALs (if users use multiple computers or all have their own computers). This is because per-device/per-user mode doesn't license the servers; the CAL is good for connecting to any server in your network. In practice, only in the case of User CALs with per-user licensing do you need a number of CALs equal to the number of active users in your directory. You still don't necessarily need one license per user, however, as you can assign CALs away from deactivated users, move CALs from users on leave to temporary users, and use one CAL for a single named user who happens to use multiple accounts.
Check out Microsoft's Windows Server 2008 Licensing FAQ [microsoft.com] and Microsoft's Windows Server 2008 CAL overview page [microsoft.com].
Re:My choices (Score:1, Informative)
use freeipa! it's the community version of redhat enterprise ipa (identity, policy, audit) and it offers a very complete
solution for your needs. and it's open... from the site:
FreeIPA (so far) is an integrated solution combining
* Linux (currently Fedora)
* Fedora Directory Server
* MIT Kerberos
* NTP
* DNS
* Web and commandline provisioning and administration tools