Let's imagine that you manage a fleet of Debian Linux servers in your Active Directory Domain Services (AD DS) environment. Your goal is to join the Linux systems to the domain to make possible truly centralized user, group, device, and resource management.
In performing preliminary research, you discover Centrify Authentication Service, a retail product that does indeed enable deep Linux integration with AD, including cross-platform Group Policy management. The problem? You can't afford the license cost, naturally.
Today I'll teach you how to join Debian Linux machines to AD by using only native tools. The upside to this procedure is that it's free; the downside is that you have to perform all housekeeping and management setup tasks manually.
Prepare the network
Joining an AD DS domain involves several Ethernet data streams that make use of various TCP/IP protocols and port IDs. Here's the "rogues' gallery" of traffic you'll need to allow on your host firewalls and network traffic control devices to allow the domain join to take place:
- UDP/TCP 135: Domain controller intercommunication
- UDP 138; TCP 139: File Replication Service (FRS)
- UDP/TCP 389: Lightweight Directory Access Protocol (LDAP)
- UDP/TCP 445: FRS
- UDP/TCP 464: Kerberos password change
- TCP 3268,3269: Global catalog (GC)
- UDP/TCP 53: Domain Name System (DNS)
Because I was unable to get my Debian Linux hosts to register their DNS records dynamically, I created the host (A) records manually on one of my AD domain controllers.
I also added the IP addresses of my domain controllers to the /etc/hosts file on the Linux servers to ensure they could resolve their names.
Prepare the Linux server
I chose to constrain today's discussion to Debian Linux because the AD join process varies a bit from one Linux distribution to another. On your candidate Linux host, fire up a terminal session and run the following command to install the realmd system:
sudo apt-get install realmd -y
The realmd system provides a nice front-end to discover and interact with identity domains (specifically Kerberos realms) such as AD.
We then use the realm command as a "Swiss Army knife" utility; we'll start by using the command to discover our AD domain. In my lab environment, my AD domain name is timw.info.
tim@linux1:~$ sudo realm discover timw.info timw.info type: kerberos realm-name: TIMW.INFO domain-name: timw.info configured: no server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin
Aha—we have some missing software dependencies. You will next need to install each of them in turn by using this pattern:
sudo apt-get install <package-name> -y
Of those dependent packages, the System Security Services Daemon (SSSD) takes center stage because it provides the underlying authentication and authorization framework for Linux interactions with AD.
Join the AD domain
Ok, let's do this! Run the following command, substituting your own AD domain name and your own domain user account (note: not a Linux local account!) that has privilege enough to join workstations to a domain:
sudo realm join timw.info -U 'pat' --install=/' --verbose
The -U parameter specifies the user account under whose security context the domain join occurs. I found that unless I added the "--install=/" clause, the realm command bombed out, complaining that I had missing dependency packages I knew were successfully installed. Ah, Linux…
If you have other errors (I had one that said "Server not found in Kerberos database"), you should add the following data to /etc/krb5.conf:
[libdefaults] rdns = false
The following screenshot shows the output Debian gave me during a successful domain join:
My Linux server now belongs to my AD domain
Next, we'll run realm again, this time to allow all AD users to log into the Linux machine:
sudo realm permit --realm timw.info --all
Finally, we'll need to enable Kerberos authentication over Secure Shell (SSH) by setting the following options in /etc/ssh/sshd_config:
#Kerberos options KerberosAuthentication yes KerberosOrLocalPasswd yes KerberosTicketCleanup yes KerberosGetAFSToken yes KerberosUseKuserok yes # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes
Verifying the domain join
As you can see in the following figure, my Linux server has a computer account in my AD domain.
At this point you can test logging into the Linux server by using an AD user account. If the login is successful, Debian should create a home directory for the user account. Be sure to use the -l (login) parameter so you can pass the User Principal Name (UPN) format of the AD user:
Subscribe to 4sysops newsletter!
ssh -l 'firstname.lastname@example.org' linux1.timw.info
As I mentioned at the start of this tutorial, in the absence of an all-in-one solution like Centrify or JumpCloud, you will doubtless need to do your homework and perform a fair amount of manual configuration and troubleshooting.