Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Directory Service Implementation From Scratch?

timothy posted more than 5 years ago | from the just-have-everyone-shout dept.

Networking 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?"

Sorry! There are no comments related to the filter you selected.

Step 1. (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28213703)

Scrap the Windows boxes.

Easy (2, Informative)

ChadAmberg (460099) | more than 5 years ago | (#28213723)

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.

Re:Easy (3, Informative)

fahrvergnugen (228539) | more than 5 years ago | (#28213779)

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.

Re:Easy (3, Informative)

GPLDAN (732269) | more than 5 years ago | (#28213941)

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.

Re:Easy (2, Informative)

Ralish (775196) | more than 5 years ago | (#28214423)

It's worth noting that Microsoft also has Services for Unix [] (applicable for Windows 2000 through Windows Server 2003) and Identity Management for Unix [] (applicable for Windows Vista through Windows Server 2008).

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.

Win2k3 R2 (2, Interesting)

Lurching (1242238) | more than 5 years ago | (#28214599)

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 (2, Informative)

BitZtream (692029) | more than 5 years ago | (#28215071)

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:Easy (1)

The Yuckinator (898499) | more than 5 years ago | (#28213951)

If you do decide to go with an Active Directory, I found that using Winbind [] was an extremely easy way to have my Samba server authenticate my users from the AD. It was up and running in no time and it's been rock solid ever since.

One thing to remember is to use Group Sharing [] when setting folder permissions on the *nix box. That was an easy one to overlook until users started asking why they couldn't open each others files!

Re:Easy (4, Insightful)

Savage-Rabbit (308260) | more than 5 years ago | (#28214343)

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:Easy (1)

wasabii (693236) | more than 5 years ago | (#28216045)

Wait. Problems like what? It supports LDAP and Kerberos. You can query it just fine.

Re:Easy (2, Funny)

Rysc (136391) | more than 5 years ago | (#28216649)

You can LDAP query AD like my moped can race in the Indy 500.

Re:Easy (3, Interesting)

wasabii (693236) | more than 5 years ago | (#28217151)

Uh huh. So what's wrong with AD?

Re:Easy (1)

Blakey Rat (99501) | more than 5 years ago | (#28217095)

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.

Unless you're a Windows developer, in which case you can just drag&drop the .net sign-on control into your project and you're done in 5 seconds.

Re:Easy (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28217673)

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 (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28214595)

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.

Re:Easy (3, Interesting)

ogrius (186951) | more than 5 years ago | (#28214817)

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.

NOT AD because of hidden complexity. (1)

xzvf (924443) | more than 5 years ago | (#28214931)

The Linux/Unix world has done a great job making AD work in their world. Just like we can read mail off an Exchange server and use Sharepoint. They are easy on day one, but like most products from MS, there are a million hidden costs as you grow and expand. If you start with a standards based LDAP directory server like 389-ds (Fedora-ds new name) you can grow into RHDS if you need support. It is cheaper than AD as your environment grows plus if you decide to migrate to another DS, it is reasonably easy because it implemented an open standard. Don't fall into the trap like so many did with Exchange and so many are with Sharepoint.

David Carradine Has Died, He Was Delicious (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28213733)

Apparently Carradine was eaten by wolves on the Connecticut turn-pike. All reports say he was delicious. Words cannot describe how sad this is. Carradine's acting was not exactly top-notch...even for the hey-day of 60's Kung-fu pop culture. His colour (a colour option picked up from an earlier version) clashes with the grey of any other living actors; that can be changed though. The black side of his acting in Kill Bill (Vol. 1 & 2) is overbearing and doesn't meld with his earlier works. His *cough* apparent suicide *cough* stands out like a sore thumb. I somehow feel like his death resembles the chrome looks like a webpage, rather than someone who won an award in 2005 for lifetime acting achievements and for browsing web pages. I cannot believe someone who created the Firefox icon could star in something so hideous and inappropriate, especially when David Carradine's marketshare is bad enough already. I could not bear to look at this all day, every day, it would drive me mad.

A suicidal has-been Kung-fu actor should be transparent, a thin veneer between me and the web page. Not a clown honking his horn in my face. I went into preferences and changed to the Mac "native" theme and no particular colour, mildly improved, but still the black is overpowering, the new-tab button is the wrong colour, and the side pane has a tinge of blue that doesnt work well with the OS X grey. The tab touching the title bar also just looks poor and conflicting. This is the same bullshit I had to put up with when Dana Plato finally offed herself. It's goudy, non-native, clashes with the websites you view, and generally gets in the way, the toolkit underneath still rears it's ugly head in how the app works, and the general layout of the widgets. The dialogues throughout the app crap all over the spacing guides in the HIG. Every inch of this app is annoying and grates on me. I'm not an interface elitist or an apple fanboy, but I can't use software that gets on my nerves and Opera and Vista occupy the top two slots for that. The browser is eclectic, with too many preferences, too complicated preferences, too many customisation options. Features not everybody needs, or wants.

AD -- de facto standard (0)

Anonymous Coward | more than 5 years ago | (#28213741)

Depending on your company's skillset, having AD as your core directory may be your best choice. The advantage is that its one point of access, one set of usernames and passwords for users, and so on.

AD in general also has a lot of management tools and knowledge available.

Of course, this isn't to say that OpenLDAP or other directory solutions are bad. Its just that in general, most vendors will bend over backwards to give Active Directory support for their products.

First Post :-) (-1, Flamebait)

lavacano201014 (999580) | more than 5 years ago | (#28213751)

Anyway, I would recommend using Linux for the actual power behind your network, and maybe use Windows as interface workstations (because Windows sucks for anything needing stability). Think of it this way: You're using Windows as the control panel for a Linux-based supercomputer.

Re:First Post :-) (0)

Anonymous Coward | more than 5 years ago | (#28214313)

you have zero enterprise experience

shot in the dark (0)

Anonymous Coward | more than 5 years ago | (#28213753)

i took a class once where we used LDAP (Lightweight Directory Access Protocol) and then used Ubuntu and VMware to setup multiple Ubuntu/Win2k/WinServer2k3 all with roaming profiles and active directories.

it worked great and was a really fun class also.

Just go with AD (4, Informative)

anom (809433) | more than 5 years ago | (#28213757)

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:Just go with AD (1)

Seranfall (680430) | more than 5 years ago | (#28213903)

I completely agree. If your a full linux shop and money for server software is an issue than OpenLDAP or something similar may be a good solution. However, with windows clients in the mix you should definitely stick with AD. Just about anything will interface with AD in some manner. Also there is far far greater support for AD then your going to find with any of the other directory services out there right now.

Twilight Zone? (5, Funny)

cowdung (702933) | more than 5 years ago | (#28213995)

Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??

Re:Twilight Zone? (2, Interesting)

alen (225700) | more than 5 years ago | (#28214323)

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.

Re:Twilight Zone? (2, Informative)

afidel (530433) | more than 5 years ago | (#28214775)

AD also does multi-master replication out of the box and it's been scale tested to the very largest of implementations.

Re:Twilight Zone? (0)

Anonymous Coward | more than 5 years ago | (#28214387)

No, they are saying MS Windows only works the MS way, and it's easier for Linux to adapt to it, than the other way around.

Re:Twilight Zone? (4, Insightful)

BitZtream (692029) | more than 5 years ago | (#28214983)

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? (3, Insightful)

sloanster (213766) | more than 5 years ago | (#28215149)

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:Twilight Zone? (1)

jdunham (446838) | more than 5 years ago | (#28215731)

but what about the majority of slashdot _writers_?

Re:Twilight Zone? (2, Funny)

serutan (259622) | more than 5 years ago | (#28215869)

Ohhhh Barnacles! It's Backwards Day!

Re:Twilight Zone? (1)

Zumbs (1241138) | more than 5 years ago | (#28215911)

Just this day, a spaceship landed and from it walked an army of Bill Gates-drones. Each of them were a part of a large, but simple plan: Find a computer, hack a slashdot account, and good-mouth everything MS. However, some of them adabted to this brave new world, and wrote their praise with reluctance to veil their plans from the *nix'ers ... but they are out there, and if you get in their way

Re:Just go with AD (5, Insightful)

dpilot (134227) | more than 5 years ago | (#28214249)

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:Just go with AD (1)

BitHive (578094) | more than 5 years ago | (#28214737)

Try using Debian. I followed the documentation I could find via Google and had Kerberos/LDAP working in an afternoon.

Re:Just go with AD (1)

anom (809433) | more than 5 years ago | (#28215915)

What linux distro do you use?

Try Likewise Open. I know it works for more, but for ubuntu, it's this easy: []

It's seriously 2 commands to join it to a windows domain.

Here's what I'm trying at home this summer (1)

adriccom (44869) | more than 5 years ago | (#28217065)


I have felt your pain. I just got my used copy of Distributed Services with OpenAFS: for Enterprise and Education [] and it looks pretty awesome so far.

It's a textbook of explanations wrapped around a whole bunch of script(1) captures of them setting up ntp,dns,k5,ldap,openafs,samba, etc on Debian with Windows, Mac, Ubuntu clients. You can find the table of contents and an excerpt at the book's site: []

hth and Good Luck!


Re:Just go with AD (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28214393)

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:Just go with AD (1)

222 (551054) | more than 5 years ago | (#28214475)

This claim smells funny to me. Can you provide any reference to per LDAP user CAL licensing?

Re:Just go with AD (1)

BitZtream (692029) | more than 5 years ago | (#28214951)

MS is pretty clear, any connection to a Windows server requires a CAL, period.

Re:Just go with AD (1)

BitZtream (692029) | more than 5 years ago | (#28215111)

Let me restate. Any client that makes a connection to a Windows server requires a CAL to access the server. Its not per connection in most cases (is in some though!), but if you're connecting to a Windows server, you need a CAL to account for it somewhere.

Windows server web edition has some allowances to keep the CAL count lower, but since it doesn't run AD its not part of the discussion here.

Brokenware (1)

gd2shoe (747932) | more than 5 years ago | (#28215391)

It's just another dimension of Microsoft's brokenware mentality. They design a product, then they break it before selling it to you so they can sell you an upgrade to a working version. CALs are the server equivalent to the PC/workstation scenario. They don't provide different versions of Windows with different capabilities. They do provide different versions of windows intentionally broken to different degrees. They're creating an artificial feature set that they can up-sell later.

It's diabolical, really, but it's hard to blame them. They are a business very near (or at) monopoly status trying to eke every last penny out of our pockets. What more should we expect?

Re:Just go with AD (2, Informative)

FreelanceWizard (889712) | more than 5 years ago | (#28217453)

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 [] and Microsoft's Windows Server 2008 CAL overview page [] .

Stick with OpenLDAP ... (-1)

Anonymous Coward | more than 5 years ago | (#28213777)

I have designed and implemented the infrastructure for multiple startup environments over the past 10 years and while the trend seems to be to use Active Directory, my last two startups were made vastly easier by not using AD. LDAP provides you with a great deal more control over the schema and capabilities needed for open source systems like Linux login, Wiki and other web based application login. Openldap also gives you a great many ways of easily managing users via a multitude of applications whether host based or web based. Most importantly, it will save you a LOT of money in the end and provide for far greater flexibility, availability and uptime. And making LDAP a domain controller for your windows hosts is easily accomplished by using Samba integration. Trust me, go LDAP ...

Re:Stick with OpenLDAP ... (0)

Anonymous Coward | more than 5 years ago | (#28214219)

Umm... AD uses LDAP....

Re:Stick with OpenLDAP ... (3, Insightful)

BitZtream (692029) | more than 5 years ago | (#28214935)

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. seriously (4, Insightful)

perotbot (632237) | more than 5 years ago | (#28213799)

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 seriously (3, Informative)

Anonymous Coward | more than 5 years ago | (#28214075)

+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. seriously (3, Interesting)

JSG (82708) | more than 5 years ago | (#28217407)

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.

Some tools aren't up to the challenge.... (-1)

SomeoneGotMyNick (200685) | more than 5 years ago | (#28213867)

Gee, I hope they don't try and implement any kind of directory service implementation from Scratch []

quit (0, Flamebait)

docbrody (1159409) | more than 5 years ago | (#28213879)

quit your job and let someone else deal with it

My choices (3, Informative)

xaoslaad (590527) | more than 5 years ago | (#28213913)

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.

Re:My choices (2, Insightful)

gbjbaanb (229885) | more than 5 years ago | (#28214287)

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:My choices (1, Informative)

IMightB (533307) | more than 5 years ago | (#28214335)

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:My choices (2, Informative)

Clover_Kicker (20761) | more than 5 years ago | (#28216133)

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.

Re:My choices (1)

JSG (82708) | more than 5 years ago | (#28217445)

eDirectory AKA NDS was based on X400 as I recall. I remember using it in 1993, before Netscape was formed - "Netscape stock traded between 1995 and 2003" - Wikipedia

Re:My choices (1)

d235j (1434583) | more than 5 years ago | (#28214341)

Yes, I agree that RHDS/FDS aka. 389 directory server ( is probably the way to go.

Re:My choices (1)

JSG (82708) | more than 5 years ago | (#28217423)

>>4.) Novell eDirectory (personally my least favorite)

Why? Have you actually used it. How does it compare to your other options?

A side benefit of Active Directory: (2, Insightful)

lazyforker (957705) | more than 5 years ago | (#28213925)

Almost any LDAP Directory service will work for your directory needs. I think the real question should be "is the cost of the Windows Server 2008+CALs outweighed by the extra features I get?". If you're considering Active Directory then you should know that as a bare minimum you will need two Windows Servers. But you will get GPOs, centralized security (domain users and groups) etc. Do you need all that? If you're a startup then spend money on getting your business up and running, not on keeping Ballmer's office stocked with chairs. So stick with any of the worthy Linux-based. FOSS solutions - I have limited experience with them so I'll leave others to comment on which is "best". (Disclaimer: I deployed AD to my company - they're a 10,000 employee global company that was running Windows NT everywhere when I joined.)

AD (2, Informative)

Malenx (1453851) | more than 5 years ago | (#28214011)

Microsoft has really done well with developing AD.

It's just honestly the best product out there currently.

Re:AD (0, Flamebait)

DaveV1.0 (203135) | more than 5 years ago | (#28214135)

That sound you just heard were a thousand fanboys lighting their flamethrowers.

Re:AD (1)

JSG (82708) | more than 5 years ago | (#28217459)

Please describe your experiences with any other directory to reinforce your expertise.

389-ds (1)

aichainz (523314) | more than 5 years ago | (#28214085)

aka fedora-ds has been very flexible and is able to provide SSO for many applications, from apps that support pam, to tacacs, apache, cvs etc. admittedly i havent gone so far as to auth a windows pc against it, but that doesnt mean it's necessarily a good idea to use AD and have linux auth against that. multi-master replication in 389 works great, and we even have a 3rd master who is on the other side of a wan-link.

Support (3, Insightful)

Cyner (267154) | more than 5 years ago | (#28214161)

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:Support (1)

codepunk (167897) | more than 5 years ago | (#28216861)

No Linux support? What do you live in the middle of the Sudan?

I live in one dinky little town and one phone call I would have a Linux Engineer on site
in under 60 minutes.

Re:Support (1)

Majestix (41486) | more than 5 years ago | (#28217341)

Find someone to come in and tell you,

"Ah, we can fix this. We'll just replace it with an MS AD server. Oh wait, you want to keep this? Why ever for?"

Those are a dime a dozen. Well ok, considerably more than a dime. But they make themselves sound soooo wonderful...

Try FreeIPA (1)

fwittekind (186517) | more than 5 years ago | (#28214263)

AD is what MS got very very very close to "Right" (1)

IMightB (533307) | more than 5 years ago | (#28214305)

Ad is very nice, we use it for Auth in a mixed env as well. I work in QA, the way that I've actually got mine setup is ADS run by Corp, FDS run by QA. FDS has Pass Though Authentication turned on.

You may want to checkout Fedora Directory Server and FreeIPA combo for linux/unix solutions

Start with SQL (3, Interesting)

unified_diff (1139065) | more than 5 years ago | (#28214365)

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, [] . 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 wiki seems to be down at the moment, unfortunately).

Re:Start with SQL (1, Interesting)

Tildedot (137711) | more than 5 years ago | (#28215171)

+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.

Choose AD (0)

wasabii (693236) | more than 5 years ago | (#28214461)

I'd use AD for everything. It works out of the box. Isn't that expensive. Does replication properly. Tracks site locality. Is expandable instantly to huge networks. Has Kerberos set up perfectly by default. There's really no downside to using it in my experience. All of hte other solutions require massive hand holding. Linux can auth against it either as a normal LDAP directory, or using Winbind. Winbind recommended.

Re:Choose AD (2, Insightful)

JSG (82708) | more than 5 years ago | (#28217477)

>>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.

emoticons (1)

AltImage (626465) | more than 5 years ago | (#28214571)

Is it really necessary to have 6 smilie faces in the article? I wonder how many also show up in the Drizzle source. I also find it interesting that the author opts for the less common "no-nose smilie face" :)

Re:emoticons (1)

AltImage (626465) | more than 5 years ago | (#28214603)

oops...wrong thread. Should have been for the MySQL/Drizzel article.

Re:emoticons (1)

caluml (551744) | more than 5 years ago | (#28215497)

I've honestly never understood how this happens? How do you accidentally post in the wrong discussion?

Re:emoticons (1)

AltImage (626465) | more than 5 years ago | (#28215643)

tabs...the answer is tabs.

try OS X server (0)

Anonymous Coward | more than 5 years ago | (#28214623)

Depending on your size you might want to consider Apple's OS X server product.

I am in the middle of building a new infrastructure based on open directory which is apple's version of LDAP. so far I have the mac, linux and windows boxes authenticating against it, as well as postsql, drupal,

still working on fully setting it up, but so far so good.

It's replacing:
netscape old LDAP
Sun's NIS+
Redhat NIS
and Active directory

so in the long run it should be better than what we have now

Novel Zen (0)

Anonymous Coward | more than 5 years ago | (#28214627)

Novel sells Zen, which does an LDAP domain like AD, hosted from Linux. Yes there might be incompatibilities with Windows, but Windows typically has incompatibilities with Windows too. Novel's stuff will probably support your UNIX systems better. The admins I've met running Novel seemed happy with it, especially with the security features and invulnerability (low incidence) to typical internet malware.

Also, you are missing the point of LDAP and AD. LDAP directory services can TALK TO EACH OTHER. It's based on standards. You can have a Linux-based LDAP forest talk to a Windows-based AD forest. It will work. There may/will be problems, but consider this:

most of the time, your linux servers will deal with the linux LDAP server
most of the time, your windows servers will deal with the windows domain

file & data transfers can also be done a variety of ways that don't involve directory services. SSH with private key auth. The HTTP your using now is another.

If system administration is becoming a burden, you just need to automate more. Write more scripts. Work as a team to automate most tasks until you have less and less to do. A perfect, orderly domain doesn't exist and may cause more problems than it solves. Cron/scheduler that downloads new/updated scripts from a central server can solve a lot of these issues without all the overhead and licensing, especially if you have special vendor application that can't run in a domain (the vendor won't support it).

Hear me out (5, Informative)

BitZtream (692029) | more than 5 years ago | (#28214727)

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 before the client considers them 'committed', which can take a while in when there are lots of other edits going on elsewhere.

On that note however, you won't find a Windows server on my network that isn't doing AD or print serving. All our other services run on FreeBSD boxes :) I would expec

Use AD (0)

Anonymous Coward | more than 5 years ago | (#28214753)

There are times to show off to the world how much of a geek you really are, but this is not one of them - why reinvent the wheel? Just use AD. It works.

FreeIPA, Apple OD, Gosa2, Novell eDirectory, FDS (2, Informative)

Anonymous Coward | more than 5 years ago | (#28214801)

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:FreeIPA, Apple OD, Gosa2, Novell eDirectory, FD (1)

nexex (256614) | more than 5 years ago | (#28215937)

There is also:
Apache Directory []
Sun OpenDS []

Re:FreeIPA, Apple OD, Gosa2, Novell eDirectory, FD (2, Interesting)

adriccom (44869) | more than 5 years ago | (#28217161)

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.

The /. M$ effect (0)

Anonymous Coward | more than 5 years ago | (#28214827)

Everyone hating on MS but loving AD. Sweet sweet irony.

Re:The /. M$ effect (1)

IMightB (533307) | more than 5 years ago | (#28215701)

tastes like crow!

Seriously though, there are many people that read slashdot that actually have used most if not all of these different Directory solutions. They need to use them because they are professionals that help run companies, Directory Servers, as a class, are the only way to sanely manage anywhere from a couple dozen users and machines to hundreds or thousands of users and machines.

It doesn't matter whether it's OSS vs Closed Source or Microsoft vs Everyone Else, Once you have REAL experience with more than one Directory server, you will realize that AD is truly the "Best of Breed" of Directory Servers.

Re:The /. M$ effect (1)

IMightB (533307) | more than 5 years ago | (#28215747)

Bad form I know...

All that being said there are GOOD implementations of AD and there are BAD implementations of AD. LDAP/Directory Servers in general are complicated, it takes quite some time and experience to know how do a Good implementation with one. Same as everything else.

Re:The /. M$ effect (0)

Anonymous Coward | more than 5 years ago | (#28217003)

AD is only "Best of Breed" if you don't know NDS and if you are 100% willing to commit to single-sourcing everything from Microsoft forever.

If you want to use kerberos... (0)

profplump (309017) | more than 5 years ago | (#28215047)

If you want to use kerberos you'll need to avoid Active Directory -- it does not play well with others. AD is a decent directory server, but the "kerberos" implementation muxes authorization and authentication and will not work with external kerberos servers at all.

On the other hand, AD does play very well with Windows desktops -- it is the only way to use certain administrative functions in Windows -- and is perfectly suitable for password-based authentication against the directory sever from any platform. So if you don't need kerberos AD is probably fine, though I'm not sure it's any better than RHDS or eDirectory or the like if all you're doing is centralized, password-based authentication.

Re:If you want to use kerberos... (1)

wasabii (693236) | more than 5 years ago | (#28215383)

Plays fine. The problem of the PAC means Linux Kerberos servers cannot serve Windows clients. Nothing to do with the reverse.

Single sign on software (0)

Anonymous Coward | more than 5 years ago | (#28215951)

Or there's something like symplified [] , they have a single sign on software that's made specifically for this sort of purpose. It's not F/OSS though, so keep that in mind too, but I looked into it recently and it seemed pretty nice.

Nah! (1)

alexborges (313924) | more than 5 years ago | (#28216247)

" it seems like it may be easiest to just use Active Directory for everything. Are there any pitfalls with this approach? "

No no no.

Go do samba+ldap and THEN you have BOTH windows and a linux directory. You might hear something about "group policies" and other crap, thats treated in-depth in the samba howto: you CAN deploy policies with a smb pdc to winxp-2k boxes without too much problem (youll need a cheap version of win2k and ads with minal cals to get the admin gui for that, but in no way should you pay CALs for your linux boxes: that is plain stupid).

No AD for me thanks. (1)

jvillain (546827) | more than 5 years ago | (#28217059)

In a high availability situation I would never trust AD to work with my nix machines. All it takes is Microsoft to make one change in the code and an admin to apply a patch to the AD servers and your nix machines can all be sitting their twittling their thumbs. Then you are stuck hoping that Microsoft wants to fix the problem. Mean while management will be sitting their blaming your nix machines and thinking it is better to go all windows. If your shop wants to go all windows do it based on a buisness requirement not based on getting bent by microsoft yet again.

Either Linux or AD (0)

Anonymous Coward | more than 5 years ago | (#28217067)

If you're a Linux shop then either stay away from AD or throw Linux away. AD is far from the best directory server, the value in AD comes in the non-directory aspects tying it into other Microsoft products. If you're a Linux shop, then deploy a good directory service (e.g. FDS, OpenIPA, eDirectory) an tie the handful of Windows boxes into that infrastructure.

MDS - Mandriva Directory Server (2, Informative)

Player Parker (1440239) | more than 5 years ago | (#28217171)

I find myself in the same situation and am considering either MDS or FDS, which is now 389 Directory Server btw, to address this need. My goal is to stay away from Microsoft's AD primarily because my boss looks for $100 solutions for $10 (or less). I won't banter on here about the merits of what MDS will and will not do, but I will say it's a very good package, well documented and certainly worth consideration. I setup a VMware server which I'd be happy to ZIP up and post on our company's sftp site for you to download and check out if you so wish. Look me up and I'll hook you up, no worries...

openldap (0)

Anonymous Coward | more than 5 years ago | (#28217187)

seriously... this is a freakin' M$ love-in...
since when has "simple", "gui" and "proprietory" been pre-requisits on slashdot?
AD is far from the best tool for the job for hetrogenous computing environments. it has limitations in the number of entities it can hold, it's buggier than a swamp and the granularity of security imnsfho, crap. if you decide to get on the AD train, don't forget to purchase ADAM as the recomended and part-of-the-solution-set to get anything to play nice that isn't winblows.
if, like me, you like to put in place solid, stable, secure and infinitely configurable systems and infrastructure, but *nix is all scary, try putting "howto" in front of you google search, here's what I found, and it works. just works. keeps working.

if you're setting this up for a dev shop, the code monkey's will love you when finally a suit comes around dropping jargon like "single sign-on" - they can code against technology that doesn't cost an arm and a leg, is completely documented and adheres to "standards" - those are the things M$ never attain.

anyhoo, enjoy the infrastructure building, just remember - if a tarded microserf can't do it with one click, then the tarded microserf can't f##k it up.

eDirectory (0)

Anonymous Coward | more than 5 years ago | (#28217189)

I'd rate your best option, by far, is eDirectory

Fully LDAP Compliant.
Can handle your directory regardless of how large it gets (AD STILL has scaling issues)
Can remap all the default mappings for both attributes and classes so you could very easily have your eDirectory tree replicate the behaviour of everything from AD-LDAP to OpenLDAP
Latest eDirectory services on OES 2 SP1 include Domain Services for Windows, allowing *native* AD calls to work (you can even manage your eDirectory with MMC)

And if you ever find eDirectory can't do everything you want it to, you can always use Identity Manger to sync your eDirectory to practically any other service you're using.

Sure, AD is great, if you're a total Microsoft house, but you'll have nothing but issues trying to get it to play nice with your Linux kit, and if you get yourself near 15,000 users you'll be wishing you had a system that scaled.
OpenLDAP is great, if you're a total non-Microsoft house, but you'll have nothing but issues trying to get it to play nice with your MS kit, and if you might find some of its feature set limiting.

Thiago Barbanti (0)

Anonymous Coward | more than 5 years ago | (#28217215)

You can use too:

Apache Directory (

Sun OpenDS (

today I have a job implementing a single sign-on solution to be integrated with system stuff of company, internally using OpenLDAP. But in my development process I am using Apache Directory as development platform to do this job at all and I see as good solution many because the manager application (Apache Directory Studio).

Why not Apple's Open Directory (0)

Anonymous Coward | more than 5 years ago | (#28217383)

With the mostly Linux/UNIX boxes and only few Windows boxes Apple's OS X Servers Open Directory (openLDAP/Kerberos) is very easy to use, and with less than 8 clicks you can have SAMBA configured with it to authenticate the Windows boxes. All clients would use Kerberos for authentication, plus you are using open source technology.

Depends on what control you want over the Windows boxes.

Linux/Mac/Windows Admin

The comments are interesting (1)

GF678 (1453005) | more than 5 years ago | (#28217781)

I notice that whenever someone recommends sticking with Active Directory, they apologies for recommending it.

It's amusing because they're apologizing for recommending the best solution in this situation, which is EXACTLY what a good commenter should do. They have nothing to apologize for, and so I guess their apologies are more for the fanboys than anyone else who cares about a good result.

Just admit it - OSS doesn't always work, so making a suggestion which involves using Microsoft technologies is nothing to be ashamed of. It shows you aren't an idiot and prefer the best solution as opposed to a Slashdot friendly solution.

OpenLDAP is the way (0)

Anonymous Coward | more than 5 years ago | (#28217811)

  I replaced an AD domain with Samba/OpenLDAP, in a mid-sized enterprise of 13 networks nationwide (~30 windows boxes each), it works like clockwork. AD works allright, but until there's a Linux version of it, you'll be enslaved to the whole Microsoft administration nightmare experience: restart-every-x-weeks/update-patch/virus-proneness etc. including the MS tax of course, wich includes call-licenses (one per client)...

OpenLDAP Pros:
Robustness: it's a snap to set up replicas everywhere.
Efficient: faster in the same hardware than a win2003/AD, the bandwidth and time needed for replication is nothing compared to what AD needs, also you don't need a cluster to make it robust, it just is.
Simple to set up if you are using the packaged version (I've used Ubuntu's and Debian's versions, they work out of the box), although for specific customization/needs it may not be as simple as clicking NEXT until your index finger is sore.
Flexible: you can authenticate almost anything against it, there are decent LDAP libraries for most programming languages, and you can pick your choice middleman authenticator: Samba, PAM, Radius, or even POP3, to name a few.
Secure: if you have your own x509 PKI (and you should), it's easy to have everything working under SSL.
Good documentation and support: there's already a ton of how-tos and tutorials on how to get it working and there's always the mailing lists and forums.
Easy to troubleshoot: just increase the verbosity of log/debug levels and you can figure out exactly what you've missed.
Easy to back up and recover: back up your database to a plaintext ldif file and recover/create new replicas in a blink.
Oh, and it's Free software.

It's not AD, so AD magical stuff for winXP/Vista is not there yet, but wait for the next version of samba and you'll get some of it if you really need it.
You need to read a little and actually understand what you are doing to set it up, but the time you spend learning how to setup OpenLDAP is but a fraction of the time you'll spend actually managing an AD network.

OpenLDAP has really simplified things around, users have a single account for: windows domain, squid proxy, apache, jabber, email, webapps etc. And it also holds postfix's virtual aliases and squid's ACLs. Everything in a single replicated, secure 'place'.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?