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.
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:
Install the libkrb53 and libsasl2-modules-gssapi-mit packages.
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 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.
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
Install the krb5-user package - when prompted, the 'Default kerberos version 5 realm' should be 'LANCS.LOCAL'.
You can test that Kerberos is correctly configured with the following command:
(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'.
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).
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.
[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 = false 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 # ad_cli messes up renewal of machine account passwords ad_maximum_machine_account_password_age = 0 # 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
Install the sssd package
Replace /etc/sssd/sssd.conf with SteveB's official version:
[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 = false 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 # ad_cli messes up renewal of machine account passwords ad_maximum_machine_account_password_age = 0 # 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
Enable Kerberos for authentication, and LDAP for name lookups:
/usr/sbin/authconfig --enablesssd --enablesssdauth --update
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
getent passwd stevebshould show the passwd entry for user 'steveb', and:
groups stevebshould show a list of groups that 'steveb' is a member of, including ones defined in AD.
Edit /etc/security/access.conf, appending lines such as:
+:root:ALL +:wheel:ALL +:tig_systems_unix_admins:ALL -:ALL:ALLto 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.
Much of this information applies to all platforms and should be on a separate page.
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:
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.
So, you have your workstation set up to authenticate via AD. What can you do with it?
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.
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'