During the install, I chose the most minimal installation package option with the addition of an SSH server.
Of course, this will probably work just as well with other distributions if you get your library dependencies right. Ubuntu may work with no modification, but I’m not sure.
Kerberos is very finicky about time. You will need an ntp server to keep your clock well synchronized.
apt-get install ntp
Also, generally I like to assign my servers static IP’s. And it also seems like the AD stuff does not like changing IP addresses once it’s been set up. Seriously. It’s probably an ingredient in the unholy glue.
edit /etc/network/interfaces
Change your “dhcp” flag to “static” and give yourself your proper address and routing info.
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
Unless you’re right on top of your DNS zone information, including PTR records, you should probably edit your /etc/hosts file too, to include the machine name you’re going to use:
edit /etc/hosts
I’m not really sure about the 127.0.1.1 entry here, but it freakishly seemed to work for me. And I’m not sure why I did it. And it may not be necessary. I think it must not be.
127.0.0.1 localhost 127.0.1.1 samba4.mydomain.com samba 192.168.1.2 samba4.mydomain.com samba # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
As for DNS, you can use Bind9 just fine with Samba 4 — but Samba 4 also has its own built-in DNS server that does that filthy injection. If you want to use Bind9 as your backend DNS server, you can, but you will need to allow the Samba 4 server to dynamically update the zone for your domain with Kerberos. There are howto’s on that. I chose to just let Samba 4 use its own built-in DNS server. Because I’m lazy. And I’m just playing for now. And I don’t like a “domain controller” being able to update my real DNS zone file.
This leads to an interesting, and by that I mean boring and unnecessary, discussion of how you should name your Active Directory “domain”. There are a few schools of thought on it, and even Microsoft has changed their tune over time on the subject. I have chosen to name my Samba 4 “domain” as a “subdomain” of my root domain – that way the Active Directory stuff doesn’t have to be authoritative for my whole domain, and I don’t have to make up a fake domain either.
And leave it to Microsoft to terribly confuse everyone by “making it easy”. By domain they do not mean a DNS domain. It’s a hybrid abomination of DNS and what is known in Kerberos as a “realm”.
So yes, well, I made Samba 4 be the DNS server, but it will also do sensible lookups to the real DNS information from my proper DNS server when it doesn’t know a name. That’s why I named it as a DNS “subdomain” (host) rather than the whole domain. For resolution:
edit /etc/resolv.conf
Now, in Ubuntu you’re going to have to do some special editing of configs to keep Network-Manager from overwriting your resolv.conf file after you make these changes.
domain mydomain.com search mydomain.com nameserver 192.168.100.2 nameserver 192.168.100.1
The first should be your Samba 4 installation IP. The second should be your real DNS server.
Probably quick & dirtiest to reboot after all this, if you like that sort of thing. BTW – make sure your /etc/hostname matches your DNS hostname. I don’t know if it’s necessary, but how can you stand it otherwise??
Debian Requirements to Compile Samba 4
I should mention, if you plan on having your Samba 4 server also be a filesharing server, and for the Active Directory stuff to manage the users and permissions for you, you need to make sure that whatever filesystem you’re going to be serving out is supporting ACL’s and extended attributes. In Debian this is a normal part of their ext4 mounts, and I think their ext3 ones as well. So you’re set!
But still, might be good to put it in, in your /etc/fstab, just as a reminder. Do, of course, use your own partition’s UUID. And whatever mountpoint you want to share.
UUID=b99750a8-9c39-11e3-82f1-525400990c6c /home ext4 user_xattr,acl 0 2
Many docs also want you to specify barrier=1 as a mount option, to make sure stuff doesn’t get corrupt in a power failure. This is enabled by default in ext4, but you may want to in ext3. And if you’re using LVM volumes, this is passed through and respected now. Ah, the wonders of the modern world.
Now, what you really want to know: which Debian packages do I need to install when compiling Samba 4? Well, how about these?
aptitude install build-essential pkg-config libacl1 acl libacl1-dev libblkid-dev libblkid1 attr libattr1 libattr1-dev libgnutls-dev libreadline-dev python-dev python-dnspython gdb libpopt-dev libldap2-dev dnsutils libbsd-dev krb5-user docbook-xsl libcups2-dev libncurses-dev libpam0g-dev libdm0-dev libfam0 fam libfam-dev xsltproc libnss3-dev docbook-xsl-doc-html docbook-xsl-ns
If you don’t have other Kerberos servers, well, I just used this server as my kerberos ones, and it works just fine. The initial realm, where it defaults to your domain name in upper-case — I made that the FQDN in upper-case as well. Apparently the realm likes to be upper-case.
Maybe you’ll want to reboot again, after the acl stuff. Maybe not. Maybe you didn’t reboot a few minutes ago, so it will only be this one reboot. Or none. I don’t care.
Compile Samba 4
The version of Samba I grabbed was their latest at the time, listed below. They may have a newer version when you read this, so always check the Samba site for the version you want.
I like compiling in /usr/src — and I’m letting Samba 4 install to its default location, which I know is a horrific violation of Debian policy. But I’m naughty.
cd /usr/src wget http://www.samba.org/samba/ftp/stable/samba-4.1.4.tar.gz tar -xzf samba-4.1.4.tar.gz cd samba-4.1.4 ./configure && make && make install
Oh, the places we’ll go.
After that completes successfully the first try and love descends upon all humanity, you might want to put the install directory into your PATH environment variable so you can avoid over-stressing your poor little phalanges. Put this in your .bashrc
export PATH=/usr/local/samba/bin:/usr/local/samba/sbin:$PATH
If you’re feeling particularly cavalier, trusting in the goodness of strangers that is. And source it! (or log out/in, open a new terminal, whatever)
I also symlinked my /usr/local/samba/etc to /etc/samba to make it less typing to edit configs:
ln -s /usr/local/samba/etc /etc/samba
Then you’ll want to make the Samba 4 stuff work. Right? First thing is to provision the so-called domain. I’m leaving it open to do some Un*x-side integration later here – that’s why the “rfc” switch.
samba-tool domain provision --use-rfc2307 --interactive
It will ask you some questions, and here’s where we get into the “domain” naming philosophy again. Just make it the same as your DNS decision above. In my example, the Realm I chose was SAMBA4.MYDOMAIN.COM
Do do the upper-case! Why? I don’t know!
And for the “Domain” I chose “MYDOMAIN” (without the .COM). It’s pretty much like your workgroup setting, is all I can figure.
If you do it this way, then all machines joining your Active Directory “domain” will get the right DNS information for your DNS zone — because the AD server will only consider itself authoritative for SAMBA4.MYDOMAIN.COM and “higher”, but not for all of MYDOMAIN.COM itself — and it will forward those DNS requests on to your proper DNS server when it doesn’t know about them.
So be sure to set your DNS forwarder here to your real DNS server.
Cold, Cruel Kerberos
I’ve never know it to be so easy. I’m leaping with joy inside. Or maybe that’s lasagna.
cd /etc cp krb5.conf krb5.conf.original cp /usr/local/samba/share/setup/krb5.conf .
Then edit your new /etc/krb5.conf and change the REALM variable to the realm you chose: SAMBA4.MYDOMAIN.COM
I know! Can you believe it! It’s here where I feel a twinge of almost… non-sickness about MS. Ok it may even be stronger than that. A little.
Reboot again. Hahaha!
You Can Dance
Now, just start Samba 4 by typing in “samba”
It will give minimal info in /var/log/syslog – mine complained about CUPS not being there, but it wasn’t enough trauma for it to die, thankfully.
Now you’ll want to set up your administrator auth-y stuff, yes?
kinit administrator@SAMBA4.MYDOMAIN.COM samba-tool user setexpiry administrator --noexpiry
Bad idea that no-expiry flag probably. But we’ve already established I’m naughty.
That’s about it! You can now fully administer it just like an Active Directory domain controller from Windows, using their remote server administration tools. Crazy, I know! That link is for Windows 8.1 download, BTW.
Also, the Samba website has a good howto on stuff like this.
The thing is, when you join a Windows machine into the “domain”, you have to make sure that you’re using your Samba 4 server as the DNS server for that machine, just like you would have to do with Microsoft’s Active Directory domain controllers. They need the filthy DNS injection.
Home Directories for Windows Users
If you want to have your Samba 4 server serve out home directories to your users, you accomplish that pretty easy. It just requires a “[home]” section in your smb.conf file.
That’s not a “[homes]” section like in Samba 3 by the way — just a singular “[home]”. It’s special. Apparently.
That section only requires a path and a not-read-only:
[home] path = /home/ read only = no
You don’t really need local accounts for your users. Samba 4 will create crazy high-numbered fictional users and groups to service your Windows throngs. Just make sure that mountpoint has the acl and xattr flags.
Oh, and your administrator account will need the “SeDiskOperatorPrivilege” I think:
net rpc rights grant 'MYDOMAIN\Domain Admins' SeDiskOperatorPrivilege -Uadministrator
This will make it so that, if you use the Windows remote administration tools in Windows, you can create users that can have a drive automatically mapped to their Windows machine when they log in, and Samba 4 will create their home directory automatically.
The setup in Windows is a little convoluted. I’m no Windows person. But here’s a step by step that I followed and it worked great.
It should also be noted that the default setup seems to allow normal workgroup functioning to continue working as well. So even if you have Windows machines that aren’t the insanely more expensive “Pro” version of Windows, you can still map to the shares like you could to a workgroup.
But then again, that begs the question, why then bother with an Active Directory Domain Controller at all? Unless you want to spend a lot more money per seat on Windows.
Final Comments
I am impressed with Microsoft’s ability to impose a standardized way of implementing LDAP in conjunction with Kerberos. I am less impressed with their shameless violations of DNS to rope this in.
I haven’t tried it yet, but apparently you can pretty easily have your Linux boxes authenticate against Samba 4 as well. I think I may not be doing that. Well, maybe I will.
It is really nice and compelling that it’s all tied together. And it’s not so bad since Samba 4’s been able to bring it into the light. I’m undecided. It seems to work well.
Anyway, I hope this helped someone. I was very daunted by the whole Active Directory integration mess at first. But these Samba guys really have done a great job. I’ll be showing them some love. Of the monetary type! Well, I suppose unless…
No comments:
Post a Comment