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?
Depends if you are just using it for windows domain services, or if you need to support things like management, federation etc.
OK buddy, you have done your job and made enough noises about FOSS. Your $large_discount coupon from MSFT is ready and waiting, mention coupon code EGDI. Coupon good for getting all MSFT software for free. Manufacturers Coupon, Never expires.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Mandriva Directory Server + Pulse 2
SME Server is, by my observation, the best Windows network server distro I have yet seen. While I don't agree with many of the underlying philosophies, I cannot deny the results. It is STABLE. It is usable. It is very maintainable. Installation is brain dead simple.
SME Server 8 is in beta at the moment but I recommend giving it a once-over. It is quite impressive. And did I mention it installs from a single CD?
GOsa is worth a look but in my experience is VERY hard to implement. It's a web based LDAP front end that manages posix accounts, Samba, email/groupware, Asterisk, fax, automatic installation (via FAI), DNS, DHCP and much more. I think the target market is large organisations with existing inhouse skills in the base technologies and plenty of man hours. I tried getting this working as a lone generalist, and I only got as far as getting posix, Samba, SOGo (a groupware solution), DHCP and DNS working. Scripts to get something working on Debian Lenny are on sourceforge (I finally found a use for my sourceforge project:) : https://sourceforge.net/projects/wfstt/ .
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.
Questions you should be asking yourself:
One more question: Why not just combine the two AD forests into one tree, with the student account domain as a child domain of the teachers' domain? (There are many other arrangements here that may better fit your needs.)
--Whizzmo
I don't often recommend SUN products with the exception of Solaris but Sun Java System Directory Server Enterprise Edition has actually proven to be a very stable solution. I don't believe its open source but I believe it is free. There is also an identity synchronization tool that allows you to sync your LDAP to AD servers if needed. Handles multimaster replication between however many nodes flawlessly with very good performance in my experience. It'll run on Windows,Linux, or of course Solaris.
Good luck, LDAP is a pain in the ass ;)
Maybe not exactly the answer you're looking for, seeing as Samba4 is not out yet; however samba4 includes, among other things:
* Internal LDAP server, with AD semantics
* Internal Kerberos server, including PAC support
You can, but don't have to hook it up to an external LDAP server. You can use MMC consoles to manage it. They're even building real Outlook compatible Exchange functionality on top of it (see openchange.org). Not that I'd ever want to run Outlook though.
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.
...we'd like to be able to replace the two aging AD servers with a single, more powerful Linux server
Whichever system you end up using, I strongly discourage building your network around a single server.
I've messed with the so-called "Active Directory replacements". They all suck.
The fact is, if you are using Windows clients, Active Directory works, it's simple, and you'd be fucking CRAZY to try to use anything else. Save yourself some pain, and blow $1000 (pounds, whatever) on Server 2003 or 2008.
Seriously. You don't want to do this. It's a fucking nightmare to try to support a Windows domain without a real, genuine Microsoft domain controller.
Did I mention this is a bad idea?
I'm not sure I understand the point... I mean I hate Windows as much as the next *nix-lovr, but if your network is a slew of Winboxen... why make a headache for yourself? Active Directory is pretty well received, even as a proprietary LDAP implementation... will a FOSS replacement really be worth the cost savings? If most of the machines to be managed are Windows, I'd use AD for them. If its a mixed network with mostly something else, then I'd attempt to shoehorn the management of the Winboxes with whatever implementation was easiest for the majority of the machines (i.e. if 200 OS X machines & 40 Winbox, I'd use Open Directory... if 90 debian & 15 winbox, likely OpenLDAP, etc.)
You don't hate AD as much as you think you do... do what is easiest... if AD is already deployed, its probably easiest).
The Admin and the Engineer
Hate on Microsoft all you want, I do it all the time myself, but AD (and Exchange as well) get the job done, are well supported by Microsoft, and in my experience, worth it. If you weren't running windows clients, it would be different, but as many people on here have said, the features of AD are hard to replicate. Perhaps you have philosophical open source / free software motives. But the only reason I could think of for that a smaller organization like yours would move off AD would be to save money on the license, and especially on CALs. But as a school, don't you get them for damn near free anyway?
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.
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..?
The racial slur is sambo, ends in the letter 'o'.
Samba (ending with the letter a) is the first word in the unix dictionary that had an s, m, & b in it.
Samba itself is a musical genre.
Do you really want to use software named after a racist slur?
No, it's not a direct comparison to the GIMP situation. The slur is Sambo ; the software is Samba . There's a difference. But is there a racial slur against trolls?
The main contenders for this purpose seem to be Fedora Directory Server, OpenDS, and Apache Directory Server;
OpenLDAP is too plain and simple. It isn't user-friendly. There are no GUI tools that come with it although there are various tools people have made that you can use to manage it. I even created one myself as a senior project because it doesn't come with one and having to use the CLI commands for everything is just more trouble than it is worth when you want to get up and running quickly.
I haven't ever used Apache Directory Server so I can't speak to that but Fedora Directory Server comes from the Netscape Directory Server of yore. NDS went under and Sun Directory Server took its place. Netscape and Sun Directory Servers are basically the same thing, even the GUIs are the same except for name/logo changes here and there. FDS should be pretty good based on the NDS/SDS pedigree. OpenDS is new and runs using Java therefore it automatically requires more resources than the others which are built with C/C++. I'd let OpenDS mature a bit more before using it. Of the ones you mention I'd pick Fedora Directory Server.
But I have some questions. Do you plan to migrate clients over to a non-Windows OS? If not you'll need to investigate how to continue making Windows clients authenticate to a non-MS directory. It is possible to make this happen but past methods of doing so (a few years ago for me) have been kludgey at best. Windows likes to talk to ADS. If you migrate to Linux clients your job gets much easier because you don't have to worry about Windows SIDs and similar critical components of a Windows infrastructure.
Do you have people who know directory servers and understand LDAP? Be aware that ADS makes things easy for a Windows administrator. Even Sun Directory Server does not automatically enable replication when you have it installed on 2 servers. I highly doubt the other implementations you are looking at do the same. Therefore you will have to really understand how directory servers work underneath when working with these other implementations. You have to create replication agreements yourself and understand the underlying LDAP structure. ADS hides replication from you (accessible through Sites and Services snap-in though) until something breaks. The schema is hidden from you as well unless you need to access it (not even in the default list of MMC snap-ins but it can be added). Make sure you have people who can administer directory server installations, not just ADS installations, when you do this migration.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
I agree with your statements regarding what ADS provides and what OpenLDAP does not. The fact that OpenLDAP gives you a backend and nothing else is one reason I did not recommend it to the submitter however your subject for your post is not correct. ADS *is* LDAP. It uses LDAP underneath just as any other directory server does on the market today. Many also can integrate with Kerberos just as ADS does. I hate when people call ADS "Active Directory" and then they refer to Sun's implementation as an "LDAP server" or whatever. The fact is ADS is as much LDAP as any other. MS has just added attributes to the schema to fit a Windows infrastructure but then again so has Sun for Solaris clients. The LDAP schema was meant to be extended and can even be extended by the administrators to add custom attributes and object classes for companies who want to integrate their products with it. MS is no different in what they did. It's their own implementation of it just as Sun has their implementation. If someone wants an unadulterated implementation of a directory server they should go for OpenLDAP but they will be sorry (if only due to lack of management tools).
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
Comment removed based on user account deletion
There is no comparable solution. Choosing anything else is a massive disservice to your users and the people responsible. AD is set up by default to work properly. It requires minimal maintence. It supports multimaster replication, automatically doing nearly everything required. It uses Kerberos. It does your DNS for you. Windows works perfectly with it. Linux sort of works with it with Samba. Your alternatives in the FOSS space are basically seting up FDS or OpenLDAP by hand. THat means making the schema by hand. OpenLDAP does not do multimaster replication. You will have to hand configure kerberos. You will have to manage most maintence tasks by hand, using tools like some Java LDAP UIs, which expose raw LDAP information to you. You will not have an easy interface to 'create users'. You will have interfaces to edit LDAP databases. FDS is a better LDAP server: but it is STILL JUST AN LDAP SERVER. It does not take care of DNS. It does not do Kerberos. Novel's commercial offerings are the closest: but they are woefully hard to get set up compared to AD, and they cost just about the same.
Samba isn't an Active Directory alternative.
1. I hope you understand what you gain and lose by switching.
2. I have had to endure the pain of selecting from a few LDAP servers few months back. Just go and download Sun Directory Server Enterprise Edition 6.3 (DSEE). Buy a support contract of whatever level you need. Set it up (takes minutes, the docs are EXCELLENT!) and after that forget it even exists. This baby just works!
- mritunjai
I've worked on very large directory deployments.
10 million user accounts.
We were using Novell e-Directory for the authority user database and AD downstream via DirXML for compatibility/legacy reasons.
Remember, Novell basically wrote the book on directory services. Microsoft just copied their implementation.
You can use ZENworks to store Group Policy objects but it will take much more than a Slashdot article to explain these concepts.
The beauty of eDirectory is that Novell have agents for basically every platform that is worth a damn, try that natively on Windows.
When you're dealing with something as critical as a central directory you don't want to mess about. If you have to throw some money at it to ensure some accountability and support then do it. Windows AD works as advertised, but it only works with Windows - you're on your own with anything else.
There is third party companies that have written software that bridge the gap to manage UNIX systems, users, applications, policy which from what I've seen works pretty well.
At the end of the day it comes down to understanding your environment, budget constraints, support, IT strategy, applications, business/IT partners.
Oh yeah one more thing, this big install is for an education body.
Just to throw what I use into the mix, on a network of ~100 WinXP desktops:
- Samba - acts as domain controller, triggers login scripts, maps drives etc. System Policy controlled using NTConfig.pol files in the 'netlogon' share, prepared using poledit.exe
- OpenLDAP - authentication backend for Samba, groups/users for the Samba server (plus many other tasks which are unrelated to desktop usage);
- WPKG - for software deployment, runs at each boot-up - really nice.
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
From my experience, in a small-to-medium Linux/*BSD/OS X environment, with NFSv4 or AFS, this will work fine.
However, as other posters here suggest: if you have predominantly windows clients, for your own sanity it would be better just to use AD from the outset.
.:SOLCAVUS:.
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
First of all, why use crappy openldap when you can use the Netspace directory server that red hat bought and opensourced.
I have foung openLDAP to be reliable, compatible and easy to use. Can you elaborate on why you think it is crap?
There is a reason why they paid 23$ millions for it...
And the reasons are?
Then, AD isn't just a LDAP server with usernames and passwords....
Nor is openLDAP just a store for Windows user names and passwords. I use an openLDAP server for Windows services as well as providing user configuration for other services such as sendmail. The great advantage of using FOSS is that you are free from vendor lock in and can consider non-proprietary alternatives in other areas of your network.
Which is why many people can only use Windows setups. There's nothing like AD in the FOSS world. To start with, FOSS client apps should be lockdown-able from the server. But you can't do that...
I mean, in a office with a linux server and some linux clients, try to lockdown some options on Firefox, the desktop, evolution....surprise, you can't do it. Oh, yeah, there're a lot of workarounds everywhere, but they are different if you use KDE or Gnome or depending on the app you are using. It's a horrible mess.
Nowhere in the article do I see a desire to use FOSS desktop clients. The submitter simply wants to replace AD server with a non MS LDAP based alternative.
Windows clients and servers, on the other hand, are VERY well coupled. The day someone cares to fix this in the FOSS world, a lot of people will start using Linux in corporate networks.
This is otherwise known as vendor lock in. Some of use have tried very hard to break free of it to avoid being held to ransom by a vendor.
Until then, Windows is pretty much the only realistic option. I can't understand why Red Hat, Suse and Ubuntu don't put more efforts on this, it's one of the biggest showstoppers for Linux adoption.
I have been running what you consider an unrealistic option for the best part of a decade. I have yet to be fired. Sirius the consultancy I recommended have a client list of blue chip companines, local govenment and schools. They are all running some form of FOSS backend. You might like to take a fresh look at FOSS, it really works in the real world.
In my previous post I forgot to mention that OGC/Becta are the government agency's responsible for technology in the UK educational environment. It is considerably easier for a UK school to use a Becta accredited supplier than any other supplier. It is an incredible achievement for Sirius to gain that accreditation as no other FOSS consultancy has managed to cut through government red tape thus far.
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.
Thanks to everyone who has posted ideas, suggestions and comments so far- I've just finished reading them all now- much appreciated and very interesting stuff.
A few points that I should've mentioned in the original question are that (as most of you correctly assumed being a UK school) nearly all clients are Win XP SP3 with the odd exceptions of a few Vista, Linux and OSX machines. I say migrating to one server but of course that would have a back-up machine- its just that at the moment we have this crazy configuration of two physically separate networks/domains with their own DCs, switches, ISPs etc- one for students one for staff. I inherited one helluva crazy mess, indeed! What I mean is that all this is going to be amalgamated into one physical network and one domain, not one server.
We don't use Exchange so AD/Exchange inter-op isn't a requirement or an issue.
I was aware of eDirectory but didn't mention that in the question because its not FOSS- however this has been recommended much more than Sun's solutions and Apache hasn't even had a look in. I don't want to rule Novell out as a possibility as it may just be better a better long term solution than sticking with AD/2003. It would seem FDS/FreeIPA is the only serious FOSS solution available for this right now
Of course, AD *should* logically be the easiest one to stick with/ 'migrate' to but that doesn't necessarily make it the best choice. I think we'd be more than willing to hire a consultant to help transitions to an alternative if there were numerous long term benefits.
I'm going to have a play with FreeIPA on a small network of test machines or under VirtualBox and see how that goes first I think.
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.
What ogdenk said.
Using Access in this manner is crazy and a huge performance issue all on its own, not to mention data integrity.
Good luck.
- Michael T. Babcock (Yes, I blog)