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 12 (and ubuntu 10.10 Server) Linux systems, they may work on older versions, but that hasn't been tested. The information here should also be relevant to other recent Linux distributions as well as other unix variants.
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.
Work is in progress to fully automate this process for scripted installations. The procedure described here allows a system to be manual configured for AD authentication after installation. It requires configuration of a number of components:
On a reasonably default Fedora installation I found that I needed to add the following packages:
The following command should be sufficient:
On a default ubuntu installation I found that I needed to add the following packages:
The following command should be sufficient:
When prompted to configure the packages, these values are sensible:
I configured and built msktutil with:
Ubuntu does not require CPPFLAGS to be set
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.
On Ubuntu, the relevant packages are krb5-user, libpam-krb5, which you installed earlier. The generated krb5.conf is valid, so Ubuntu users don't need to replace the configuration.
The main configuration file for Kerberos is /etc/krb5.conf. The following example should be sufficient for most systems:
[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
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 create the computer account in the OU.
Run the following from any machine with msktutil installed.
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.
TODO: precreation and account resetting from dsa.msc does not seem to work, we need to work out why/usr/local/sbin/ad_creds_renew:
#!/bin/bash HOSTNAME=`hostname | sed 's/\.lancs.ac.uk//' | tr '[a-z]' '[A-Z]'` KRB5CCNAME=/tmp/.ldapcache [ "$1" = "rnd_delay" ] && sleep `expr $RANDOM % 600` [ "$1" = "boot_wait" ] && until netstat -rn | grep -q ^0.0.0.0; do sleep 1; done /usr/local/bin/msktutil --computer-name $HOSTNAME --auto-update && \ /usr/kerberos/bin/kinit -k $HOSTNAME\$ -c $KRB5CCNAME && \ chown nscd $KRB5CCNAME
Ensure that this works:
chmod +x /usr/local/sbin/ad_creds_renew /usr/local/sbin/ad_creds_renew
Ubuntu users: nscd runs as 'root', so remove the final chown from this script.
This should run without errors, and should leave a file in '/tmp/.ldapcache'.
Now configure ad_creds_renew to run periodically - add the following to root's crontab:
@reboot /usr/local/sbin/ad_creds_renew boot_wait @hourly /usr/local/sbin/ad_creds_renew rnd_delay
nss_srv_domain lancs.local base ou=University,dc=LANCS,dc=LOCAL timelimit 120 bind_policy soft idle_timelimit 3600 use_sasl on sasl_secprops maxssf=0 krb5_ccname FILE:/tmp/.ldapcache nss_paged_results yes nss_base_passwd ou=Users,ou=University,dc=LANCS,dc=LOCAL nss_base_group ou=Groups,ou=University,dc=LANCS,dc=LOCAL nss_map_attribute uid sAMAccountName nss_map_attribute shadowLastChange pwdLastSet nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute uniqueMember member nss_map_attribute gecos displayName nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup Group nss_schema rfc2307bis nss_initgroups backlink nss_getgrent_skipmembers yes nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd # PAM settings pam_login_attribute sAMAccountName pam_filter objectclass=User pam_min_uid 500
Turn nscd on:
/sbin/chkconfig nscd on /etc/init.d/nscd start
Ubuntu users: nscd starts by default when it is installed, so nothing to do here.
TODO: check if tuning the limits in nscd has any worthwhile effect on performance
Enable Kerberos for authentication, and LDAP for name lookups:
/usr/sbin/authconfig --enablekrb5 --enableldap --update
On non-Fedora systems you will need to edit your PAM configuration
and /etc/nsswitch.conf with other relevant tools, or edit them manually.
TODO: more clues about what to do on non-Fedora systems
Ubuntu users: Alter nsswitch.conf to use 'files ldap' for various databases, instead of compat:
passwd: files ldap group: files ldap shadow: files ldapEdit /etc/pam.d/login and /etc/pam.d/sshd to uncomment the 'pam_access.so' line. 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 only.
Ubuntu: Consider using the 'admin' group rather than 'wheel' and including the 'local' account created during installation to allow emergency access
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).
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 appear to work correctly, although there seems to be a name resolution issue with domain-based DFS (for example, //LANCS\DEPTS/... doesn't work, but //LANCS.LOCAL/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'