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?"
Re:Twilight Zone? (Score:3, Interesting)
AD and OpenLDAP are like first cousins.
big difference is Open LDAP you have to create your schema. with AD Microsoft did the work for you and upgrading is easy. if you first deployed AD with Windows 2000, upgrading to later versions of windows and AD apps is easy. MS ships ldif files with any of their apps that extend AD with new classes and objects that do this automatically. saves you a lot of time.
Start with SQL (Score:3, Interesting)
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 [usit.uio.no]. 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).
Re:Just go with AD (Score:1, Interesting)
The main pitfall is to be careful about the MS licensing rules for AD. You essentially need a CAL for EVERY USER in your directory, or some of the crazy very expensive CALs. This is no big deal if you already have CALs, but it would be insane to use AD for something where the users accessing the server are not employees of your company. The licensing costs would become crazy when compared with something open source.
Re:Easy (Score:1, Interesting)
The problem with AD is lock-in. Once you deploy AD, you will never be able to switch to another directory product, as Microsoft software dependency creep will ensure that no other product can operate as a drop-in replacement.
If you only have a few Windows machines, use a standardized solution and live with loss of MS-specific functionality. If you deploy AD, you'll soon find yourself locked in, and the investment in MS-only technology will only keep growing.
Win2k3 R2 (Score:2, Interesting)
Windows 2003 R2 has (virutally) the same IDMU as Win 2008.
I have implemented such a mixed environment, with one problem. As I pointed more and more liunx boxes at the AD running IDMU, the number of internal connections from the AD server to it's own LDAP port increased until they were all tied up. It got so the AD server could not even read its own global policies.
I had to implement a Linux NIS slave and point all of my Linux boxes at it instead of the AD server.
Re:Easy (Score:3, Interesting)
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.
Re:Start with SQL (Score:2, Interesting)
+1 to this. Extremely flexible.
We do all of this, except for plain text passwords in tables.
We highly recommend encrypting, or completely eliminating, plaintext passwords. Instead, create and store the required hashes (ssha, etc.) for various bits and pieces when you create a user, or the user changes their password.
Re:Easy (Score:4, Interesting)
Re:FreeIPA, Apple OD, Gosa2, Novell eDirectory, FD (Score:2, Interesting)
Yikes, I'm replying to an AC.
Mac OS X and Server are now virtualizable in recent Vmware Fusion and Parallels installs (at least). Although there were technical and legal challenges to parallelizing OS X installs, these have apparently been surmounted.
Now I just need more RAM.
Re:Novell.......no seriously (Score:3, Interesting)
and +1 for eDir from me as well.
I have a blackbelt in directory management (AD, eDir and OpenLDAP)
eDirectory has a nasty habit of being virtually unkillable and is by far and away the most flexible. With 8.8 you can run multiple trees on a host (in MS speak think of multiple domains on a single DC) No waste of a system to just do DC duties for one bit of your system.
If you want the most powerfull directory option then use eDir as your metadirectory and then use IDM to populate other directories and applications as needed (eg MySQL, Oracle, text files, Exchange, GroupWise, NIS, etc ad nauseam)
IDM is phenomenally powerfull, the iManager plugin is as a shining example of how to do a webapp or use Designer, an Eclipse based thingie is great too and has a huge feature set -even churns out your documentation.
AD doesn't really cut it as a LDAP system - compare the rich schema of eDir to AD for example, also you can put replicas where ever you want (it is not DNS federated unless you want it to be)
Steep learning curve but really well worth it.
Grab an eval of Open Enterprise Server 2 (SuSE based), try it out properly, wedge in Identity Manager and you'll be spending cash on the product.
Directory services (Score:2, Interesting)
I have a pretty long history of this, and I have set up a couple of major implementations (1,000,000+ objects) so I'm putting in my 2cents.
I started with Novell's NDS in 1993 (yup, I was a beta tester) and so I am pretty oriented towards that product. Other Directory Service products I have managed include AD and eTrust. I am still most impressed with Novell's product, and for good reasons. AD is really an LDAP interface into a distributed registry. It is not really a full X.500 directory, and it weaknesses show when it comes time to upgrade or migrate. eTrust is built on the old Ingres database (Alan Lloyd couldn't get a free copy of Oracle) and there were issues with it's replication and failover modes when I ran it. Once burned, twice shy. The most reliable, in terms of not getting up at 2 AM, was eDirectory, and I still respect Novell's attitude towards Quality.
The performance of most DS products is pretty equal these days, a test I read last year had a 4-core Opteron doing 60,000+ searches per second. That's plenty, divide the number of leaf objects by that number to find the number of processors you will need. More importantly is how you build your tree, and that is NOT a minor effort. Number one, you will need replicas, at least three of each partition in the tree. Number two, enough bandwidth to make sure that replication and synchronization is not impeded. Number three, you WILL have a number of arguments from the management team (if they are one) at the normal number of communication paths within the team, that is N! if they all fight separately, N!/P! if they gang up. These arguments will be centered on who has what access, up to why the tree doesn't place them at the top (hint: follow the organization chart. Get the CEO to tell HR to give it to you.)
After that, it's really a matter of studying the available literature. Get a copy of the X.500 documentation to understand the standards for update and replication, and after that, try a couple of test implementations in a little three server lab. You can probably do that on a couple of one-lung PCs to get a feel for what the tree will look like and how to manage it. I haven't had a test lab in my house in a couple of years, but the last one was an Athlon laptop with OES 1 on it. Get a copy of NDS Basics from Novell Press and bone up. The other book useful to this effort is Open Enterprise Server Administrator's Handbook also from Novell Press. Grab an eval copy of OES and practice. When you go live, the price of the eDirectory component itself is worth the cost of OES.
davel
Re:Easy (Score:3, Interesting)