User:Rudyvalencia/Active Directory integration

Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks.

This article describes how to integrate an Arch Linux system with an existing Windows domain network using Samba.

Before continuing, you must have an existing Active Directory domain and be a user with the appropriate rights to query users and add computer accounts (domain join).

This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the Active_Directory_integration#Resources section for additional information.

Introduction

This article explains how to configure an Arch Linux system to participate in an Active Directory domain. This article was written and tested on a clean installation, and it is assumed that all configuration files are unmodified. For the duration of the article, the example Active Directory domain will use the following configuration:

NetBIOS domain name: INTERNAL
DNS domain name: internal.domain.tld
Kerberos realm: INTERNAL.DOMAIN.TLD
First DC: server1.internal.domain.tld with IP address 192.168.1.1
Second DC: server2.internal.domain.tld with IP address 192.168.1.2

In most small networks, the domain controllers (DCs) also hold the DNS server role. This may not be true in larger networks. Generally, DCs also hold the NTP role, but not always. Consult your network administrator to verify correct values for DNS and NTP servers.

Terminology

If you are not familiar with Active Directory, there are a few keywords that are helpful to know.

Samba: A free/open source implementation of Windows networking services and protocols.
Domain : A collection of computers, user groups and accounts managed by Active Directory.
NetBIOS: A legacy name service used as an alternative to DNS, but still present in Windows.
Winbind: A service used by both Windows and Samba for authenticating both user and computer resources.
DNS (Domain Name System): A decentralized naming system used to identify computers reachable via a network.
SID (Security Identifier): a resource (computer, group or user) identifier unique to each entity.
SMB (Server Message Block): used by Active Directory to communicate with member computers.
WINS (Windows Information Naming Service): Used for resolving NetBIOS names to Windows hosts.

Needed software

Install the following packages:

samba;
smbclient;
pam-krb5;
ntp (required, unless you are using systemd-timesyncd); and
cups (optional, for sharing or using network printers)

For testing and troubleshooting, install:

bind (for the nslookup command); and
krb5 (for the kinit and klist commands)

To install all of the above packages with NTP, execute the following as root (optional dependencies shown in italics for brevity.):

# pacman -S samba smbclient pam-krb5 cups ntp bind krb5

Initial configuration of services

DNS configuration

Active Directory depends entirely on DNS for name resolution. It is imperative that the /etc/resolv.conf file is configured with both the correct DNS servers and a domain search suffix. Whether configured via DHCP or static configuration, ensure that these values are correct for your domain. For the example domain configuration, the following contents are appropriate (be sure to replace 192.168.1.1, 192.168.1.2, and internal.domain.tld with appropriate values for your network):

/etc/resolv.conf

nameserver 192.168.1.1
nameserver 192.168.1.2
search internal.domain.tld

If you elected to install the bind package, you can test DNS configuration with the following commands (be sure to replace server1 and internal.domain.tld with appropriate values for your network):

$ nslookup -type=SRV _kerberos._tcp.internal.domain.tld.
$ nslookup -type=SRV _ldap._tcp.internal.domain.tld.
$ nslookup server1.internal.domain.tld.

You should get output similar to the following (adjust appropriately for only one DC, or more than two):

Server:        192.168.1.1
Address:       192.168.1.1#53

_kerberos._tcp.internal.domain.tld service = 0 100 88 server1.internal.domain.tld.
_kerberos._tcp.internal.domain.tld service = 0 100 88 server2.internal.domain.tld.
...
_ldap._tcp.internal.domain.tld     service = 0 100 389 server1.internal.domain.tld.
_ldap._tcp.internal.domain.tld     service = 0 100 389 server2.internal.domain.tld.
...
Name:   server1.internal.domain.tld
Address: 192.168.1.1

NTP configuration

In an Active Directory domain, more specifically for Kerberos ticketing, it is imperative that time is synchronized will all other hosts on the network. A difference of no more than five minutes is required. For the example domain configuration, an appropriate /etc/ntp.conf or /etc/systemd/timesyncd.conf file should have the following contents (be sure to replace server1, server2, and internal.domain.tld with appropriate values for your network):

ntp.conf

/etc/ntp.conf

# Use your domain's NTP servers 
server server1.internal.domain.tld
server server2.internal.domain.tld

# Restrictions
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntpd.drift

Enable and start the ntpd.service unit.

systemd-timesyncd

/etc/systemd/timesyncd.conf

[Time]
# Use your domain's NTP servers
NTP=server1.internal.domain.tld
FallbackNTP=server2.internal.domain.tld 0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048
ConnectionRetrySec=30
SaveIntervalSec=60

Enable and start the systemd-timesyncd.service unit.

Kerberos configuration

The Samba documentation recommends a minimal Kerberos configuration, with just enough information in the [libdefaults] section to hand off the work of discovering domain details to DNS. Unfortunately, this does not work well in practice. Continuing with the example domain configuration, modify the /etc/krb5.conf file with the following contents (be sure to replace instances of INTERNAL, internal.domain.tld, SERVER1, and INTERNAL.DOMAIN.TLD with appropriate values for your network):

/etc/krb5.conf

[libdefaults]
   default_realm = INTERNAL.DOMAIN.TLD
   dns_lookup_realm = false
   dns_lookup_kdc = true

[realms]
   INTERNAL.DOMAIN.TLD = {
      kdc = SERVER1.INTERNAL.DOMAIN.TLD
      default_domain = INTERNAL.DOMAIN.TLD
      admin_server = SERVER1.INTERNAL.DOMAIN.TLD
   }
   INTERNAL = {
      kdc = SERVER1.INTERNAL.DOMAIN.TLD
      default_domain = INTERNAL.DOMAIN.TLD
      admin_server = SERVER1.INTERNAL.DOMAIN.TLD
   }

[domain_realm]
    .internal.domain.tld = INTERNAL.DOMAIN.TLD

[appdefaults]
    pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        minimum_uid = 1
    }

Samba configuration

Base Samba configuration file

A default installation of samba does not ship with an example /etc/samba/smb.conf file. For our example domain configuration, use the following base settings (replace instances of INTERNAL and INTERNAL.DOMAIN.TLD with appropriate values for your network):

/etc/samba/smb.conf

[Global]
   workgroup = INTERNAL
   security = ads
   realm = INTERNAL.DOMAIN.TLD

   # Allow offline/cached credentials and ticket refresh
   winbind offline logon = yes
   winbind refresh tickets = Yes

   # Do not require that login usernames include the default domain
   winbind use default domain = yes

   vfs objects = acl_xattr
   map acl inherit = Yes
   store dos attributes = Yes

   # Use a unified keytab to store obtained Kerberos tickets
   dedicated keytab file = /etc/krb5.keytab
   kerberos method = secrets and keytab

If you do not wish to share local printers configured in cups, then add the following to the [Global] section of the /etc/samba/smb.conf file:

/etc/samba/smb.conf

[Global]
...
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes
...

The remainder of the configuration depends on whether your domain supports RFC2307 Unix/NFS Attributes. Consult with your domain administrator if unsure.

idmap configuration for domains with RFC2307 extensions

Ensure that the UID and GID ranges below do not overlap with system ranges, that all users have at least the uidNubmer attribute, and that those users' PrimaryGroup has a gid attribute. Append the following to the [Global] section of the /etc/samba/smb.conf file (replace INTERNAL with the NetBIOS domain name):

/etc/samba/smb.conf

[Global]
...
   # UID/GID mapping for local users
   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   # UID/GID mapping for domain users
   idmap config INTERNAL : backend = ad
   idmap config INTERNAL : schema_mode = rfc2307
   idmap config INTERNAL : range = 10000-999999
   idmap config INTERNAL : unix_nss_info = yes

   # Template settings for users without ''unixHomeDir'' and ''loginShell'' attributes 
   template shell = /bin/bash
   template homedir = /home/%D/%U
...

Additionally, if user accounts in AD have a gidNumber attribute, you can use it instead of the RID for the user's Primary Group by adding the following setting to the [Global] section:

/etc/samba/smb.conf

[Global]
...
   idmap config INTERNAL : unix_primary_group = yes
...

idmap configuration for domains without RFC2307 extensions

If your administrator has not extended the AD schema to include the RFC2307 attributes, use the following idmap configuration in the [Global] section of the /etc/samba/smb.conf file (replace INTERNAL with the NetBIOS domain name):

/etc/samba/smb.conf

[Global]
...
   # UID/GID mapping for local users
   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   # UID/GID mapping for domain users
   idmap config INTERNAL : backend = rid
   idmap config INTERNAL : range = 10000-999999

   # Template settings for users
   template shell = /bin/bash
   template homedir = /home/%D/%U
...

Joining the domain

To join the AD domain, issue the following command (be sure to replace Administrator with a user that has privileges to join the AD domain):

# net ads join -U Administrator

Start the individual Samba services

Enable and start the smb.service, nmb.service, and winbind.service services.

Configure NSS

Modify the /etc/nsswitch.conf file to allow Samba to map names to user and group IDs:

/etc/nsswitch.conf

...
passwd: files systemd winbind
group: files [SUCCESS=merge] systemd winbind
...
hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname
...

Testing NSS

Verify connectivity by listing the AD domain users and groups:

# wbinfo -u
# wbinfo -g

You should get a list of AD users followed by AD groups.

Configuring PAM authentication

Rather than configuring options directly in the Linux-PAM configuration files, set defaults for the pam_winbind module in /etc/security/pam_winbind.conf:

/etc/security/pam_winbind.conf

[Global]
   debug = no
   debug_state = no
   try_first_pass = yes
   krb5_auth = yes
   krb5_ccache_type = FILE:/run/user/%u/krb5cc
   cached_login = yes
   silent = no
   mkhomedir = yes

For most services, it will be sufficient to modify only the /etc/pam.d/system-auth file. Any configuration for programs that do not include this file will also need to be modified directly. Create a backup of the /etc/pam.d/system-auth file and use the following configuration:

/etc/pam.d/system-auth

#%PAM-1.0
auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=3 default=ignore]  pam_systemd_home.so
auth       [success=2 default=ignore]  pam_unix.so          try_first_pass nullok
auth       [success=1 default=bad]     pam_winbind.so
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.
auth       optional                    pam_krb5.so          try_first_pass minimum_uid=10000

-account   [success=2 default=ignore]  pam_systemd_home.so
account    [success=1 default=ignore]  pam_unix.so
account    required                    pam_winbind.so
account    optional                    pam_permit.so
session    optional                    pam_krb5.so          minimum_uid=10000
account    required                    pam_time.so

-password  [success=2 default=ignore]  pam_systemd_home.so
password   [success=1 default=ignore]  pam_unix.so          try_first_pass nullok s>
password   required                    pam_winbind.so
password   optional                    pam_permit.so
password   optional                    pam_krb5.so          minimum_uid=10000

-session   optional                    pam_systemd_home.so
session    required                    pam_mkhomedir.so skel=/etc/skel/ umask=0022
session    required                    pam_limits.so
session    [success=1 default=ignore]  pam_unix.so
session    required                    pam_winbind.so
session    optional                    pam_krb5.so          minimum_uid=10000
session    optional                    pam_permit.so

If you have other services that do not include the /etc/pam.d/system-auth file, modify the configuration to mirror all pam_unix.so entries for pam_winbind.so and change all required to sufficient. A good example is the su configuration. Create a backup of the /etc/pam.d/su file and use the following in its place:

/etc/pam.d/su

#%PAM-1.0

auth      sufficient  pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth     required    pam_wheeel.so   trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth     required    pam_wheel.so    use_uid
auth      sufficient  pam_winbind.so
auth      required    pam_unix.so
account   sufficient  pam_winbind.so
account   required    pam_unix.so
session   sufficient  pam_winbind.so
session   required    pam_unix.so

The above pam_winbind configuration will not use the default location of the Kerberos ticket (KRB5CCNAME), which is at /tmp/krb5cc_UID. Instead, it stores the automatically refreshed Kerberos ticket to /run/user/UID/krb5cc. Add the following to the [libdefaults] section of krb5.conf to let Kerberos know the new credential cache location:

/etc/krb5.conf

[libdefaults]
   ...
   default_ccache_name = /run/user/%{uid}/krb5cc
   ...

To test your changes, start a new console or ssh session (do not exit your existing session until you have tested thoroughly) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'.

Finally, you should test login as both the root user and a local unprivileged user before logging out of your existing (working) session.

Testing Kerberos ticketing

To test that your AD user received a Kerberos ticket, issue the klist command:

$ klist

Ticket cache: FILE:/run/user/20000/krb5cc
Default principal: administrator@INTERNAL.DOMAIN.TLD

Valid starting       Expires              Service principal
12/25/2020 03:35:21  12/25/2020 13:35:21  krbtgt/INTERNAL.DOMAIN.TLD@INTERNAL.DOMAIN.TLD
        renew until 12/26/2020 03:35:15

Configuring Shares

Earlier we skipped configuration of the shares. Now that things are working, go back to /etc/samba/smb.conf, and add the exports for the host that you want available on the windows network.

/etc/samba/smb.conf

[MyShare]
  comment = Example Share
  path = /srv/exports/myshare
  read only = no
  browseable = yes
  valid users = @NETWORK+"Domain Admins" NETWORK+test.user

In the above example, the keyword NETWORK is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that Domain Admins is encapsulated in quotes so Samba correctly parses it when reading the configuration file.

Enabling SSH to use Kerberos authentication

All we need to do is add some options to our sshd_config and restart the sshd.service.

Edit /etc/ssh/sshd_config to look like this in the appropriate places:

# /etc/ssh/sshd_config

...

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
KerberosGetAFSToken yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

...

Restart the sshd.service.

Using SSSD

sssd can be used instead of Samba to integrate with AD. See SSSD documentation.

Commercial solutions

PowerBroker Identity Services
Centrify