Building The Net

Samba 4 as an Active Directory Server – Can it dance the dance?

Two weeks ago I thought to myself ‘Gee, now that Samba 4 has a real release out, wouldn’t it be fun to test it out and see how it holds up?‘ And so my adventure began. Now mind you, I’m not a novice to Samba, or to Active Directory, so I figured this would be a simple setup and test. How hard could it be?

If you’re going to dance the Samba, you need a good dance floor.

I setup a fresh base install of Debian Wheezy (still in testing at writing) on a virtual machine, and went to install the samba4 package. Much to my surprise, the version of Samba in the Wheezy repository was still marked as the beta release. After a little research, I decided to build Samba 4 from source and follow the howto on the official Samba Wiki. Here is the link. The howto was pretty accurate for a single server setup. It requires a few additional tweaks if you plan to use it with Unix hosts as well. As a matter of fact, the actual process of installing the OS and required compilers and libraries, getting the source downloaded and configured, and building the software itself, is pretty straight forward.

Wait… This is very strange…

As I said in the first paragraph, I consider myself pretty knowledgeable when it comes to Samba… I’ve been deploying Samba solutions for clients for many years, and like to think I do a spot on job of it. So my first thought was that I would just setup a smb.conf file with some new settings, restart the daemon and have a fully functional AD controller. Boy, was I ever wrong… The further and further into the setup I got, the more and more I grew to realize that this was not my old comfortable Samba 3 software… This was… well… this was different… very different! As I started to read about how to setup the system, I came to realize that the new Samba 4 software I was working with was going to change everything I’d come to expect from Samba as a whole. Here are some things I didn’t expect that caused me have to rethink the way I normally would deploy Samba:

• Samba 4 no longer supports an external LDAP server
• Samba 4 requires Kerberos
• Samba 4 AD users do not have to be in Unix users
• All documentation states that you should be managing the Samba 4 server through a windows client.
• Samba 4 uses it’s own internal DNS server by default, and should be used for the AD.

In short, the Samba server will be the single point of authentication and domain control for the entire network. Needless to say, I was a bit taken back by all this. In my world, flexibility is the goal. This can’t be the solution that the Samba team has come up with…

Now, in defense of the Samba team, I did a bit of research, and now realize that their choice to internalize all the required services under one configuration, actually reduces the setup complexity that would be inevitable if all of the services were not controlled by one software package. So, like it or not, if you need Samba to work as an Active Directory Domain Controller, it will be your everything…

When in doubt, surge forward!

So, after realizing that regardless of my concerns surrounding the ‘Samba 4 will be all powerful’ issue, it still was my job to at least evaluate it. So, forward with the configuration we went!

Step one was to run the command that would setup the Active Directory. This was actually pretty easy! I just ran ‘samba-tool domain provision’ and answered all the questions. Once it was done, I copied the krb5.conf file from the private directory over to the /etc/ directory. Continuing with the HowTo on the Samba Wiki, I created some shares, and moved over to a Windows PC to see if I could actually join the new Active Directory.

Oh, there was one little thing that wasn’t really clear in the HowTo… How to setup the [homes] section. It is a little different:

[homes]
        path = /home
        read only = No

Notice that there are no macros in this such as %U or %S. Apparently Samba 4 ignores them, but no worries, it now shares the associated home directory from the user’s Active Directory account and uses this path to find it.

Windows for Samba Management.

First, I had to make sure that the windows system was pointed toward the samba server for it’s DNS. Once that was done, I attempted to join the new Samba Active Directory. And to my amazement, it worked! Then I had to download the Windows Remote Administration Tools and get them installed on the windows system. This took a bit of time, as it does some patching while it’s at it. Then, the moment of truth… After opening the ‘Users and Computers’ program, I successfully created a new AD user, and set up their home directory! I couldn’t believe it! I also was able to edit the DNS through the DNS manager.

I was a bit struck with the whole concept… I mean, did this mean that someone with AD management experience could manage this network? Well, yes, I think so… This was big!

Of course, there were a few little things…

• Changes were a bit slow in saving.
• User directories created from the remote manager were accessible by other users.
• File security settings were a bit off all the way around.
• Printing is still a bit kludged.

But all and all… It worked, and with a bit more work, I got winbind working so I could fix the file permissions using ‘setfacl’ on the unix side.

Oh! and bonus! I can use winbind for nsswitch and pam so all the users truly can be kept in AD!

Oh, about that winbind for nss and pam bonus…

I hinted a bit in the first paragraph about the amount of time I spent on this project. It was close to two weeks. Why? Because I wanted to figure out how to fix the file permissions and allow users to log into the Samba box itself. I also wanted to see what it would take to share numeric IDs across the network to other Unix file systems shared by NFS. Sadly, the required settings and build settings were scattered about the wiki, or not really referenced at all. I did get some stellar help from the mailing list, and that did make it possible to get it all working.

So, am I running out to all my friends and telling them to Upgrade?

Not exactly… See, most of my customer base use Samba with LDAP authentication. They have all sorts of other programs and applications that depend on that LDAP information. Right now, Samba 4 is a bit shy when in comes to adding additional LDAP schemas to their native LDAP server, so for these customers, it might be a bit of a stretch for them to Samba 4 at this time. But, it’s open source, and it will evolve, it always does.

And, even though you can change almost all settings from the windows workstation, I still found some things that didn’t really work the way I thought they should have. The one that comes to mind was the way the remote manager created the home directories. It really required a bit of work to make them private to the user that owned them. I ended up developing some scripts to create users on the Unix command line, but I tend to lean toward the Unix toolbox for my fixes. <g>

For now, I’m telling folks to consider Samba 4 only if they are going to re-tool their user authentication model. I’m also telling our Windows Server customers to consider adding a Samba 4 domain controller as a backup controller for their network.

So, thanks for reading this… I left out a lot of the frustration and headaches I experienced doing this project. I’ll probably voice more of that in the video when I release it. Stay tuned!

— Stu