Learn how to bind a Debian Linux-based server to an Active Directory (AD) domain without purchasing third-party software.
Latest posts by Timothy Warner (see all)

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
  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:

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.

Linux server in an AD domain

Linux server in an 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 'pat@timw.info' 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.

  1. Avatar
    tmack (Rank 2) 4 years ago

    Until Microsoft makes Add-Computer do this PowerShell will never be accepted into the Linux community … IMO.

  2. Avatar
    Torsten Zenk 3 years ago

    Hey Tim,
    thanks very much for the writeup. Quick and easy and very fast, compared to many other solutions.

Leave a reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account