In this article by Gregory Boyce, author Linux Networking Cookbook, we will focus on getting you started by Configuring Samba as an Active Directory compatible directory service and Joining a Linux box to the domain.
(For more resources related to this topic, see here.)
If you have worked in corporate environments, then you are probably familiar with a directory service such as Active Directory. What you may not realize is that Samba, originally created to be an open source implementation of Windows file sharing (SMB/CIFS), can now operate as an Active Directory compatible directory service. It can even act as a Backup Domain Controller (BDC) in an Active Directory domain. In this article, we will configure Samba to centralize authentication for your network services. We will also configure a Linux client to leverage it for authentication and set up a RADIUS server, which uses the directory server for authentication.
Configuring Samba as an Active Directory compatible directory service
As of Samba 4.0, Samba has the ability to act as a primary domain controller (PDC) in a manner that is compatible with Active Directory.
How to do it…
Installing on Ubuntu 14.04:
- Configure your system with a static IP address and update /etc/hosts to point to that IP address rather than localhost.
- Make sure that your time is kept up to date by installing an NTP client:
sudo apt-get install ntp - Pre-emptively disable smbd/nmbd from running automatically:
sudo bash -c 'echo "manual" > /etc/init/nmbd.override' sudo bash –c 'echo "manual" > /etc/init/smbd.override' - Install Samba and smbclient:
sudo apt-get install samba smbclient - Remove stock smb.conf:
sudo rm /etc/samba/smb.conf - Provision the domain:
sudo samba-tool domain provision --realm ad.example.org --domain example --use-rfc2307 --option="interfaces=lo eth1" --option="bind interfaces only=yes" --dns-backend BIND9_DLZ - Save the randomly generated admin password.
- Symlink the AD krb5.conf to /etc:
sudo ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf - Edit /etc/bind/named.conf.local to allow Samba to publish data:
dlz "AD DNS Zone" { # For BIND 9.9.0 database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so"; }; - Edit /etc/bind/named.conf.options to use the Kerberos keytab within the options stanza:
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab"; - Modify your zone record to allow updates from Samba:
zone "example.org" { type master; notify no; file "/var/lib/bind/example.org.db"; update-policy { grant AD.EXAMPLE.ORG ms-self * A AAAA; grant [email protected] wildcard * A AAAA SRV CNAME; grant [email protected] wildcard * A AAAA SRV CNAME; grant DDNS wildcard * A AAAA SRV CNAME; }; }; - Modify /etc/apparmor.d/usr.sbin.named to allow bind9 access to a few additional resources within the /usr/sbin/named stanza:
/var/lib/samba/private/dns/** rw, /var/lib/samba/private/named.conf r, /var/lib/samba/private/named.conf.update r, /var/lib/samba/private/dns.keytab rk, /var/lib/samba/private/krb5.conf r, /var/tmp/* rw, /dev/urandom rw, - Reload the apparmor configuration:
sudo service apparmor restart - Restart bind9:
sudo service bind9 restart - Restart the samba service:
sudo service apparmor restart
Installing on CentOS 7:
Unfortunately, setting up a domain controller on CentOS 7 is not possible using the default packages provided by the distribution. This is due to Samba utilizing the Heimdal implementation of Kerberos while Red Hat, CentOS, and Fedora using the MIT Kerberos 5 implementation.
How it works…
The process for provisioning Samba to act as an Active Directory compatible domain is deceptively easy given all that is happening on the backend. Let us look at some of the expectation and see how we are going to meet them as well as what is happening behind the scenes.
Active Directory requirements
Successfully running an Active Directory Forest has a number of requirements need to be in place:
- Synchronized time: AD uses Kerberos for authentication, which can be very sensitive to time skews. In our case, we are going to use ntpd, but other options including openntpd or chrony are also available.
- The ability to manage DNS records: AD automatically generates a number of DNS records, including SRV records that tell clients of the domain how to locate the domain controller itself.
- A static IP address: Due to a number of pieces of the AD functionality being very dependent on the specific IP address of your domain controller, it is recommended that you use a static IP address. A static DHCP lease may work as long as you are certain the IP address will not change. A rogue DHCP server on the network for example may cause difficulties.
Selecting a realm and domain name
The Samba team has published some very useful information regarding the proper naming of your realm and your domain along with a link to Microsoft’s best practices on the subject. It may be found on: https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ.
The short version is that your domain should be globally unique while the realm should be unique within the layer 2 broadcast domain of your network.
Preferably, the domain should be a subdomain of a registered domain owned by you. This ensures that you can buy SSL certificates if necessary and you will not experience conflicts with outside resources.
Samba-tool will default to using the first part of the domain you specified as the realm, ad from ad.example.org. The Samba group instead recommends using the second part, example in our case, as it is more likely to be locally unique.
Using a subdomain of your purchased domain rather than a domain itself makes life easier when splitting internal DNS records, which are managed by your AD instance from the more publicly accessible external names.
Using Samba-Tool
Samba-tool can work in an automated fashion with command line options, or it can operate in interactive mode. We are going to specify the options that we want to use on the command line:
sudo samba-tool domain provision --realm ad.example.org --domain example --use-rfc2307 --option="interfaces=lo eth1" --option="bind interfaces only=yes" --dns-backend BIND9_DLZThe realm and domain options here specify the name for your domain as described above.
Since we are going to be supporting Linux systems, we are going to want the AD schema to support RFC2307 settings, which allow for definitions for UID, GID, shell, home directory, and other settings, which Unix systems will require.
The pair of options specified on our command-line is used for restricting what interfaces Samba will bind to. While not strictly required, it is a good practice to keep your Samba services bound to the internal interfaces.
Finally, samba wants to be able to manage your DNS in order to add systems to the zone automatically. This is handled by a variety of available DNS backends. These include:
- SAMBA_INTERNAL: This is a built-in method where a samba process acts as a DNS service. This is a good quick option for small networks.
- BIND9_DLZ: This option allows you to tie your local named/bind9 instance in with your Samba server. It introduces a named plugin for bind versions 9.8.x/9.9.x to support reading host information directly out of the Samba data stores.
- BIND_FLATFILE: This option is largely deprecated in favor of BIND9_DLZ, but it is still an option if you are running an older version of bind. It causes the Samba services to write out zone files periodically, which Bind may use.
Bind configuration
Now that Samba is set up to support BIND9_DLZ, we need to configure named to leverage it. There are a few pieces to this support:
- tkey-gssapi-keytab: This settings in your named options section defines the Kerberos key tab file to use for DNS updates. This allows the Samba server to communicate with the Bind server in order to let it know about zone file changes.
- dlz setting: This tells bind to load the dynamic module which Samba provides in order to have it read from Samba’s data files.
- Zone updating: In order to be able to update the zone file, you need to switch from an allow-update definition to update-policy, which allows more complex definitions including Kerberos based updates.
- Apparmor rules changes: Ubuntu uses a Linux Security Module called Apparmor, which allows you to define the allowed actions of a particular executable. Apparmor contains rules restricting the access rights of the named process, but these existing rules do not account for integration with Samba. We need to adjust the existing rules to allow named to access some additional required resources.
Joining a Linux box to the domain
In order to participate in an AD style domain, you must have the machine joined to the domain using Administrator credentials. This will create the machine’s account within the database, and provide credentials to the system for querying the ldap server.
How to do it…
- Install Samba, heimdal-clients, and winbind:
sudo apt-get install winbind - Populate /etc/samba/smb.conf:
[global] workgroup = EXAMPLE realm = ad.example.org security = ads idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%U template shell = /bin/bash winbind use default domain = yes - Join the system to the domain:
sudo net ads join -U Administrator - Configure the system to use winbind for account information in /etc/nsswitch.conf:
passwd: compat winbind group: compat winbind
How it works…
Joining a Linux box to an AD domain, you need to utilize winbind that provides a PAM interface for interacting with Windows RPC calls for user authentication. Winbind requires that you set up your smb.conf file, and then join the domain before it functions. Nsswitch.conf controls how glibc attempts to look up particular types of information. In our case, we are modifying them to talk to winbind for user and group information.
Most of the actual logic is in the smb.conf file itself, so let us look:
- Define the AD Domain we’re working with, including both the workgroup/domain and the realm:
workgroup = EXAMPLE realm = ad.example.org - Now we tell Samba to use Active Directory Services (ADS) security mode:
security = ads - AD domains use Windows Security IDs (SID) for providing unique user and group identifiers. In order to be compatible with Linux systems, we need to map those SIDs to UIDs and GIDs. Since we’re only dealing with a single client for now, we’re going to let the local Samba instance map the SIDs to UIDs and GIDs from a range which we provide:
idmap uid = 10000-20000 idmap gid = 10000-20000 - Some unix utilities such as finger depend on the ability to loop through all of the user/group instances. On a large AD domain, this can be far too many entries so winbind suppresses this capability by default. For now, we’re going to want to enable it:
winbind enum users = yes winbind enum groups = yes - Unless you go through specific steps to populate your AD domain with per-user home directory and shell information, then Winbind will use templates for home directories and shells. We’ll want to define these templates in order to avoid the defaults of /home/%D/%U (/home/EXAMPLE/user) and /bin/false:
template homedir = /home/%U template shell = /bin/bash - The default winbind configuration takes users in the form of [email protected] rather than the more Unix style of user username. Let’s override that setting:
winbind use default domain = yes
Joining a windows box to the domain
While not a Linux configuration topic, the most common use for an Active Directory domain is to manage a network of Windows systems. While the overarching topic of managing windows via an AD domain is too large and out of scope for this articl, let’s look at how we can join a Windows system to our new domain.
How to do it…
- Click on Start and go to Settings.
- Click on System.
- Select About.
- Select Join a Domain.
- Type in the name of your domain; ad.example.org in our case.
- Enter your administrator credentials for the domain.
- Select a user who will own the system.
How it works…
When you tell your Windows system to join an AD Domain, it first attempts to find the domain by looking up a series SRV record for the domain, including _ldap._tcp.dc._msdcs.ad.example.org in order to determine what hosts to connect to within the domain for authentication purposes. From there a connection is established.
Resources for Article:
Further resources on this subject:
- OpenStack Networking in a Nutshell [article]
- Zabbix Configuration [article]
- Supporting hypervisors by OpenNebula [article]