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?"
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.
Because clearly, they're not holding it right.
Samba has been around literally for decades and has seen constant reliable use.
You're suggestion that the software is new and poorly designed is invalid.
There are good admins and bad admins. If software that has been successfully deployed for multitudes of years has been a problem then bad admins are far more likely to blame.
- Dan.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
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/
Is it fair, to say, then, that Samba4 and AD are both good choices for people with strong admin background, but perhaps AD is a beter choice for someone who, for instance, administers the server in addition to other business tasks? Not everybody has the time to become a good admin. They tell their boss that, but the boss also doesn't have funding to go and hire one.
Software being around for decades doesn't magically cure all the bugs.
The OP stated that there were too many small glitches with the features they were trying to use, to which your response was that these glitches were imaginary and he just wasn't using it right. That sounds like something Steve Jobs would say.
You're suggesting that Samba is absolutely perfect and has nothing wrong with it at all just because people have been using it for 20 years. I doubt that. Would you like to take that logic and apply it to Windows and see where that gets us?
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.
If Samba is difficult to administer, that's a problem. That makes it inferior to the competition.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
The basic samba code has indeed been around for decades, and it's great.
Do be aware that samba4 release candidate 4 only got released on 30th October 2012 and as the announcement says "This is the first release candidate of Samba 4.0.0! This is *not* intended for production environments and is designed for testing purposes only.".
http://lists.samba.org/archive/samba-announce/2012/000277.html
No, it's not. When it involves Linux or OSS, it's always the admin's fault. When it's a proprietary solution, it's bad software. You must be new here, get with it.
...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.
Yeah, I never understood the whole 'tools that require more training to use are better!'. If two tools do similar jobs in the same use case, but one can be administered by someone who isn't a dedicated professional, and the other one requires a specialist, then within that use case, the easier to use tool is better. Additional complexity without additional benefit is not superior.
Certified SBS guy here.
Why would you be running multiple SBS boxes? You do realize that each SBS server is its own Forrest/Domain, right? You can't just join these boxes to the same domain without breaking some serious functionality. That's because each SBS box *must* hold all the FSMO roles. About the only time you can temporarily break an SBS box is when performing a migration to a new SBS box. You can join a standard server as a secondary DC, but again, you can not have two or more SBS servers in the same Forest!
I'm guessing one of two things here.
1. You performed an epic hack.
2. You really don't know what the hell your doing.
Life is not for the lazy.
Don't you get it? It has been used for 20 years. What are you complaining about?
// MD_Update(&m,buf,j);
You realize that the guide you link is not only horribly out of date (over a year IIRC since alpha11 came out) and won't work with any of the current alpha (yeah, ALPHA) releases, but that Samba 4 has it's own dNS server now, basically requiring it operate autonomously from existing infrastructure?
Yes, building/installing and then provisioning Samba 4 takes all of about 5 minutes. Now integrate it with something which was in existence before you decide to stroke your balls with Samba 4... good luck, let me know how it goes.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers