How-to Guide Joining Linux to Active Directory for Windows Admins

You're probably here because you've decided to join a Linux machine to your beloved Active Directory. If so, excellent! If instead you're here for cat videos, comics or the like, I'm afraid you're going to be very bored.

Assumptions

I'm going to make a few assumptions about you, dear reader. If you feel they're not appropriate, you may want to grab some assistance from other experienced people.

• You know how to build and administer Windows systems and Active Directory (let's say roughly equivalent to the MCSA credential or the previous MCTS Windows Administrator);
• You have appropriate rights to join computers to Active Directory;
  
• You have root access to the Linux machine (either sudo -s or su - is fine, as is a local root login)
  
• You know how to install packages on the Linux machine;
• You know how to edit files on the Linux machine.

I'm also going to assume the following about your world:

• You have working DNS, DHCP and enough Internet connectivity to add packages (or you can use ISOs);
  
• Domain controllers are online and reachable, and so on.
• Debian is your platform; Ubuntu should be nearly identical, but Centos/RHEL will be a little different.
• Your AD domain names are DOMAIN / domain.example.com and your AD username is Daffy
  
• Your Linux computer is called LinuxPC

Background

Let's review what happens when you join a reasonably modern Windows computer to a (simple) AD domain:

• The computer's DNS suffix is set to the AD domain name;
• The computer registers itself in DNS automatically;
• The computer is rebooted, then downloads and applies group policy;
• You can logon to the computer by specifying either a Pre-Windows 2000 logon name (that's DOMAIN\User) or a UPN (User@dns.domain.example.com)
• Domain Admins have administrative rights on the computer
• You can configure services to run as domain accounts.

Most of the guides for joining computers to an Active Directory environment are written from the point of view of the Linux expert. And the tools to join the domain also do things the Linux Way. This is to be expected and is not a bug.

Basic Domain Join

We need to install the Linux packages to support AD membership. On Debian this is normally just a case of installing realmd, sssd, ntp and adcli:

# apt-get install realmd sssd adcli ntp

Per [1], configure sssd to start at boot:

# systemctl enable sssd

You should now be able to discover the AD environment with realmd:

# realm discover domain.example.com

If that's successful, you can join with:

# realm join --user=Daffy domain.example.com

Obviously, enter your password when prompted.

Assuming it is successful, at this point you can authenticate, but if you try to log in you won't have a home directory, so you'll probably get disconnected immediately. Edit /etc/pam.d/common-session and add a line to the end, so that a successful login creates the home directory with the standard (skeleton) content:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

And we're done with step 1. Would not be possible for me to write this without Alan's notes (reference 1).

Register DNS Names

By default, sssd will not register the workstation or server name in DNS automatically. What may be confusing (and will bite you in the rear not now, not in a few days, but probably when DNS is next tweaked, scavenged etc) is that sssd will update an existing name, but not register a new one. Let's fix that with a set of changes to /etc/sssd/sssd.conf. It's the old .INI file format, so you should be familiar with it.

Under your domain entry add a few lines (note that some of these are supposedly also the defaults, but because I've seen really weird results, I'm specifying explicitly):

[domain/domain.example.com]
ad_hostname = linuxpc.domain.example.com
dyndns_update = true
dyndns_ttl = 3600
dyndns_refresh_interval = 43200
dyndns_update_ptr = true

Save the file, and restart sssd:

# systemctl restart sssd

Your DNS name should magically be registered. If you want to set the DNS domain name, go ahead and do that now (with the domainname command).

Allow Logon with Username Only

OK at this point you've probably tried to logon and discovered that you need to use the UPN (email address format) or it doesn't work. That might be what you want; if not, head on back to /etc/sssd/sssd.conf. Under your domain entry, update or add this line:

use_fully_qualified_names = false

And restart sssd for the change to take effect. Now, you can log on as a domain user with just your username. You can also log on as DOMAIN\User or User@domain.example.com.

Domain Admins are Administrators ... I mean root

You will probably want to grant sudo access to one or more domain groups or users. I'll use Domain Admins here, because that's "normal", but you should consider whether your "Workstation Admins" or "Level 1" or other special groups are better suited.

Create an appropriately named file in /etc/sudoers.d - I like to name it so that it matches the AD object name, so for this example it will be /etc/sudoers.d/DOMAIN_DomainAdmins, and include this line:

%Domain\ Admins@domain.example.com ALL=(ALL) ALL

Domain Admins will now be able to undertake any task using sudo. You can obviously lock this down as needed to specific groups and tasks/functions too, but that's outside the scope of this simplistic guide.

Running a Daemon as an AD Account

Now, this is probably not needed often but you may find that you want a service to run as a particular user especially if it's updating fileservers (e.g. a filesystem exported for NFS and shared via SMB).

When you create your service definition for systemd, include these lines:

[Unit]
...
Requires=sssd.service
After=network-online.target sssd.service

[Service]
...
User=DomainUser
Group=Domain Users

I have several daemons running in this manner on a couple of hosts. Resolves quite a few weird permissions problems.

References

[1]: Joining Debian 8 to Active Directory |
[2]: 2.6. Additional Configuration Examples
[3]: CentOS 7, Active Directory and Samba