jgreco
Resident Grinch
- Joined
- May 29, 2011
- Messages
- 18,680
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.
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.