Steve Bennett
last updated: 30/03/2010
last updated: 30/03/2010
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.
These instructions are old and haven't been updated for over a year. Use the new instructions if you can.
The examples given here apply specifically to Fedora systems, but should be relevant to other distributions and variants of unix.
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.
Nearly all of the procedure has been successfully automated. The manual procedure currently consists of 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:
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:
[logging]
default = FILE:/var/log/krb5libs.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = LANCS.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[domain_realm]
.lancs.local = LANCS.LOCAL
lancs.local = LANCS.LOCAL
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
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'.
We don't actually need the samba service, but the tools provided with samba make it very straightforward to join the domain.
We need a minimal samba configuration in /etc/samba/smb.conf:
[global]
workgroup = LANCS
hosts allow = 127.0.0.0/8 10.0.0.0/8 148.88.0.0/16 194.80.32.0/21
log file = /var/log/samba.log
max log size = 50
security = ads
realm = LANCS.LOCAL
password server = *
use kerberos keytab = true
wins server = 148.88.5.82
If you are already using samba, you will need to merge these settings with what you are already using.
Get your creds right first:
Where <adminusername> is a username with rights to create a computer account. Then:
net ads join createcomputer="<OU>" createupn
Where <OU> should be replaced by an OU that you have rights to create computer accounts in. The OU is relative to the Directory root, with components separated by slashes, e.g. "University/Servers/ISS".
You will be prompted to enter a password. It appears to be safe and correct to just press 'Return'.
net ads join createcomputer="<OU>" createupn -U <user>Where <user> is your (admin?) username. You will be prompted to enter your password.
You can check that a machine is correctly joined with:
net ads testjoin
/usr/local/sbin/kinit_nssldap_ccache:
#!/bin/bash
HOSTNAME=`hostname | sed 's/\.lancs.ac.uk//' | tr '[a-z]' '[A-Z]'`
/usr/kerberos/bin/kinit -k host/${HOSTNAME} -c /tmp/.ldapcache && \
chown nscd /tmp/.ldapcache
Ensure that this works:
chmod +x /usr/local/sbin/kinit_nssldap_ccache /usr/local/sbin/kinit_nssldap_ccache
This should run without errors, and should leave a file in '/tmp/.ldapcache'.
Now configure kinit_nssldap_ccache to run periodically - add the following to root's crontab:
@reboot /usr/local/sbin/kinit_nssldap_ccache @hourly /usr/local/sbin/kinit_nssldap_ccache
host lancs-dc0.lancs.local lancs-dc1.lancs.local lancs-dc2.lancs.local lancs-dc3.lancs.local base ou=University,dc=LANCS,dc=LOCAL timelimit 120 bind_policy soft 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 msSFU30Name nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute uniqueMember member nss_map_attribute gecos displayName nss_map_objectclass posixAccount User nss_map_objectclass posixGroup Group #nss_default_attribute #nss_override_attribute nss_schema rfc2307bis nss_initgroups backlink nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd # PAM settings pam_login_attribute msSFU30Name pam_filter objectclass=User #pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com #pam_member_attribute uniqueMember pam_min_uid 500 pam_max_uid 0
Turn nscd on:
/sbin/chkconfig nscd on /etc/init.d/nscd start
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
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.
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'