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.
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.
Installing on Ubuntu 14.04:
sudo apt-get install ntp
sudo bash -c 'echo "manual" > /etc/init/nmbd.override'
sudo bash –c 'echo "manual" > /etc/init/smbd.override'
sudo apt-get install samba smbclient
sudo rm /etc/samba/smb.conf
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
sudo ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf
dlz "AD DNS Zone" {
# For BIND 9.9.0
database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";
};
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
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 Administrator@AD.EXAMPLE.ORG wildcard * A AAAA SRV CNAME;
grant SERVER$@ad.EXAMPLE.ORG wildcard * A AAAA SRV CNAME;
grant DDNS wildcard * A AAAA SRV CNAME;
};
};
/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,
sudo service apparmor restart
sudo service bind9 restart
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.
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.
Successfully running an Active Directory Forest has a number of requirements need to be in place:
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.
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_DLZ
The 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:
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:
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.
sudo apt-get install winbind
[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
sudo net ads join -U Administrator
passwd: compat winbind
group: compat winbind
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:
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
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.
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.
Further resources on this subject:
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…