Slashdot Mirror
Best FOSS Active Directory Alternative?
danboid writes "I'm an IT technician at a large school near Manchester, England. We currently have two separate networks (one for pupils, one for staff) each with its own Windows Server 2003 Active Directory box handling authentication and storing users' files. We're planning on restructuring the network soon and we'd like to be able to replace the two aging AD servers with a single, more powerful Linux server running an open source OpenLDAP implementation. The main contenders for this purpose seem to be Fedora Directory Server, OpenDS, and Apache Directory Server; but I've been unable to find meaningful comparisons among the three. I'd like to hear which solution Slashdot readers recommend. What is your experience with ease of implementation / maintenance? Any stories of similar (un)successful migrations? Any other tips for an organization wanting to drop AD for a FOSS equivalent?"
The main contenders for this purpose seem to be Fedora Directory Server, OpenDS, and Apache Directory Server
Seeing as you don't even mention Samba, I assume you are trying to avoid drop-in replacements for AD?
Try talking to Tim Fletcher at Parrswood.
but the first thing to do is look at how these have been deployed
I dont see anyone with production systems on a large domain using anthing other than redhat directory or Novell eDirectory
I see some custom OpenLDAP servers scale really well but thats about it
so given your choice above I would go for Fedora Directory Server and hack
if the choice was mine I would spend a little money and get the Novell eDirectory
regards
John Jones
http://www.johnjones.me.uk - email and digital communication
The story goes around that an infamous Australian telecommunications company wanted to put 80,000 people on a single Windows NT domain which put it well past the 16bit limit of users - and thus the active directory project started.
I'm a network admin for a tech college here in the states. We really use the hell out of group policy. We use an AD server for managing the directory and UNIX (FreeBSD mostly) boxes for handling everything else. The UNIX boxes act as member servers in the domain.
Unfortunately there's nothing that really supports things like group policy and the like for Windows but well..... Windows Server.
Samba4 is supposed to change this but it may be a while before it's ready for widespread use.
In a school environment, you really want the Group Policy and automated software deployment features. Unfortunately, due to the closed nature of Windows, Windows Server is the only product capable of pulling off managing windows desktops well. You can hand-create policy files for machines but it's a pain in the ass and hard to maintain in the long run. Samba3 can act like an NT4 PDC if you wanted to do this though.
This is rapidly changing. If I were you, I'd deploy Linux or BSD for everything BUT the directory servers and then migrate when Samba4 is ready for prime time.
Students are great at f**king up machines, group policy is almost a must.
If you don't need centralized management of the desktops themselves, just the users and groups, etc, then there are several solutions that would work well. In a school though, I really recommend either dumping PC's entirely and go with OSX on the desktop and OSX Server or sticking with AD for directory services.
Don't even start with the flames. Linux and BSD are awesome but until you can run Photoshop, Indesign, etc that the syllabii for certain classes call for in a supported fashion, it's NOT going to happen. OSX happens to be a UNIX with good commercial desktop apps that aren't half-assed and it's semi-open.
It may not be opensourced yet, but Sun has released almost their entire enterprise stack for free for anyone to use, including their DSEE, with unlimited entries. It can synchronize with AD, and they have a good deployment planning guide for synchronizing with AD and there are guides all over the place regarding authenticating Windows off of LDAP servers.
I love Active Directory, but just a little amusing anecdote... The company I'm working for is a 100% Windows shop across the board, has desktops in the 6 figures, yet does NOT use Active Directory...
Their "forests" connect for business reasons to the domains of all of their clients, which makes the machines/accounts in the domain hit the millions...so well, to make that work better, they wrote their own "Active Directory" from scratch...its still running on Windows server, but its not an actual Active Directory(tm) kindda thing.
But yeah, replacing AD for the sake of replacing it, is retarded. Windows Server isn't even that expensive, and for smaller companies, you can get Small Business Server, which is really, really cheap for what it provides.
I've seen RHDS (paid support version of FDS, but basically the same code) scale to millions of users. I've had a clustered pair running on blades handling 250K records easily. AD doesn't scale as well, requires tons of supporting software and locks you in to a funky LDAP-like format. If you want to move from RHDS to Novell, or OpenLDAP or even AD all you have to do is dump to ldif. Try going from AD to anything else without a great deal of pain.
In the summary, the poster mentioned wanting to reduce the number of physical servers from two to one. There's no way to do that with active directory (unless you virtualize) because each DC can only handle a single domain. Personally, I think the server count just for DCs is a big problem with the design of active directory. If you had two separate but related organizations, to do things the "right" way you'd need at least six domain controllers (two for an empty root, then two DCs for each of the production domains.)
What part of "shall not be infringed" is so hard to understand?
If you're considering Fedora DS, you also might want to look at FreeIPA.
I have set up four installations of SMEserver 7.x in the past 8 months into small businesses. I think I have put a collective 24 man hours into keeping those sites up. They stay up... keep going and going and going... and running Linux, I don't have nearly as much to worry about with critical worms running around and the like. Meanwhile, keeping up with my Microsoft AD network keeps my family fed and me employed full time. I am not complaining, I am just saying if TCO is largely factored by time/labor? SME server beats Microsoft hands down so far.
Microsoft does not justifiably dominate the market. It simply dominates the way it does with all other things it does. MSIE is the best web browser, I suppose, as evidenced by its dominance as well..?
No, but I remember when Debian was only two CDs, and the second wasn't very full.
Hail Eris, full of mischief...
E pluribus sanguinem
There's a nasty little caveat to using linux clients to authenticate securely to Sun's LDAP server: if you're using a proxy account for authentication, you need to place a plaintext file (ldap.conf, I believe) so that it can be read (cannot use a hash). I've still yet to figure out a workaround to prevent the need to place the password in plaintext where the only thing I can do is chmod 400 the file.
:)
I would love to be demonstrated otherwise, if someone knows
That account only has to have read only search to the directory. You can setup ACI's to prevent it being able to do anything but return authentication search results.
Anonymous search is common for both AD and LDAP directories. If you set things up correctly, all you can see with this account/password are the same you could see on a linux/unix box by doing a "getent {passwd,group,host...} command.
I have one question. If the Japanese Ministry of Agriculture is not in charge of Gundam, then who is?
I recently worked with a guy who had this same mantra "I have someone to call who will help me, that's why we use Microsoft.".
This guy never bothered to learn anything from Microsoft because he could just pick up the phone and burn company money on an incident report and get hand held through fixing whatever it was he fucked up that day.
I'm not saying that you 'never' have problems with things other than Microsoft, but when you do you've got more immediate options available such as (1) googling for error messages (2) looking at the source (3) scouring the forums for the project.
Personally for every product I managed to switch from Microsoft to something open source I never had to be woken up at 3am for anything, I'm sure it's possible that would happen but if it did I, or anyone with a web browser, a little unix experience and 2 ounces of brains could solve it too.
Microsoft being available to fix their broken stuff isn't the answer, making resilient software in the first place is. For lack of resilient software from them, I go elsewhere.
And, for the record, I don't care about Microsoft vs. OSS or any of that stuff, I've paid for plenty of great software over the years, if Microsoft makes a good product I've got no qualms about going with them.
However, with terrible piles of crap like Exchange and Vista, the answer isn't who do you call at 3am, it's who do you call at 9am to replace it.
As far as 'who will maintain this when I'm gone?' who gives a fuck? If I get fired, fuck you and the horse you rode in on. If I leave, I'll happily produce documentation that any future employee with a little unix experience could understand.
Plus, fuck you for charging me $250 if it's my fault. I make mistakes just like everyone else, if I'm doing something terribly wrong, fine, but if I made a little mistake or MS didn't document it.. fuck you double?
There's plenty of sharp guys out there who'd chomp at the bit for the opportunity to be woken up @ 3am for $250 to say 'Oh, you need to push the changes out to the cluster.'. That's not a reason to go with microsoft.
It's a reason MANAGERS will go with Microsoft. But, with the recent economic blood-letting of idiots from tech companies you might not be hearing 'Nobody every got fired for buying Microsoft..' much anymore.
Thanks for the reply, Fyzzler. I have looked at anonymous querying, but for DDoS purposes, it does not seem prudent. However, I'll read up on configuring ACI's, but it would still be nice to eventually not have to rely on a plain-text password, anywhere.
We have implemented a similar project in our local school.
OpenLDAP takes a while to configure but it does work eventually. When new students are added to the school DB they are added to the system by a Perl script which generates entries automatically and mails the class tutor with their login details.
Samba once set up works wonderfully for us.
Best of luck and hope it works out well for you.
"Linux is for noobs"-The new MS fud strategy
It can be done, but there's a few things you have to bear in mind:
1. Lots of existing products (and this is becoming more common as the years go on) expect an AD-backed domain. Samba + (insert name of LDAP server here) currently can only emulate an NT4-type domain. Samba 4 claims to eliminate this issue but the last time I checked it wasn't even in beta. You'd be nuts to implement it in production at this stage. If your employer's been heavily into Windows for some time, don't be too surprised to find you need to replace quite a lot.
2. Do you have a lot of policies pushed out through AD? (If you're a school, the answer should be "yes". Unless you like making work for yourself...) The closest equivalent is NT4- style policies - which aren't as flexible, don't offer as much and suitable precooked template files are becoming much harder to find.
3. Do you use Exchange anywhere? Exchange doesn't have a directory of its own, relying heavily on AD. You'd have to replace it, and while there are lots of projects claiming to replace Exchange, few come anywhere close in the real world. Most of the projects seem to be driven by people who have heard of Exchange and had it described to them, but never actually used it much.
4. Is your network heavily subnetted? AD doesn't really care about this because it uses DNS to find services it requires (such as the domain controllers). NT-4 type domains use broadcast packets, and can be a dog to get everything working properly where a lot of subnets are involved.
5. The information stored in AD about who owns and has permissions over which files is stored as unique IDs ("SIDS"). As far as I know, there is no easy pre-cooked way to migrate these SIDs between AD and Samba. So you're going to have to be very careful at replicating this information in your shiny new LDAP-backed system otherwise who has access to which files is going to be thrown all over the place. If that means one pupil gets read-access to another pupils work, that's annoying. If that means all the students get write access to a file storing their grades, that goes out annoying and through the other side.
Basically, if you already have a strong investment in Windows servers and associated licenses, this carries very high risk, will cost an inordinate amount of time and inevitably mean substantial upheaval for your end users. And (assuming you currently have AD running fairly nicely and you do a good job), you'll come out the other side with there being little or no perceivable benefit to anyone else.
OpenLDAP is a top notch LDAP implementation. It's only about 60% of a directory solution though. The management and configuration tools are where the difference is.
Now setting up openLDAP isn't that difficult but it's a stretch for a lot of MSCE type IT folks. I'm also going to go ahead and assert that maybe 20% of AD users or LDAP users actually have any idea how the LDAP tree is structured, they basically want a GUI where they can reset passwords and grant access, how the rest of it works they could care less. You've got a fairly steep hill to climb if you want to run OpenLDAP and simply don't care about LDAP.
All that being said, there have been a lot of startups that try to polish some opensource and sell it, Directory Server in a box built on top of OpenLDAP seems like a slam dunk, it's really an exercise in building a UI and writing documentation.
If I had originally built the network where I'm at, believe me, I would have gone with thin clients for a majority of the labs. Would have cut our TCO dramatically. No moving parts, no HD's to fail and they are easily managed.
Thin clients are awesome in an environment like this if you can convince mgmt that you need a killer server. The thin clients themselves are cheap but you want something pretty beefy server-side.
Moving to thin clients at a previous employer for most things cut the number of helpdesk calls by at least half and failure rates weren't even 25% of what they were with PC's on their desk. There's some gotchas here and there but I didn't regret it one bit.
Just because it has some good uses doesn't mean it's not vendor lock-in, and it doesn't mean the vendor won't effectively be holding your IT operations for ransom. You may think this is an OK trade-off for having systems that work very well together and allow you a great deal of control over clients, but not everyone would agree. You are basically putting yourself in a situation where Microsoft could raise their price 1,000% per seat and you would be forced to pay. They also can, and do, force you to upgrade, even if you don't see a need to. Now it might be that this loss of control is worth being able to push out and enforce client side Windows Update parameters...but it's definitely not as clear cut a case as you're trying to make it.