SAMBA

  Stuart Burns rolls up his sleeves and takes you through the process of setting up a Linux-based Active Directory infrastructure and how to use it.

Credit: www.samba.org

OUR EXPERT

Stuart Burns is a big Linux advocate and enjoys trying new things in Linux before sharing his findings with the world.

L ike it or not, a lot of authentication uses Active Directory (AD) to manage users and resources. It’s a staple of the Windows world and until recently (Samba 4) there was no way to have a complete AD stack in FOSS to “talk proper AD”. Luckily, with SAMBA version 4.7 and later it’s possible to build an AD controller based completely on Debian and Samba. If you follow AD all the way back it’s just Microsoft’s take on LDAP with some extra secret sauce.

This new capability is a great step forward. However, it’s important to note that while the authentication will work as expected, some items may not work. The message is, “Try this but be aware there may be some areas that present difficulties.” That said, authentication, print servers and SMB file shares should all work if correctly implemented.

The home user among us may be thinking, “This does nothing for me” but even at home, for the techie types AD can be useful. Think of all those usernames and passwords across different systems that are all managed separately. If you could just use one across the entire breadth of your eco-system, wouldn’t that be great? AD makes this possible. One simple daily example is integrating AD management into FreeNAS so that you can log in using a centralised authentication. AD provides this, as well as being able to assign domainbased rights to SMB shares.

A key part of setting up AD is its dependency on DNS. Whenever you set up an AD infrastructure in Windows for the first time it automatically installs a DNS server. Most new installations should select ‘Samba Internal’ for the DNS type. The DNS system comes as part of the AD system, but also provides standard DNS resolution. The walkthrough in this instance is being performed in a test lab. To follow along with this walkthrough the user will need a virtual machine with a static IP address. (For this example, the test AD server IP will be 192.168.1.10 with a netmask of 255.255.255. xxx and a gateway of 192.168.1.1.) The VM should also be able to download the installation packages that will be needed. For this walkthrough Debian 10 is used, but if you’re using Ubuntu it should be very similar.

It’s crucial that the AD domain isn’t a real world one, or it’ll cause problems. For example, chose itburns.lab, which isn’t a real world domain. This is important because it’s not something that can be changed later. It’s vital to lay the groundwork, too. Ensuring accurate time is critical or it can cause problems in Active Directory. VirtualBox VMs (and others) get their time from the host they sit upon, but once other machines are added the time may not be in such accurate sync. For that reason alone, if expanding beyond virtual experimentation, use a time server and make sure all clients receive their time from it.