Slashdot Mirror
Ask Slashdot: Is Samba4 a Viable Alternative To Active Directory?
First time accepted submitter BluPhenix316 writes "I'm currently in school for Network Administration. I was discussing Linux with my instructor and he said the problem he has with Linux is he doesn't know of a good alternative to Active Directory. I did some research and from what I've read Samba4 seems very promising. What are your thoughts?"
We finally switched out our last NAS that was running Samba. Too many small glitches. Not worth the hassle.
It's important to realise that Active Directory has a bunch of overlapping different features. Samba4 is a great for part of it. Puppet is great for a different part of it (the ability to configure systems - like a superset of Active Directory Group Policies) LDAP covers some other parts etc. etc. You need to be really careful with this question because it is already loaded. Essentially, if the answer is "Active Directory" you are asking the wrong question. Your overall system administration story with Linux will be much better than Windows but you need to start thinking more from the beginning since it isn't always as obvious which tool is the right tool.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Samba 4 is in it's Alpha release stage and is not recommended for production. That said it's a remains to be seen thing if it will be.
It also depends a great deal on how and what you use AD for. For simple authentication you can use samba 3 + LDAP for that now.
For programs that require AD not so much with either.
Samba 4 *is* intended to be a full AD implementation. Currently it has a built in LDAP and Kerberos server set in the same daemon. That is a problem
for some, like myself, that use Samba 3 + LDAP for shared auth. When complete is *should* be a fairly complete implementation of the AD specs, all
of them. I have no idea how long this will take, or just how complete it is, but those are the design goals. All of this is a result of Microsoft releasing the
full spec due to the European Union lawsuit.
I also commented above, Samba 4 *is* intended to be a full AD server implementation. It is using the documents Microsoft was forced to release
as a result of an EU lawsuit.
How complete an implementation it ends up being and how well it works will have to wait to be seen once it exits Alpha status and gets a few
beta releases under it's belt.
It's a whole new samba in the end.
It works for small environments. But as you start getting above 50 people AD is the way to go for two reasons: 1) Less admin overhead time. Like it or not, AD "just works" unless you really snork it up; and 2) AD credentials integrate with more stuff and it's not tenable to have to maintain different user databases for each one. Sooner or later an enterprise will want exchange.,,,,,,,and spam filtering......and internet proxies etc. There are a multitude of products out there that will integrate with AD. To get the same with Linux / Samba (if it can be done at all) will require cobbling together services and solutions that will complicate your life. The bottom line: I went through my Linux zealotry phase too. Then I got a life and couldn't spend hours on end reading docs and fiddling with services and config files. Towards that end AD just simplifies user admin and frees you up to deal with other stuff. Linux has its place in the enterprise, but it ain't as an AD replacement.
Slashdot discussion about Samba 4's Beta release Samba 4 Enters Beta
I am Slashdot. Are you Slashdot as well?
We have, for many years, had a computing environment that, on the server side, is a mix of Red Hat Enterprise and Windows. Users and groups are (ostensibly) the same in both environments. The servers running Samba were in AD but were not acting as DCs.
Samba has always handled the user accounts perfectly. Groups, on the other hand, break fairly frequently - and by "break" I mean it stops realizing that group "foo" on Windows is also group "foo" on Linux. Since most of our end users are on Windows boxes, and most of the authorization on the web server (my main concern) is handled using groups, this has been a big headache for me. Fortunately we were able to convince our manager it wasn't worth the continued investment in man-hours by our Linux and Windows guys to keep debugging this group issue, and we just pulled the plug - now everyone has to use scp/sftp, and everything works well.
Admittedly this is a narrow use case I'm describing. Also I wouldn't be surprised if everything would be peachy if 100% of the AD stuff was being handled by Samba (and ONLY by Samba). But if this is a mixed environment, you should do some serious testing before making a decision.
#DeleteChrome
Samba may be able to do some of the windows file and printer sharing... even acting as a domain controller. BUT. Trust me. It will be hell to administer. For what you pay for Windows 2012 standard... with Hyper-V, and all the roles and services you just get... I dont see how you can compete with the ease of use and administrations. In the other-hand, if you are hard core UNIX/Linux and you need to support a few windows boxen in your environment.. then this is a great fit for you. Otherwise, stay away... far away. Anything you save in dollars you will spend in time... ten times over.
When you talk about alternatives to Active Directory you need to be specific as to what features of Active Directory you refer to. Active Directory is a lot of things: Distributed multi-master database, Authentication provider, Authorization provider, Configuration management system, and more. The Active Directory infrastructure provides: File services, Print services, Group policy, LDAP, DNS, DHCP, and other services.
I haven't read in detail about Samba 4, and it appears that the Samba Wiki is down at the moment, but there is a decent description on the Fedora Project site. According to the Fedora site, Samba 4 includes the ability to be a domain controller and implements the Kerberos stack, but it is not clear that it provides the centralized configuration management that Active Directory does. This centralized management (Group Policy) and the ability to delegate administration (Organizational Unit based delegation) are very powerful features of Active Directory and what keep large organizations on the platform.
If what all you are looking for is a shared account database and the ability for multiple workstations to authenticate against it, Samba 4 may be just the ticket. If however you are looking for a replacement for Active Directory at an enterprise level, I doubt it is there yet.
Since 2005, The combination of OpenLDAP, Heimdal Kerberos, and Samba 3 has been a staple in the Linux Infrastructure, with other services such as FreeRadius, NFSv4, and AFS being tacked on for good measure.
Many if not most Linux based utilities support LDAP. Unlike Samba 3, which functioned as an OpenLDAP based application, Samba 4 completely replaces OpenLDAP, and Heimdal Kerberos. Consider the following. Samba 3, while far beyond what Windows NT4 was ever capable of, expanded the NT4 Domain concept far beyond it' design limiations. In the most recent era, Samba 3.5 and 3.6, created an enhanced form of NT Domain Authentication just for interoperability with Windows 7. (This is very fascinating because it uses Windows 2003 Sign and Seal with NT4 Authentication, something NT4 never could do.) So it can be be said, while Windows 7 expressly drops support for Windows NT4, Windows 7 has express support for Samba 3.
Yet the sword of Damoclese has swung over the head of Samba 3.x for a long while. Vista dropped support for NT4 Style System Policies, requiring administrators to resort to registry Trickery with Wine and third party policy tools such as NitroBit.
Samba 3 brought about a form of NT Domain that supported LDAP as a backend, could use Kerberos for Authentication both for file shares and joining the Domain. (Although only other Samba clients could utilize the Kerberos aspects of Samba 3.) Could delf out policy by OU. With help from OpenLDAP, Samba 3 could overcome the single PDC limitation, and all Samba Domain Controllers could be writable PDCs because OpenLDAP supported Multi-master Replication.
Beyond Samba, FreeRadius could use LDAP for authentication, Evolution could garner configuration information from OpenLDAP, for IMAP and SMTP settings (CalDAV Support was never added, even though there were feilds in the OpenLDAP schema for the three CalDAV based Calendar, Addressbook, and Task List.) This cooperated with eGroupware. Sudo could draw Sudoers from OpenLDAP, as could NSS. Each had their own unique Schemas.
Unlike when Windows moved from NT4 Domains too AD, the movement was simple, before, you had no Directory Service, and now, boom! you do. In the Linux world LDAP has been a reality for a long time. Many applications are built to participate in Open Directory based Domains based on OpenLDAP Schemas. What happens if the Schemas conflict definitions? How will this be resolved?"
Ask yourself why?
I used to be like you when I was 20 a decade ago. Here is what I have learned. Your enterprise hates change and looks at you as a financial burden and unnecessary cost unless you work for an IT company. If they have AD why switch? If what they have works don't mess with it.
I saw this pop up last week on slashdot when Microsoft suggested business users stop using XP. Shockingly a decade ago on slashdot people would be laughing at everyone using a 11 year old platform who refuses change all based on Microsoft. Fast forward today you see folks under 35 freak out and DEMAND XP BE SUPPORTED FOREVER because changing is something you never ever do! Those over 35 got modded down saying upgrading is part of your job. The point is to put SAMBA 4 in you have to fight such people. They hate change and will cling to obsolete products as their behaviors in the last decade taught htem to lock versions with no updates and view everything as a cost center. Even a free product like Samba as such.
If it breaks who do you sue? Who do you call for support? Will you be handed a pink slip with a boot up your ass out of the door if something breaks? AD is standard, it is used by everyone else, other products like SQL Server, Sharepoint, and Exchange use it. It is part of the proprietary eco system at work and even though slashdotters breathe down Linux as the end all for everything it is not in an already established enterprise environment.
Just stick with AD. It is what you will be quizzed on and expected to know in your first job interview. If you do not know it they will find someone else who will. It is that simple.
http://saveie6.com/
So far I've set up several small offices using Samba4 as a drop in replacement for Active Directory. Here is what I've found it does well: Windows Authentication, AD DNS, Group Policy, Easy scripting (python tools and libraries). What it doesn't do well yet: Replicating AD with other servers. I haven't had much experience using subdomains, etc, mainly because I haven't been able to get it to replicate. But for a small office, it works fine.
Look at the use case.
I know too many Windows and Linux folks who try to shoehorn one way of doing things so it runs the way they want them to. This post reeks of that.
Find the best business reason to use one thing or another. I don't disqualify MS because it's not open source, or Linux because it's free. There are costs to doing everything, and usually made up outside of what infrastructure you decide on.
That said, Windows is best on the desktop because of Group Policy, its extension into things like System Center, IT Asset Management systems, reporting, workflow, automation, etc. I know it "can be done" with Linux but the process is usually smushed together and kludgy. Windows is simpler because of the software that supports it, many of them made by MS themselves.
I will stick with *nix for my backend requirements, and Windows for my front end. Until something changes drastically, I don't see much point in trying Linux on the desktop -- it's clearly not its strong suit.
The price is always right if someone else is paying.
Keep in mind that "Group Policy" is, truly, is merely Windows Registry keys stored in the LDAP database in Active Directory. Samba 4 will store these in it's LDAP database. Something Samba 3.x+OpenLDAP Couldn't do.
Linux has no Registry, Linux approaches the Group policy concept differently by having application level Sub-Schemas that have to be imported into the tree. Linux applications then have to be configured to call on the LDAP Database instead of using it's local files. There are OpenLDAP Schemas for:
Sudoers ...and more.
Evolution
eGroupware/phpGroupware
DHCP
Samba 3 of course
Bind (Deprecated)
Posix Accounts (/etc/password, NIS and NFS related)
CUPS (Printers)
Kerberos
Posix
Puppet
urpmi (Exclusive to Mandriva)
Apache (Can store httpd cluster information)
Zimbra
When Samba 4 is released, you have to import all these OpenLDAP entries into the Samba 4 LDAP tree.
I don't think these days there's much "configuring and reading documentation". There's one samba-provided registry file you need to import on every Windows Vista/7/8 host before joining them to the domain, and that' sit. It pretty much works. Server-based printers w/ drivers don't work for some printers because said printer drivers are buggy and won't take anything but only certain windows server versions. If you use IPP printing, things are fine. I still keep drivers on the server and push them to clients using windows-native print server configurator.
A successful API design takes a mixture of software design and pedagogy.
Take a look at http://www.zentyal.org/ .
Puppet has a server and client setup. The Puppet server process is Unix only.
MSI packages are supported. I'm not sure about group policies yet.
I can throw myself at the ground, and miss.
I realise Novell aren't exactly a powerhouse any more, but does anyone else remember about 5 years ago when they released Domain Services for Windows? That was basically Samba 4, but using eDirectory and NSS (that's a proper man's filesystem, for you young kids) as the back end. I only played with it briefly whilst at my last employer, but damn did it rock... All the NSS clustering and good bits of Novell tech were totally transparent. The only time you knew you were talking to a Linux box was if you opened up a DC in MMC and looked at its properties, where it said something along the lines of "SuSE Linux Open Enterprise Server".
Fairly obvious that Jeremy A was largely responsible for DSfW, just a shame that stuff was most likely locked up as Novell IP and off limits to Samba 4.
I don't think it's bad for what it does, but the inability to rollback changes or even to know what's been changed is a serious oversight. There are third party tools that fix this (Google search for active directory change control), but for a large scale environment you shouldn't have to rely on third parties to make a tool usable.
Contrast this to a UNIX based ldap server (openldap) where the entire directory can be saved and reloaded as a text file over and over again.
AD also has the tendency to bury lots of information behind properties windows that have 30 or so tabs. Even if you look at all of those you'll still miss disconnected pieces like group policies or if an AD account has an exchange account.
I don't think "replace AD with Samba" is a good idea though. If you're going to be using lots of Windows systems then you're better off managing them with the tools provided by the vendor.
...it has a built in LDAP and Kerberos server set in the same daemon. That is a problem...
The reason is that M$'s implementation of things like LDAP is broken. So a standard LDAP (or Kerberos) server is not going to work.
E.g., OUs that really aren't (In AD, OUs are just cosmetic). There are attributes associated with objects that break LDAP spec. etc.
Microsoft broke Kerberos just enough to prevent using a standard Kerberos server setup, but works to use std. clients against AD.
Microsoft broke DNS in the 90s. They allowed things like underscores in names which are illegal according to spec-- all standard DNS servers now allow underscores to allow interop with the broken M$ implementation. There is even a DNS RFC that comes just short of naming M$ which calls out that they butchered and abused DNS in their AD implementation-- this abuse interoperates with current DNS servers, though. so this isn't a reason for including their own DNS.
So, rather than breaking every other existing software package, or trying to maintain a bunch of patch sets, Samba just includes its own implementation of the above with breakage compatible with M$'s breakage.
Oh really? I ran multiple data centers and managed over 3,000 Windows Servers on 150 independent AD domains, Windows server is every bit as capable as Linux for almost all functions. In some, it excels at far beyond linux, such as managing enterprise networks via Active Directory. As with anything, it's about selecting the right tool for the job. Your statement "only case where I would consider using Windows Server in place of a Linux Server is if I could only hire grade 10 IT nerds who have no idea what there doing" simply goes to show that you are the grade 10 IT nerd who has no idea what he is doing.
I know exactly what I'm talking about, in my experience the only people who blast Linux are really covering up the fact they don't understand it. Windows is capable because Microsoft slapped a over bloated GUI on. I've used many Windows and Linux servers and I have yet to see a case where Linux wasn't the better choice in 99% of all cases. That 1% is for the "special" software that some VP wants installed that only runs on Windows.
I've had many people complain that they have to learn the command line to use Linux and they need to understand how the network works and etc.... but I tell them to grab a book and learn. Out out the 100's of Linux servers I managed I would down grade 0 of them to Windows, from my personal experience Windows gets in the way and allows slop on my network, Linux keeps it neat and running fast, even the master Domain controller which is used for something like 1000 people to log onto the network is Linux based. Before I started the Domain controller was a Windows Server and the login time wasn't horrible, after I upgraded it to a Linux server we shaved about 1/2 second off the login times and another 20% on resource use. So my statement holds, If you don't want to use Linux for your network then you either don't understand it or you don't want to put effort in upfront.
Fair enough, but to admin a Linux network, LDAP to Samba is like replacing a bicycle with a 30 ton truck. Sure, it is still transportation, but the operating costs are a little different. On Linux, you don't need it. You don't need NT shares (just use sshfs) you don't want group profiles (just use files in /etc), things done with Samba are usually done far more simply on Linux without it. Once you have it in place, you need to feed it... that complexity costs admin time forever. Sure, if you are stuck with a mixed environment, then it is necessary, but if you can avoid it, it is better to apply a suite of lighter tools.
to do which functions and to scale to what size? login authentication for 100 users in a medium sized business works very well, the medical office management company I set up with vmware and linux servers (but windows desktops) has been working very well that way for 3 years already.....
Overall, no, it isn't even close. Samba 4 may offer the core features of AD its self, but it doesn't offer all the powerful management and Group Policy tools, system deployment facilities, etc. Some of it could probably be hacked in on top, but IMO, it's really not worth it.
I was running a Samba3 domain on an LDAP directory for years. It was OK, but always had annoying warts and problems, plus it was a pain to run. Automatic printer drive deployment was fiddly and never that reliable. Group Policy wasn't even an option.
Eventually I gave in and moved over to win2k8. As a heavy Linux user and long-time *nix sysadmin, I have to say, for running Windows networks I am NEVER going to use anything else. Sure it has its issues, but it's reliable and it has an amazing array of system management tools.
The Microsoft Deployment Toolkit alone is worth running a Win2k8 box for : just PXE boot your clients and have them auto-re-install themselves, install software and printers, change settings, add local users, install updates, and reboot almost ready to use. You can do this with a USB key and a manually copied Windows PE image, but it's fiddly and annoying.
Then there's Group Policy. Group Policy actually makes me want to use Windows. It makes me want to get rid of my Linux thin clients - despite their reliability - because with Group Policy I can just push changes out to all machines (or defined subsets) with a few simple changes in a central directory. It's seriously impressive.
About the only irritation is that so many software packages use custom installers rather than the Microsoft Installer (MSI), so it's not always easy to roll them out via Group Policy server push. Some of those that do (I'm looking at you, Adobe) don't make it easy to just download their updates whenever they come out and push them via Group Policy; you have to go and check for updates by hand. Fail.
Despite the irritations, there's just nothing like it for booting a client off the network and having it come up ready to use. Redirect the user's desktop and documents folder and you don't even need to worry about the machine breaking or having client backups; you back up the redirected folders, and if the machine breaks you just re-image it because it has no local data of any importance on it.
The sad fact is that tools like this are no fun to work on, so they're not something we're going to be seeing in Linux/BSD land in a hurry.
Fuck proprietary AD calls. LDAP is the standard to code apps with. AD has an LDAP interface by the way.
Everything I write is lies, read between the lines.
You don't understand. AD IS LDAP. The Samba 4 AD Server runs OpenLDAP and Heimdal Kerberos.The file /etc files direct the machine to look to LDAP for configuration and policy instructions.
References:
http://stackoverflow.com/questions/997424/active-directory-vs-openldap
http://www.openldap.org/lists/openldap-software/200507/msg00185.html
http://blog.is4u.be/search?q=openldap
Everything I write is lies, read between the lines.
Microsoft broke DNS in the 90s. They allowed things like underscores in names which are illegal according to spec-- all standard DNS servers now allow underscores to allow interop with the broken M$ implementation. There is even a DNS RFC that comes just short of naming M$ which calls out that they butchered and abused DNS in their AD implementation-- this abuse interoperates with current DNS servers, though. so this isn't a reason for including their own DNS.
Not really correct. The DNS specification in RFC1035 from 1987 allows the use of underscores in names. This has never changed.
This is a common misconception because the use of underscores in hostnames IS prohibited and this remains true. Microsoft chose the use of underscores in thier AD implementation to remove the possibility of name-space collision with hostnames. BIND, the most popular DNS server in use only permits underscores in hostnames when an option is set to override the default.
Microsoft has broken lots of standards either because they didn't understand them or found it advantageous to ignore them, but this is NOT one of them.
Kevin Oberman, Network Engineer, Retired
Well, OK, granted for personal machines.
But you should at least be able to browse the available servers, right? What I see is the community will continue to put out buggy Windows interop software because M$ can't just hand over the AD source.
Anyway, like I said in another place in the discussion, the Linux community seems to have went about this wrong.
It would have been better to come up with a networking addon for Windows clients to allow them to easily browse and connect to resources provided by Linux servers in a hierarchical domain arrangement (basically, Domain Name System). So: ibm.com, fl.ibm.com, miami.fl.ibm.com, files1.miami.ibm.com, etc.
Auth handed by OpenLDAP and Kerberos. Remote login by RADIUS.
Some of that stuff would need some polishing around the edges plus integration, but again, writing your own Windows client DLL should seem to be much easier than divining and decoding messages passed around an AD network.
Also: it would have been nice to really think outside the box. Like, how about allowing users to browse resources instead of being concerned with which server a resource happens to reside on?
I'm not a lawyer, but I play one on the Internet. Blog