Configuring a Linux system to be a full AD member

These instructions assume a good understanding of unix system administration. Read through them first and make sure that you understand the implications of all the parts before you begin, particularly from a system security point of view.

The examples given here have been tested on Fedora 18 and Ubuntu 12.04 Linux systems. Prior to Fedora 15, the SSSD service did not fully support Active Directory integration. Other distributions have not been tested with this configuration (please let me know if you do such a test, whether you succeed or not). If your favorite Linux distribution includes a recent version of SSSD, these instructions may also work for you (please let me know if they do).

Please send feedback on any successes or failures on this topic, or to suggest any other improvements.

Aims

The aim of this work is to produce a set of procedures to join non-Windows systems to an Active Directory domain.

A derivative of the process described here is used for scripted installations of Fedora Linux, although the machine still requires a manual step to join the machine to the domain. Contact steveb if you want to perform scripted installs in this way.

The procedure described here allows a system to be manually configured for AD authentication after installation. It requires configuration of a number of components:

All of these components should be included in a default install of Fedora Linux (version 15 or later).

Ubuntu

Install the libkrb53 and libsasl2-modules-gssapi-mit packages.

apt-get install libkrb53 libsasl2-modules-gssapi-mit

System Time

Kerberos requires that all machines involved have clocks that are reasonably accurate. You may need to run 'ntpd' or 'ntpdate'.
TODO: examples of how to configure ntpdate

Kerberos Configuration

Kerberos is a network authentication protocol that was developed at MIT in 1988. It has widespread support across unix platforms, so if it's not already installed on your system it should be readily available.

Fedora

On Fedora, the relevant packages are krb5-libs, krb5-workstation, pam_krb5, but they should be installed already.

The main configuration file for Kerberos is /etc/krb5.conf. The following example should be sufficient, but if there are other entries present you should leave them unchanged:

[libdefaults]
    default_realm = LANCS.LOCAL
    forwardable = yes
    ticket_lifetime = 10h # AD limit
    renew_lifetime = 5d   # AD limit

[domain_realm]
    .lancs.local = LANCS.LOCAL
    lancs.local = LANCS.LOCAL

Ubuntu

Install the krb5-user package - when prompted, the 'Default kerberos version 5 realm' should be 'LANCS.LOCAL'.

apt-get install krb5-user

Fedora & Ubuntu

You can test that Kerberos is correctly configured with the following command:

kinit <username>

(replace <username> with a valid AD username). You should be prompted for the password for the username, and you should see no error if the password is correct. You can list your current Kerberos tickets with 'klist' and you can destroy your current Kerberos tickets with 'kdestroy'.

Create an AD computer account

For the computer to join the domain it must have a computer account to log on with. As with Windows, you can precreate the computer account on another machine if that's more convenient. The new machine will be able to use the account without requiring any extra passwords to be typed in.

You'll need to be authenticated (via kinit) with sufficient credentials to be able to perform the join (and create the account, if it's not been precreated).

net ads join -k
If you need to create a computer account as well (i.e. it's not been precreated) you can add "createcomputer=<ou_path>" to the command. <ou_path> should be a suitable path to an OU that you have rights to create computer objects in (e.g. "University/Servers/ISS")

If you need to 're-join' the machine to the domain (for instance if you need to re-install the system), you can simply re-run the above command.

Configure SSSD

Fedora

/etc/sssd/sssd.conf:

[sssd]
debug_level = 3
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam

domains = LANCS

[nss]
debug_level = 3
filter_groups = root
filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd
reconnection_retries = 3
entry_cache_nowait_percentage = 50

[pam]
debug_level = 3
reconnection_retries = 3
offline_failed_login_attempts = 5
offline_failed_login_delay = 5
# allow PAM to cache user details for this long
# this can improve login times
# but it also delays AD changes from being seen
pam_id_timeout = 600

[domain/LANCS]
timeout = 60
debug_level = 3
dns_discovery_domain = lancs.local

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = none

ad_domain = lancs.local
ad_enable_gc = false
ldap_id_mapping = False
ldap_use_tokengroups=true
dyndns_update = false
enumerate = False
min_id = 200
cache_credentials = False
ldap_user_gecos = displayName
ad_gpo_access_control=permissive

# ignore_group_members makes getgr* omit the members field
# this vastly improves performance for things like id and sudo
# but it may need to be disabled if any of your applications
# expect to be able to read group memberships.
ignore_group_members = true

# you may wish to use these instead of the directory-provided values
#override_homedir = /home/%u
#override_shell = /bin/bash

After making any change to sssd.conf, you'll need to restart SSSD with:

systemctl restart sssd.service

Ubuntu

Install the sssd package

apt-get install sssd

Replace /etc/sssd/sssd.conf with SteveB's official version:

/etc/sssd/sssd.conf:

[sssd]
debug_level = 3
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam

domains = LANCS

[nss]
debug_level = 3
filter_groups = root
filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd
reconnection_retries = 3
entry_cache_nowait_percentage = 50

[pam]
debug_level = 3
reconnection_retries = 3
offline_failed_login_attempts = 5
offline_failed_login_delay = 5
# allow PAM to cache user details for this long
# this can improve login times
# but it also delays AD changes from being seen
pam_id_timeout = 600

[domain/LANCS]
timeout = 60
debug_level = 3
dns_discovery_domain = lancs.local

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = none

ad_domain = lancs.local
ad_enable_gc = false
ldap_id_mapping = False
ldap_use_tokengroups=true
dyndns_update = false
enumerate = False
min_id = 200
cache_credentials = False
ldap_user_gecos = displayName
ad_gpo_access_control=permissive

# ignore_group_members makes getgr* omit the members field
# this vastly improves performance for things like id and sudo
# but it may need to be disabled if any of your applications
# expect to be able to read group memberships.
ignore_group_members = true

# you may wish to use these instead of the directory-provided values
#override_homedir = /home/%u
#override_shell = /bin/bash

After making any change to sssd.conf, you'll need to restart SSSD with:

restart sssd

Configuration of PAM and NSS

Fedora

Enable Kerberos for authentication, and LDAP for name lookups:

/usr/sbin/authconfig --enablesssd --enablesssdauth --update

Ubuntu

Nothing required - installing the sssd package will do all the appropriate tweaks.

Non-Fedora & Ubuntu

On non-Fedora/Ubuntu systems you will need to edit your PAM configuration and /etc/nsswich.conf with other relevant tools, or edit them manually.
TODO: more clues about what to do on such systems

Fedora & Ubuntu

At this point you should be able to lookup user attributes, e.g.:
getent passwd steveb
should show the passwd entry for user 'steveb', and:
groups steveb
should show a list of groups that 'steveb' is a member of, including ones defined in AD.

Access control

Edit /etc/security/access.conf, appending lines such as:

+:root:ALL
+:wheel:ALL
+:tig_systems_unix_admins:ALL
-:ALL:ALL
to limit login access to specific users according to your requirements.

Some systems (e.g. Ubuntu, RHEL6) may need to enable pam_access.so in /etc/pam.d/sshd and /etc/pam.d/login for this to take effect, and may wish to use group 'sudo' rather than 'wheel'.

You should now be able to login using an AD username and password. Also, 'groups should show the AD groups that you are a member of, as well as any local memberships.


Further Notes

Much of this information applies to all platforms and should be on a separate page.

'homedir' and 'shell' attributes

The unix attributes in AD are static, so each user will receive the values on all SFU-enabled clients. There are two particular attributes for which this may be an issue: 'homedir' and 'shell'.

The 'homedir' attribute has a value in the form '/home/unix/nn/username'.

If you want users to see their networked home directories when they log in, you should arrange for automount (or something similar) to do an appropriate mount via NFS. (TODO: kerberised NFS, CIFS access).

If you want users to have local home directories you can mount your own 'home' disk at /home, or arrange for the 'home' filesystem to be accessible on this path by appropriate symbolic links.

Consider using the PAM mkhomedir module (ubuntu users: append session optional pam_mkhomedir.so to /etc/pam.d/common-session) - this creates user home directories on demand.

The 'shell' attribute has a value of '/usr/bin/local-sh' for all users. If you want all users to have a real shell, you can create a symlink, eg:

ln -s bash /usr/bin/local-sh

If you want to give different behaviour in different contexts (e.g. to allow different shells for different classes of users), local-sh can itself be a script that determines the appropriate shell and then uses exec to launch it.

Forwarding Kerberos Tickets with SSH

So, you have your workstation set up to authenticate via AD. What can you do with it?

Samba Client access

The 'smbclient' command gives command-line access to samba shares. If you use the '-k' flag, it will authenticate via kerberos. DFS redirections may (or may not) work correctly, this seems to be a name resolution issue rather than an authentication problem (e.g. //LANCS/DEPTS/... doesn't work in all cases, but //DEPTS/... does)

The GNOME file browser uses Kerberos automatically, so paths like smb://homes1/18/bloggsf should just work.

SSH

In Fedora, SSH has Kerberos support built in, so to a large extent it will just work.

However, 'ticket forwarding' is disabled by default, and if you turn it on you should only do so for hosts that you trust. Ticket forwarding allows the ticket that you use to access a service to be used to access further services, so if this is turned on you can connect from server A to server B, and then from server B to server C. This can be very convenient, but it must be understood that a connecting to an untrusted host could be a security risk.

You can enable ticket forwarding by enabling the option 'GSSAPIDelegateCredentials'. One way to do this is by editing (or creating) an ssh configuration file '~/.ssh/config':

Host server1
    GSSAPIDelegateCredentials yes

For more details see the manual page for 'ssh_config'