This guide describes the steps necessary to make make workstations a part of the justdavis.com network. The network provides the following services:
- Kerberos Authentication: Used by Windows and Linux workstations to authenticate login user names and passwords. Also allows for Single-Sign-On to various services.
- The configuration of this service is described in the following guide: Eddings Kerberos Server
- LDAP Directory: Used by Linux workstations to determine centralize users and groups.
- The configuration of this service is described in the following guide: Eddings LDAP Server
- OpenAFS File Server: Used by Windows and Linux workstations as a centralized file server.
Previously, workstations had been joined to the davisonlinehome.name network. It provided the same services, but has since been decommissioned in favor of the new justdavis.com network.
Windows Vista
Kerberos Login Setup
References:
- http://web.mit.edu/Kerberos/kfw-3.2/kfw-3.2.2/relnotes.html#mslsa
- http://technet.microsoft.com/en-us/library/cc738673.aspx
Windows Vista has basic support for Kerberos logins. However, it does not support the use of LDAP directories, so user accounts will have to be manually created and mapped to their corresponding Kerberos identities.
Install all required dependencies:
- Heimdal Kerberos for Windows:
- Download the latest version from Heimdal Kerberos from Secure Endpoints.
- Install it.
- Windows Server 2003 Support Tools:
- Windows Server 2003 Resource Kit:
Create a Kerberos host principal for the computer’s FQDN. For these principals, it is recommended that you create a very complex randomized password. This password will need to be written down (it will be used again later). This process will likely have to be done on a Linux workstation that can connect to the Kerberos server (replace hostname.domain with the computer’s FQDN):
$ kadmin -p karl/admin
kadmin: addprinc -policy hosts host/hostname.domain
Please note: generally, it’s a good idea to use the -randkey flag to addprinc. However, there’s no way to capture the password generated by that, and we will need to enter the password manually on the Windows computer.
Configure Kerberos authentication for the client workstation. The following commands must be run from a Command Prompt that has been launched by right-clicking the application icon and selecting Run as administrator (ignore comment lines starting with a #):
# Add the realm and KDC (via DNS):
> KSETUP /AddKdc JUSTDAVIS.COM kerberos.justdavis.com
# Add the Kerberos admin server:
> KSETUP /AddKpasswd JUSTDAVIS.COM kerberos.justdavis.com
# Assign the realm:
> KSETUP /SetRealm JUSTDAVIS.COM
# Set the computer's host principal password (replace <Password> with the password created earlier for the host/hostname.domain principal):
> KSETUP /SetComputerPassword "<Password>"
# Map realm principals to local accounts of the same name:
> KSETUP /MapUser * *
Local user accounts should be created for each network user that will be logging in to the workstation. For example, a local user account named karl should be created if the karl@JUSTDAVIS.COM network user will be using the workstation, erica for erica@JUSTDAVIS.COM, etc. These user accounts can be used in one of two modes:
.\usernameorhostname\username: Login to local user account only, where the ‘.’ is an abbreviation for the local workstation’s hostname. If users login using a username of this form, they will need to use the local user account’s password (if any) and will have access to any files stored in the local user account. They will not have access to any resources secured by the network user account, e.g. AFS servers.username@JUSTDAVIS.COM: Login to network identity under the local user account. If users login using a username of this form, they will need to use the Kerberos principal’s password and will have access to resources available to both the local user account and any resources accessible to the Kerberos user.
Before logging in, the computer must be restarted for the KSETUP commands above to be applied. Please note that further setup will be needed for most Kerberos-secured network resources to become available. See the section(s) below for more information.
OpenAFS Setup
The OpenAFS project provides extensive support for Windows clients in addition to Linux ones. This support requires the installation and configuration of three components:
- a Kerberos API provider, e.g. Heimdal or MIT
- the Network Identity Manager application
- the OpenAFS client libraries and applications
Of the two Windows Kerberos libraries available, Heimdal and Kerberos, Heimdal seems to be the better choice. Download and install the latest release for your architecture from the following page: Heimdal Kerberos for Windows from Secure Endpoints.
After installation, add the following entry to the [libdefaults] section of the %SystemRoot%:\ProgramData\Kerberos file:
allow_weak_crypto = true
Then, download and install the latest release of the Network Identity Manager application from the following page: Network Identity Manager Version 2.0 from Secure Endpoints.
Finally, download and install the latest release of OpenAFS for Windows for the workstation’s architecture from the following page: http://www.openafs.org/windows.html. When prompted, select the following options:
- Setup Type: IFS Based Client
- Default Cell:
justdavis.com - Integrated logon: Enable
- AFS crypt security: Enable
- Freelance mode: Enable
- Lookup cells in DNS: Enable
TODO: This guide may be incomplete, as it has not been tested yet.
Ubuntu 12.04 and 12.10
Ubuntu can be configured as a Kerberos and LDAP client, able to interact with both services on the command line. It can also be configured to use Kerberos for login authentication and LDAP for all directory services (e.g. “what users are available?”).
This section details the portion of that configuration common to both 12.04 and 12.10.
Kerberos Client
With the workstation a Kerberos client of the JUSTDAVIS.COM realm, users will be able to use the kinit, klist, and kdestroy commands to acquire and manage Kerberos tickets for that realm. These tickets can be “passed along” to other applications that have Kerberos support (e.g. SSH and OpenAFS clients).
The Kerberos client utilties can be installed as follows:
$ sudo apt-get install krb5-user
Because the Kerberos realm’s information is provided via DNS, users should now be able to obtain tickets from the realm, as follows:
$ kinit karl@JUSTDAVIS.COM
After that, the JUSTDAVIS.COM realm should be set as the workstation’s default, which will allow users to omit the realm suffix in the above command. Edit /etc/krb5.conf to configure the “default_realm” option, as follows:
[libdefaults]
default_realm = JUSTDAVIS.COM
Test that, as follows:
$ kdestroy
$ kinit karl
If everything’s working, the kinit command should list the newly obtained ticket.
The system will need to be configured to allow background services on it to make requests to the Kerberos server on behalf of the users. For this to work, the system’s fully qualified domain name (FQDN) must first be configured correctly. To ensure this is the case, two files have to be setup correctly:
/etc/hostname: This file should have the non-qualified hostname./etc/hosts: This file should have the fully qualified hostname, as well as the non-qualified hostname as an alias assigned to127.0.0.1.
Specifically, the first three entries in /etc/hosts should read as follows (replace “compname” with the short name for the workstation, e.g. “pratchett”):
127.0.0.1 localhost.localdomain localhost
::1 compname.justdavis.com compname localhost6.localdomain6 localhost6
127.0.1.1 compname.justdavis.com compname
The hostname configuration can be tested with the hostname command. The first command should return the unqualified name and the second command should return the fully qualified name:
$ hostname
$ hostname -f
Once the hostname is configured correctly, the workstation will need a Kerberos principal created for it, and to add that principal to the system’s default keytab file (/etc/krb5.keytab). The simplest way to do this is to run the kadmin tool on the local workstation, as follows (replace “compname” with the short name for the workstation, e.g. “pratchett”):
# sudo kadmin -p karl/admin@JUSTDAVIS.COM
kadmin: addprinc -policy hosts -randkey host/compname.justdavis.com
kadmin: ktadd host/compname.justdavis.com
kadmin: quit
Troubleshooting Note: If you receive an error stating “kadmin: Missing parameters in krb5.conf required for kadmin client while initializing kadmin interface”, this is because the MIT Kerberos client does not yet support looking up the Kerberos “admin” server via DNS. In that case, add the following entry to the [realms] section of the /etc/krb5.conf file:
[realms]
JUSTDAVIS.COM = {
admin_server = kerberos.justdavis.com
}
LDAP Client
With the workstation a client of the dc=justdavis,dc=com LDAP directory, users will be able to use the ldapsearch command to query the LDAP directory for the objects contained in it.
Install the required packages:
$ sudo apt-get install ldap-utils libsasl2-modules-gssapi-mit
The workstation will need to have the public certificate authority certificate for the justdavis.com domain installed into its local OS certificate store. This can be done, as follows:
$ sudo scp localuser@eddings.justdavis.com:/usr/local/share/ca-certificates/ca.justdavis.com.crt /usr/local/share/ca-certificates/
$ sudo update-ca-certificates
Ensure that the OpenLDAP client tools are configured to use the local OS certificate store by editing the /etc/ldap/ldap.conf file and ensuring the following option is configured correctly:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
At this point, users should be able to query the LDAP directory if they specify the server, authentication DN, and base search DN, as follows:
$ ldapsearch -x -D uid=karl,ou=people,dc=justdavis,dc=com -W -H ldaps://ldap.justdavis.com -b dc=justdavis,dc=com
For convenience, the OpenLDAP client tools should be configured with the LDAP server’s address and the directory’s base search DN. This can be accomplished by editing the /etc/ldap/ldap.conf file and ensuring the following options are configured correctly:
BASE dc=justdavis,dc=com
URI ldaps://ldap.justdavis.com
At this point, users should be able to query the LDAP directory if they specify the authentication DN, as follows:
$ ldapsearch -x -D uid=karl,ou=people,dc=justdavis,dc=com -W
For further convenience, users should also be able to authenticate to the LDAP server with Kerberos (via GSSAPI) and thus avoid having to specify an authentication DN at all, as follows:
$ kinit karl@JUSTDAVIS.COM
$ ldapsearch -Y GSSAPI
OpenAFS Client
References:
- Debian openafs documentation in /usr/share/doc/openafs-* (after packages are installed)
Install the openafs client packages:
$ sudo apt-get install openafs-doc openafs-client openafs-modules-dkms openafs-krb5
You will be prompted to enter values for the following settings:
- cell name:
justdavis.com - client cache size:
500000 - db server host names:
eddings.justdavis.com - run client at boot: yes
Troubleshooting note: Minimal Ubuntu installs, e.g. JeOS, may not have the kernel headers required to build the OpenAFS kernel module. If the install above ends with a message indicating the DKMS build couldn’t be performed, the headers likely need to be installed. For example, on JeOS machines, the linux-headers-virtual package is needed:
$ sudo apt-get install linux-headers-virtual
Granting Users Administrative Privileges
Users who need administrative privileges should be made members of the sudo group on the system. This will give those users permission to use the sudo command, and also the ability to perform administrative functions in any GUI applications that require them.
Users can be added to the group, as follows (replace “someuser” with the username to be granted administrative privileges):
$ sudo usermod -a -G sudo someuser
SSH Configuration
SSH can also be configured to accept existing Kerberos ticket/credentials via GSSAPI. This will allow users with valid tickets to connect to this workstation over SSH without having to enter a password. Please note that, because this login bypasses PAM, the user will not have a valid Kerberos ticket or AFS token in the new remote session; users will have to manually run kinit and aklog after connecting, if needed. To temporarily disable GSSAPI, and instead use PAM authentication, when connecting as a client, the ssh -k flag can be used.
To enable this, set the following option in the SSH server’s /etc/ssh/sshd_config file:
GSSAPIAuthentication yes
Then, restart the ssh service:
$ sudo service ssh restart
Troubleshooting Note: While testing network logins on pratchett, I was unable to login and had the following error in /var/auth.log: “Jul 29 22:52:03 pratchett sshd[30251]: pam_krb5(sshd:auth): (user karl) credential verification failed: Server krbtgt/DAVISONLINEHOME.NAME@JUSTDAVIS.COM not found in Kerberos database”. Turns out, this error was due to the old DAVISONLINEHOME.NAME host principal still being stored in /etc/krb5.keytab. I discovered this by running ktlist -k and resolved it by deleting the keytab and re-creating it using kadmin and ktadd.
Ubuntu 12.04-Specific Configuration
This section details the portions of the configuration that are specific to Ubuntu 12.04.
NSS and PAM Configuration
References:
Ubuntu uses NSS to configure the lookup of accounts for the workstation, amongst other things. In order to login to network accounts, NSS needs to be conifgured to make use of the LDAP server.
There are several options on how to go about this:
- Either the
libnss-ldaporlibnss-ldapdpackage can be used to connect NSS to LDAP. Aslibnss-ldapdis a fork of the originallibnss-ldapand seems to be regarded as an improvement, that’s the recommened option. - The LDAP server can be contacted synchronously for every lookups, or can be cached asynchronously using
nscdandlibnss-db, instead. As laptops can’t always contact the server and synchronous lookups are slow, it’s recommended to cache the lookups.
Ubuntu uses PAM to configure the “chain” of services and calls to be made during login. This will allow for the use of both Kerberos and LDAP during logins, as appropriate. In addition, by using PAM with the pam_ccreds package, the workstation can be configured to cache logins, allowing for use when the network servers are unavailable or the workstation is disconnected.
Both NSS and PAM can be configured on Ubuntu using the AuthClientConfig tool. This tool will take a “profile” created for it and use that profile to configure both services. This is recommended over editing the configuration files by hand, as it allows the configuration to be managed centrally and re-applied when necessary for upgrades of the system.
The libnss-ldapd and nslcd packages should be installed and configured:
$ sudo apt-get install libnss-ldapd
If prompted by the installation, answer the questions as follows:
- LDAP server URI:
ldaps://ldap.justdavis.com - Search Base BN:
dc=justdavis,dc=com - Check server’s SSL certificate: demand
- Name services to configure: (none)
If not prompted during the installation, those settings should be configured by setting the following options in the /etc/nslcd.conf file:
uri ldaps://ldap.justdavis.com
base dc=justdavis,dc=com
tls_reqcert hard
Either way, the /etc/nslcd.conf file will also need the following option to be set:
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
Restart the nslcd service:
$ sudo service nslcd restart
To reduce the load on the LDAP server, improve workstation performance, and enable disconnected operation, the libnss-db service will be used to cache LDAP lookups. The service should be installed, as follows:
$ sudo apt-get install libnss-db nss-updatedb
The cache database can be populated/updated, as follows:
$ sudo nss_updatedb ldap
A cron job should be added to update this database automatically every hour. Create a new /etc/cron.hourly/nss-updatedb-ldap script with the following contents:
#!/bin/bash
/usr/sbin/nss_updatedb ldap
Mark the new script as executable:
$ sudo chmod a+x /etc/cron.hourly/nss-updatedb-ldap
Once this is completed, the additional PAM modules that are needed and AuthClientConfig should be installed, as follows:
$ sudo apt-get install libpam-krb5 libpam-afs-session libpam-ccreds libpam-foreground auth-client-config
Create a new AuthClientConfig profile in the file /etc/auth-client-config/profile.d/justdavis_network:
[justdavis_network]
nss_passwd=passwd: compat db
nss_group=group: compat db
nss_shadow=shadow: compat
nss_netgroup=netgroup: nis
pam_auth=auth [default=reset success=done] pam_unix.so debug
auth optional pam_group.so
auth [default=ignore success=1 service_err=reset] pam_krb5.so use_first_pass debug forwardable
auth [default=die success=done] pam_ccreds.so action=validate use_first_pass
auth optional pam_afs_session.so
auth optional pam_gnome_keyring.so
auth sufficient pam_ccreds.so action=store use_first_pass
auth required pam_deny.so
pam_account=account sufficient pam_unix.so
account sufficient pam_krb5.so
pam_password=password sufficient pam_unix.so obscure sha512
password sufficient pam_krb5.so debug try_first_pass
password required pam_deny.so
pam_session=session optional pam_krb5.so
session optional pam_ck_connector.so nox11
session optional pam_afs_session.so
session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
Please note: The following customizations may need to be made to the above profile.
- On servers (workstations without a GUI display), the “
pam_gnome_keyring.so” line should be removed. - If the
/lib/security/pam_cap.sofile is present, an additional line should be added after the “pam_gnome_keyring.so” one:auth optional pam_cap.so
Enable the justdavis_network profile and restart nscd to clear its cache:
$ sudo auth-client-config -a -p justdavis_network
$ sudo /etc/init.d/nscd restart
Add the following to the end of /etc/security/group.conf:
# Ensure that network-authenticated users are added to the standard user groups
* ; *; *;Al0000-2400; adm, dialout, cdrom, plugdev, lpadmin, admin, sambashare, disk
Ubuntu 12.10
This section details the portions of the configuration that are specific to Ubuntu 12.10.
NSS Configuration
References:
Ubuntu uses NSS to configure the lookup of accounts for the workstation, amongst other things. In order to login to network accounts, NSS needs to be conifgured to make use of the LDAP server.
There are several options on how to go about this:
- Either the
libnss-ldaporlibnss-ldapdpackage can be used to connect NSS to LDAP. Aslibnss-ldapdis a fork of the originallibnss-ldapand seems to be regarded as an improvement, that’s the recommened option. - The LDAP server can be contacted synchronously for every lookups, or can be cached asynchronously using
nscdandlibnss-db, instead. As laptops can’t always contact the server and synchronous lookups are slow, it’s recommended to cache the lookups.
NSS can be configured on Ubuntu using the AuthClientConfig tool. This tool will take a “profile” created for it and use that profile to configure NSS. This is recommended over editing the configuration files by hand, as it allows the configuration to be managed centrally and re-applied when necessary for upgrades of the system.
The libnss-ldapd and nslcd packages should be installed and configured:
$ sudo apt-get install libnss-ldapd
If prompted by the installation, answer the questions as follows:
- LDAP server URI:
ldaps://ldap.justdavis.com - Search Base BN:
dc=justdavis,dc=com - Check server’s SSL certificate: demand
- Name services to configure: (none)
If not prompted during the installation, those settings should be configured by setting the following options in the /etc/nslcd.conf file:
uri ldaps://ldap.justdavis.com
base dc=justdavis,dc=com
tls_reqcert hard
Either way, the /etc/nslcd.conf file will also need the following option to be set:
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
Restart the nslcd service:
$ sudo service nslcd restart
To reduce the load on the LDAP server, improve workstation performance, and enable disconnected operation, the libnss-db service will be used to cache LDAP lookups. The service should be installed, as follows:
$ sudo apt-get install libnss-db nss-updatedb
The cache database can be populated/updated, as follows:
$ sudo nss_updatedb ldap
A cron job should be added to update this database automatically every hour. Create a new /etc/cron.hourly/nss-updatedb-ldap script with the following contents:
#!/bin/bash
/usr/sbin/nss_updatedb ldap
Mark the new script as executable:
$ sudo chmod a+x /etc/cron.hourly/nss-updatedb-ldap
Once this is completed, the additional PAM modules that are needed and AuthClientConfig should be installed, as follows:
$ sudo apt-get install libpam-krb5 libpam-afs-session libpam-ccreds libpam-foreground auth-client-config
Create a new AuthClientConfig profile in the file /etc/auth-client-config/profile.d/justdavis_network:
[justdavis_network]
nss_passwd=passwd: compat db
nss_group=group: compat db
nss_shadow=shadow: compat
nss_netgroup=netgroup: nis
Enable the justdavis_network profile and restart nscd to clear its cache:
$ sudo auth-client-config -t nss -p justdavis_network
$ sudo /etc/init.d/nscd restart
PAM Configuration
References:
- Ubuntu Wiki: LDAPClientAuthentication: this page provided the syntax for
pam-auth-updateprofiles.
Ubuntu uses PAM to configure the “chain” of services and calls to be made during login. This will allow for the use of both Kerberos and LDAP during logins, as appropriate. In addition, by using PAM with the pam_ccreds package, the workstation can be configured to cache logins, allowing for use when the network servers are unavailable or the workstation is disconnected.
In Ubuntu 12.10, PAM is most easily configured using the pam-auth-update tool/framework. Rather than the monolithic profile required by auth-client-config, pam-auth-update breaks profiles into smaller package-specific modules, e.g. one for Kerberos, one for OpenAFS, etc. In fact, most of the PAM configuration for Ubuntu 12.10 is already done at this point in the guide, as most of the packages installed came with the profiles needed.
The following profile will provide the only needed PAM configuration that is still missing. Save the following as /usr/share/pam-configs/justdavis:
Name: Enable justdavis.com Modules
Default: yes
Priority: 900
Session-Type: Additional
Session:
required pam_mkhomedir.so umask=0022 skel=/etc/skel
Auth-Type: Primary
Auth:
required pam_group.so use_first_pass
Once the new profile is in place, run pam-auth-update as follows:
$ sudo pam-auth-update
In the UI, do the following:
- Enable all of the profiles.
- Disable the LDAP Authentication profile (it is provided with one of the LDAP client or NSS packages installed above).
- Select Ok to apply the changes and exit.
Add the following to the end of /etc/security/group.conf:
# Ensure that network-authenticated users are added to the standard user groups
* ; *; *;Al0000-2400; adm, dialout, cdrom, plugdev, lpadmin, admin, sambashare, disk
LightDM Network User Logins
References:
By default, the login screen/application used by Ubuntu, LightDM, will only allow local users to login.
To resolve this, edit the /etc/lightdm/lightdm.conf and add the following line:
greeter-show-manual-login=true
After restarting the system, users willbe able to login by selecting their account from the list (if they’ve logged in before) or by entering the network username manually.