Samba 4 as an Active Directory PDC

[jgreco]

Note: FreeNAS does not yet support Samba 4.

It's a busy time. A lot of stuff going on here. I thought I'd take a few moments to drop a note here because this is probably relevant to some people here.

Like many others here, I've had a tough time over the years justifying running Windows servers for a task as lightweight as authentication services. So I generally hate Windows anyways but end up needing to support it for certain things. We've been running NT domains on Samba here for over a decade, as a result.

But that strategy is showing its age, so it is time to look forward. I've been watching the AD developments in Samba for several years, and now I am very pleased to say that "it works." At least for my small test deployment of a handful of PC's. Perhaps more shockingly, not only does it work, but there is straightforward documentation that does not involve convoluted command lines and groveling around in the innards of stuff. I was expecting this to be ... harder.

So. You need a FreeBSD machine. Or better yet a FreeBSD VM. Ours was FreeBSD 9.1R-i386 in a small VM. I'm guessing it could be made to work out of a jail as well, on FreeNAS, but I haven't tried, and this isn't a guide to doing that.

This document outlines protocol and port requirements for firewall purposes. If you're running a host-based firewall (always a good idea), here's what to exempt in order for AD to work.

# http://technet.microsoft.com/en-us/library/dd772723(WS.10).aspx
# Active Directory and Active Directory Domain Services Port Requirements

Installing Samba didn't require any special configure flags (except to relocate some stuff according to our local system deployment rules), so "./configure; gmake; gmake install" was sufficient.

Next, the Samba folks have this totally awesome Samba AD DC HOWTO. Take it up at "Provisioning Samba."

I haven't actually gotten around to setting up BIND9. The internal server seems to work well enough for an uncomplicated small network.

DNS is important to the correct operation of AD. We're in an environment where the domain in use has been delegated to the Samba server. I'm not quite clear on what the best route would be to take if you don't happen to have a domain name to operate under. My best guess is that you could just lie, use "mynetwork.internal", and point all your hosts at the Samba server for DNS requests.

Once you've done all the tests and everything looks reasonable, you're almost done. If you wish to support roaming profiles, it appears to be easiest to accomplish this on the PDC server directly. Add a share to smb.conf, and share out a UFS filesystem. Make sure you do a "tunefs -a enable /dev/gpt/profiles" (or whatever device name you used) to enable Windows style ACL's. That's pretty much the server side all done.

From here, you have to wander on over to a Windows client and use the Microsoft administration tools. Log in to your new AD domain on a Windows PC as "Administrator" using the credentials you had set up. Install WindowsServer2003-KB340178-SP2-x86-ENU.msi and you'll end up with a new program group containing "Active Directory Computers and Users". And there you go.

 

[paleoN]

DNS is important to the correct operation of AD. We're in an environment where the domain in use has been delegated to the Samba server. I'm not quite clear on what the best route would be to take if you don't happen to have a domain name to operate under. My best guess is that you could just lie, use "mynetwork.internal", and point all your hosts at the Samba server for DNS requests.

Not sure I follow you here. If you don't have a domain you simply create one in DNS. Unless, you mean you have an external domain that resolves from the internet. In which case you are surely using a spit DNS setup. It would effectively be the same setup minus the external portion, no?

 

[jgreco]

Yes, in proper use, you cannot just "simply create one in DNS." This breaks various things, depending on how poorly it is implemented, and can lead to all sorts of interesting problems. For a proper DNS setup, the domain needs to be delegated. What you're calling an "external domain", which is a really bad concept, for all the reasons Vix and other DNS purists like to pontificate about.

However, it is fairly common for people working on Microsoft networks to be completely clueless about how things should be done correctly, so I'd wager that more than half of all AD domains do not trace up to the root. Given the way Samba seems to have been designed, it looks like the AD zone is snarfed and served locally, with other requests proxied (similar in function to a combined authoritative/recursion setup).

Given a proper DNS environment, I doubt there's a valid reason to use the Samba server as your recursor. However, for the people who are likely to be experimenting with AD support, my guess is that there will be a lot of semi-broken setups. Using the Samba server as your recursor is more likely to work in that case.

Too much complexity in modern networks.

 

[paleoN]

Ok, not correct terminology.

What you're calling an "external domain", which is a really bad concept, for all the reasons Vix and other DNS purists like to pontificate about.

Put me firmly in the non-purist camp. I have no issue serving DNS locally with a made up domain, under a non-existent TLD, using private non-routable IPs.

Given a proper DNS environment, I doubt there's a valid reason to use the Samba server as your recursor. However, for the people who are likely to be experimenting with AD support, my guess is that there will be a lot of semi-broken setups. Using the Samba server as your recursor is more likely to work in that case

Yes, I don't imagine most people are buying domain names and obtaining public IPs for their home lab setups in order to be proper.

 

[jgreco]

Yes, the problem is, you're probably smart enough to actually do those things correctly, but lots of people aren't.

I don't have any idea what you're talking about public IPs for though.