I've come across many articles about how to join a linux system to a Microsoft Active Directory domain and they all work more or less with some tweaking. This is my article, here describing my own processes for doing it, trying to explain each bit as it comes.

Part of a "Using Linux in a Windows Domain" group of posts.
This article is for desktop Debian Linux - for setting up a PC so it can be used by a standard user of the PC.

Basics

I'll be running through the process I use for joining Debian Linux as a desktop to Active Directory. The steps should be fairly generic as they use packages available in most distributions, so adapt to your distro as required.
This follows this article quite closely, with some changes.

I use neovim as an editor, aliases to vim. If you use another editor then replace vim with your editor i.e. nano in all cases.

Required Packages

First things first we need the right packages installed. This can be done by the following command:

# apt install realmd sssd samba-common krb5-user adcli libsss-sudo sssd-tools libsasl2-modules-ldap packagekit libpam-mount
  • sssd is a set of services and tools to manage the connection to the domain.
  • pam handles general user authentication, and creation of mounts for network shares etc.
  • realmd is a tool providing a simple way to discover and join domains.
  • krb5 is a kerberos (authentication token) handler amongst other things.
  • The other packages like *-ldap, adcli are further tools use for domain administration.

For the most part, when we say realm we mean your windows "domain name". We'll be using YOURDOMAIN.LOCAL as an example.

Joining the Domain

This is at its simplest a case of configuring basic krb5 and using realm join to actually join the domain.

Configuring krb5

Edit the krb5.conf file to set the default realm:

vim /etc/krb5.conf

[libdefaults]
default_realm = YOURDOMAIN.LOCAL # Should be in CAPS

This will allow the krb5 client to identified the default realm. If you don't set this, then a realm will need to be specified with every kerberos request i.e. with kinit.

Realm Join

Realmd handles a massive amount of the work here. It used to be we had to manage a lot of this configuration ourselves, but realm now does a lot of it for us.

You can discover information about the local domain by issuing the below command

realm discover
# or
realm discover YOURDOMAIN.LOCAL

If all looks good you can join it

realm join --user={your administrator account} YOURDOMAIN.LOCAL

And to check everything is OK

realm list

which should output something like

yourdomain.local
  type: kerberos
  realm-name: YOURDOMAIN.LOCAL
  domain-name: yourdomain.local
  configured: kerberos-member
  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
  login-formats: %U@yourdomain.local
  login-policy: allow-realm-logins

Testing Connection

Technically now the computer is joined to the domain and can authenticate. You can test with:

kinit {domain user} # will authenticate as that user
klist # to show the kerberos token validity
kdestroy # deauthenticate as that user

Or, of course, log out and back in as a domain user account.

Tuning SSSD

Open up your /etc/sssd/sssd.conf file and make a few tweaks

vim /etc/sssd/sssd.conf

Most of this will already be completed in your file as realmd handled it. But check over it anyway.

[sssd]
domains = yourdomain.local
config_file_version = 2
#services = nss, pam # commented out as these are socket units which are dynamically handled by systemd
implicit_pac_responder = false # having set to true allegedly crashed some SSSD services. It's not essential.

[domain/yourdomain.local]
access_provider = ad
id_provider = ad
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = YOURDOMAIN.LOCAL
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/.krb5cc_%U
full_name_format = %1$s
realmd_tags = manages-system joined-with-adcli
fallback_homedir = /home/%u@%d
override_homedir = /home/%u@%d
ad_domain = yourdomain.local
use_fully_qualified_names = False
ldap_id_mapping = True
dydns_update = False

# This next one was a real fix for me. I had some issues where a Group Policy was unreadable which crashed SSSD and prevented the user from logging in. Windows would silently ignore it, so never an issue. I like the fact it was highlighted to me, but is not ideal for a production machine where people need to log in. So we ignore unreadable GPOs.
ad_gpo_ignore_unreadable = True

Now update the PAM modules

pam-auth-update

and make sure to check [*] Create home directory on login is enabled.
This will allow the system to validate the user again the domain, create the user's home directory and mount the user's network shares if set.

Sudo

There's a chance you may want domain administrators to have sudo privileges. This can be done by adding the following line to /etc/sudoers

%domainadmins   ALL=(ALL:ALL) ALL

Samba

Having Samba configured also helps streamline connectivity to network shares.

vim /etc/samba/smb.conf

[global]
  workgroup = yourdomain.local
  realm = YOURDOMAIN.LOCAL
  encrypt passwords = yes
  client protection = encrypt

There are a couple of further notes regarding GVFS and automatically mounting network shares in the article mentioned at the start, if you need those things in place I recommend checking through that article as well.

Testing.

We should be good to go. Let's run some tests.

Are services running?

systemctl status
# If the state is `degraded` you can see failed services by running this command
systemctl list-units --failed

I experienced some issues with SSSD failing due to unreadable GPOs mentioned above. I discovered SSSD crashed when trying to log in, and adding the SSSD option to ignore unreadable GPOs fixed it.

Login

Great! We're here. Now we can log in. Either log in using the desktop login screen, or from a terminal enter:

login {user name}

to log in as that user. The home directory should be created during login and everything is ready to go.

Automatically Mounting Shared Folders

You can edit /etc/security/pam_mount.conf.xml to enable automatic mounting of shared folders at login. I have had mixed success with this, but I'll put it here anyway:

...prefilled content...
<!-- this should go somewhere before the `<mkmountpoint ... >` block.
                <volume
                        fstype="cifs"
                        sgrp="domain users"
                        server="yourserver.yourdomain.local"
                        path="share"
                        mountpoint="~/Network Drives/Share"
                        options="vers=3.0,sec=krb5i,cruid=%(USERUID),nodev,nosuid,noexec,rw"
                />
...prefilled content...