If you already have an Active Directory Domain Controller in place, diligently servicing all your needs and making itself indispensable, hopefully you’ve chosen Linux and Samba 4 to fulfill this.
If you haven’t used this free and open version of Active Directory and the domain controller, perhaps you’d like to? For the latest and greatest Samba 4 version that you compile yourself, you can follow the steps outlined for Debian Wheezy (and possibly Ubuntu).
Remember, too, that Debian backports now has a much more recent version of Samba 4 in its archives, and it seems to be working great right now.
But suppose you have that beast in place, and you want to add, say, a network file server — some storage that can be accessed by all domain users and whose rights and permissions are determined by your Active Directory domain controller.
It’s easy to just create a share on your Samba 4 Active Directory Domain Controller, and serve that out, with all the permission “goodness”. But maybe you don’t have tons of storage in that box, or in that VM, and you don’t want to, either.
Or, you could find some filthy user’s computer in the domain that has a lot of hard drive space in an array, and map it out to the others. (I mean lovely user – it’s a joke!#$@!). But we know that’s a terribly unsettling idea.
So why not build out or spin up a new Samba 4 server that’s pretty much dedicated to housing user data, whether that’s shared between the masses for apps or data, or just for daily backups.
I’ll tell you why. Because you’re frightened. How can you get one Samba server to listen to another Samba server and believe all its tales about the users and their permissions? How will the UIDs and GIDs match up for filesystem stuff? Sure, you know it’s possible. You’ve looked around. You’ve seen all kinds of insanity for linking Samba 3 into Windows AD/DC, mapping local users and huge cut-‘n-paste swaths of wild configuration blocks.
But if you go Samba 4 again, will you find any documentation that is currently to the point where Samba 4 development is? Or to the way that Debian has mutated it?
The answer is yes! All over the place, including the Samba site itself, and it’s all whacko and incomplete, if all you want to do is create a simple file server – you just want a simple Samba 4 file server that is a domain member file server. You don’t care if users can ever log into the Linux box. You just want them to have access to Windows file shares served with Windows users permissions and rights honored.
And you may think… I’ll just make a big RAID disk on some server, and serve out to my One Box To Rule Them All Samba 4 AD/DC – and then it has big drives and plenty of space! Well, it would if NFS or CIFS handled extended filesystem attributes… Alas! We are thwarted.
So here’s what I did:
You must a Samba 4 Active Directory Domain Controller running just fine already. Or a normal Windows-y one if you must run a Windows one for some nonsense reason.
You must have a Debian (or possibly Ubuntu) server ready to go with only the minimal stuff installed – like the SSH server. That’s because it’s proper. And you will be proper. Another distribution is fine of course, just don’t complain to me.
Don’t use Debian Wheezy’s version of Samba 4. It’s not ripe yet. And don’t use Samba 3. It’s overripe. (Simply too many notes) Either roll your own Samba 4 from source or enable the Debian backports repository and go with that version of Samba 4, there.
If you follow the instructions to roll your own, skip the samba-tool domain-provision step and the Cold, Cruel Kerberos sections!It makes your new Samba 4 server have delusions of grandeur and it won’t want to listen to your already-existing AD/DC.
If you go with Debian backports, this is what you’ll need:
# apt-get -t wheezy-backports install samba samba-doc samba-testsuite winbind libnss-winbind # apt-get install acl
Setting Up the Samba 4 Domain Member
The smb.conf [global] section
If you’re using the Debian version of the /etc/samba/smb.conf from backports, throw away everything in it, because it’s garbage Samba 3 stuff and they haven’t bothered tidying anything up.
For a simple Samba file server, you just need your [global] section and your share definition. I’ll highlight some of the stuff in it, after this example listing (that works just great). Be certain that your filesystem that serves out the stuff is mounted to support xattr and acl’s. (in your /etc/fstab put the mount options “user_xattr,acl” in place of “defaults”).
Anyway, here’s that /etc/samba/smb.conf file:
[global] netbios name = <servername> workgroup = <win domain> security = ADS realm = <kerberos realm> encrypt passwords = yes idmap config *:backend = tdb idmap config *:range = 70001-80000 idmap config <win domain>:backend = ad idmap config <win domain>:schema_mode = rfc2307 idmap config <win domain>:range = 3000000-4000000 winbind nss info = rfc2307 winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes
That’s it, really. I love Samba 4 for this. Consider me gushing and oozing again, all over the Samba development team again for doing such a damn fine job pulling so much together. Very well done.
Here’s what some of those things are:
- netbios name – anything you like – I like to use the hostname portion from DNS
- workgroup – that’s your Windows “domain”. Make it the same as your main Samba 4 server’s.
- realm – your Kerberos realm – again, make it the same as what your main Samba 4 server’s is.
Now, the idmap stuff should be fine for you to use, if your AD/DC is standard Samba 4. The range values are UID values that map to local users (the asterisks) and your AD users (the <win domain> ones).
By default, at least right now, Samba 4 is by default using the UID range of 3000000 – 4000000. That can be changed when you set up your Samba 4 AD/DC. A Windows-based AD/DC is probably different. Find it out, and put it there.
The local mapping range just shouldn’t overlap your domain range ones. And I kept mine well above any UIDs I’d really be using locally on this machine (in the 70000’s… 😉 )
I hate winbind. I just copy and pasted that bit from some Samba site documentation dealing with domain member servers. It seems necessary, especially the nss bit for letting your system know about domain users on the AD/DC.
The last 3 lines are critical if you want permissions to be right on the filesystem here.
The smb.conf Share Definition
Behold the glory of letting a fascist AD/DC handle all your decisions for you!
[storage] path = /srv/storage read only = no admin users = "@MYDOMAIN\Domain Admins"
Whatever path you want there, Sparky. And the MYDOMAIN bit is your domain of course, just like above. And oddly, this is the tricky one that caused me quite the headache.
After I got all this set up, I couldn’t set permissions on the share as a domain administrator. Permission denied. You have to add the “admin users” parameter even for domain administrators. I like this because it gives your local root the final authority still. But nobody mentioned this and it took forever to figure out. Here, I have the admin users be anyone @MYDOMAIN who is part of the Domain Admins group on the AD/DC.
But I digress.
The Final Steps
Of course, reload or restart this Samba daemon and its associated daemon cohorts of nmb and winbind.
# service samba restart # service winbind restart
I hope you didn’t “provision” this Samba 4 server with samba-tool…
Also, remember to edit your /etc/resolv.conf file to make sure the nameserver you’re using is your Active Directory Domain Controller. If you don’t, you won’t be able to join the domain, since it relies on that absurd DNS injection flotsam.
The next step is to join your domain as a domain member.
# net ads join -Uadministrator
No, it’s not magic. It just gets your domain info from you smb.conf file.
If you got an error, you might want to make sure that you’re using your main AD/DC server as your DNS server in /etc/resolv.conf – that is, make sure your ‘nameserver’ is set to the IP address of your primary AD/DC. If it’s not, you won’t get the revolting Microsoft DNS injection they made necessary, and you’ll fail.
Remember the NIS/YP stuff? No? Well, then just do what I say:
# edit /etc/nsswitch.conf
Then add “winbind” to the end of the passwd and group lines, while leaving the rest of the file alone:
passwd: compat winbind group: compat winbind
You might want to reboot. Make sure your mountpoint for the share you’re offering has those attributes specified in /etc/fstab.
You’ll probably want to grant your domain admins the ability to control files and permissions on your shares as well:
# net rpc rights grant 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -Uadministrator
But maybe not! I think it’s pretty well handled by specify the admin on the share level of the smb.conf file. But I did both, because I was flailing with that problem I mentioned earlier, and will not reiterate out shame.
Anyway, that’s about it. Except for, of course, always be sure you install ntp since time is so critical for this implementation with Kerberos. Just a few steps really, but lots of words and background info on why. Hope it helps.