Ubuntu SingleSignOn

Contents

Introduction1.

Audience2.

Authentication3.

Account Management

Securing Access

Anonymous Access1.

1.

4.

Shared File Systems

NFS1.

Samba2.

SSHFS3.

5.

Client Configuration

Authentication1.

Accounts

Login Manager

Configuration

1.

2.

Shared Files3.

Testing and Validation4.

6.

Caching

Hostnames1.

Credentials2.

7.

LDAP Authentication

Installing required

packages

Configuring LDAP1.

Configuring

Kerberos

2.

Configuring PAM

and NSS

3.

1.

Reverting2.

8.

Troubleshooting

Common Error Messages1.

Kerberos2.

9.

Partners

Support

Community

Ubuntu.com

Login to edit

Search

SingleSignOn

1. Introduction

This page describes how to set up network-connected

Ubuntu machines to support Single Sign-On (SSO). SSO

is a name for a collection of technologies that allows

network users to provide a single set of credentials for all

network services. In a properly configured SSO

environment, a user's desktop environment can migrate

seamlessly between computers, and access to shared

resources such as file systems and printers can be

managed with ease.

This SSO solution centralizes the following services:

Authentication: Verification that a user or server is

who they claim to be and providing a mechanism

for passing this information to hosts on the

network. Kerberos is used for this purpose.

Account Management: Information about the user

such as username and group membership.

OpenLDAP is used.

Shared File Systems: several options are available.

Auto-mounting is effected by pam_mount.

(Limited) Authorization: authorization information

is a combination of group membership information

held in the LDAP directory and local file system

permissions.

This guide is divided into several sections that describe

SingleSignOn - Community Ubuntu Documentation https://help.ubuntu.com/community/SingleSignOn

1 of 14 Monday 25 March 2013 04:11 PM

OpenLDAP3.

Service Configuration

SSH1.

Apache2.

NFS3.

10.

installation of required server software, testing, and

installation of software on the client.

2. Audience

This guide is written for system administrators looking

for a Single Sign-On solution. To properly implement the practical steps found in this guide, the

reader should be comfortable with the use command-line applications, using the Bourne Again

SHell (bash) environment, and editing system configuration files with their preferred text editor

application. While previous familiarity with OpenLDAP or Kerberos is not required for this guide,

the reader is advised to pursue further learning from the resources listed in the Resources section to

broaden their understanding of the technologies involved in SSO.

3. Authentication

Kerberos is an authentication protocol using a combination of secret-key cryptography and trusted

third parties to allow secure authentication to network services over untrusted networks. This guide

uses the MIT implementation of Kerberos as the authentication function of SSO.

See the Kerberos wiki page for instructions on deploying MIT Kerberos.

4. Account Management

LDAP is the Lightweight Directory Access Protocol. It is designed to store data records and allow

for easy access to the records via a simple network interface. LDAP can provide access to directory

type information such as an address book for your email client, or a list of users and groups that

have access to services on your network. This guide uses the OpenLDAP package for the account

management function of SSO.

Detailed instructions on installing and populating an LDAP directory are available on the

OpenLDAPServer page and in the Ubuntu Server Guide. Pay special attention to the section on

encrypting LDAP traffic if user passwords are stored in the LDAP directory (this is not

recommended).

4.1. Securing Access

The Security section of the OpenLDAPServer describes how to configure authentication to

OpenLDAP via Kerberos in detail. The Kerberos wiki page also contains information on installing

and troubleshooting Kerberos/SASL integration. The following is a brief summary.

Generate an LDAP keytab using kadmin:

kadmin: addprinc -randkey ldap/[email protected]: ktadd -k ~/ldap.keytab ldap/[email protected]

1.



Securely transfer the keytab to the OpenLDAP server (scp is used here):

$ scp user@kdc:/home/user/ldap.keytab ~/

2.

Fix permissions and move the keytab to the correct directory:

$ chmod 640 ~/ldap.keytab$ sudo chown openldap:openldap ~/ldap.keytab$ mv ~/ldap.keytab /etc/ldap

3.

Configure OpenLDAP to reference the new keytab by adding the following line to

/etc/default/slapd:

export KRB5_KTNAME=/etc/ldap/ldap.keytab

4.

Install SASL packages:

$ sudo apt-get install sasl2-bin libsasl2-2 libsasl2-modules libsasl2-modules-gssapi-mit

5.

Configure SASL by adding the following attributes to the cn=config DIT. For statically

configured instances, add the appropriate directives to slapd.conf and restart.

#The FQDN of the Kerberos KDC.#slapd.conf: sasl-host kerberos.example.comolcSaslHost: kerberos.example.com

#The Kerberos realm name#slapd.conf: sasl-realm EXAMPLE.COMolcSaslRealm: EXAMPLE.COM

#slapd.conf: sasl-secprops noanonymous,noactive,noplain,minssf=56olcSaslSecProps: noplain,noactive,noanonymous,minssf=56

#slapd.conf: saslRegexp uid=([^/]*),cn=example.com,cn=GSSAPI,cn=auth uid=$1,ou=people,dc=example,dc=olcAuthzRegexp: {0}"uid=([^/]*),cn=example.com,cn=GSSAPI,cn=auth" "uid=$1,ou=people,dc=example,dc=co

#slapd.conf: saslRegexp uid=host/([^/]*).example.com,cn=example.com,cn=gssapi,cn=auth cn=$1,ou=hostsolcAuthzRegexp: {1}"uid=host/([^/]*).example.com,cn=example.com,cn=gssapi,cn=auth" "cn=$1,ou=hosts,d

#slapd.conf: saslRegexp uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth cn=admin,cn=configolcAuthzRegexp: {2}"uid=ldap/admin,cn=example.com,cn=gssapi,cn=auth" "cn=admin,cn=config"

6.

4.1.1. Anonymous Access

In small environments with minimal security requirements, it may be convenient to allow any user

on the network to obtain account information anonymously. This is a more NIS-like approach,

without some of NIS's more serious security concerns. See section 10.3 of OpenLDAP's security

documentation for details.

If anonymous access is used, the directory's Access Control List must be configured carefully. The

default OpenLDAP configuration restricts access to sensitive fields such as userPassword and

shadowLastChange only.

5. Shared File Systems



Note: The file server must have access to the account information in the LDAP directory. Configure

the file server using the process described the Authentication and Accounts sections of the Client

Configuration section. Test with getent passwd.

5.1. NFS

NFS works well for network environments comprised primarily of *nix systems, but security can be

a concern. See http://nfs.sourceforge.net/nfs-howto/ar01s06.html. One solution is IPSec, see

SettingUpNFSHowTo for details.

5.2. Samba

Samba can be configured to use Kerberos as an authentication source; see the Samba/Kerberos wiki

page for details. This can be an attractive option for network environments where hosts must

interoperate with Windows. Some of the security concerns related to NFS are also present here,

although Samba provides an extension to the CIFS/SMB protocol that is designed to provide

transport encryption.

1

IPSec can be useful here as well.

5.3. SSHFS

The use of libpam-krb5 allows pam_mount to auto-mount SSHFS file systems if the file

server's SSH access has been Kerberized (see http://www.visolve.com/security/ssh_kerberos.php for

details on configuring Kerberos authentication in SSH). Transport encryption is automatic. It may be

necessary to restrict remote access to portions of the server's file system with tools such as rssh,

scponly, or chrooted SSH.

2

6. Client Configuration

6.1. Authentication

The following instructions briefly demonstrate the process for configuring a host to participate in a

Kerberos realm. Each step of the process is described more thoroughly in the Client Configuration

section of the Kerberos wiki page.

Install the packages necessary for Kerberized local authentication:

$ sudo apt-get install krb5-user krb5-config libpam-krb5

The krb5-user package is very useful for diagnostics and troubleshooting, but not strictly

necessary. Supply a default realm name, and the FQDNs of the KDC and administrative

servers if this information is not available via DNS.

1.

Verify the hostname of the client:

$ hostname -fclient.example.com

2.



If the output of hostname -f does not include the domain name, you will need to debug

the your domain name resolution before continuing.

Generate a keytab for the host using kadmin:

kadmin: addprinc -randkey host/[email protected]: ktadd -k ~/client.keytab host/[email protected]

3.

Securely transfer the keytab to the host, if necessary. scp is used here.

$ scp user@host:/home/user/client.keytab .

4.

Correct permissions:

$ chmod 600 ~/client.keytab$ sudo chown root:root ~/client.keytab

5.

Deploy the keytab:

$ sudo mv ~/client.keytab /etc/krb5.keytab

6.

6.2. Accounts

Install the packages necessary for NSS to access LDAP with Kerberos authentication:

$ sudo apt-get install libnss-ldapd libsasl2-modules-gssapi-mit kstart

libnss-ldapd should prompt for an LDAP server URI and search base (usually of the form

dc=example,dc=com), and present a list of name services to configure. passwd, groupand shadow services must be enabled. If debconf does not prompt for this information, it is

simple to make the necessary changes manually:

Edit /etc/nslcd.conf and specify the uri and search base parameters.

...# The location at which the LDAP server(s) should be reachable.uri ldap://ldap.example.com/

# The search base that will be used for all queries.base dc=example,dc=com

1.

Edit /etc/nsswitch.conf and add ldap to the list of services that service passwd,

group, and shadow. A minimal configuration looks like this:

passwd: compat ldapgroup: compat ldapshadow: compat ldap

2.

1.

If TLS encryption is enabled on the LDAP server, configure nslcd to use encryption with the

following lines in /etc/nslcd.conf:

#SSL optionsssl start_tlstls_reqcert hardtls_cacertfile /path/to/CA/cert

2.



Add the following lines at the bottom of /etc/nslcd.conf:

sasl_mech GSSAPIkrb5_ccname FILE:/tmp/host.tkt

3.

Disable LDAP authentication using pam-auth-update4.

Restart nslcd:

$ sudo service nslcd restart

5.

6.2.1. Login Manager Configuration

LDAP users may not be displayed in the login manager configuration until they have successfully

logged in. To enable manual logins in LightDM, add the following line to /etc/lightdm/lightdm.conf:

greeter-show-manual-login=true

6.3. Shared Files

pam_mount is a PAM module that provides a flexible mechanism for mounting file systems as part

of the login process. Install as follows:

$ sudo apt-get install libpam-mount

Configure pam_mount to mount directories by editing /etc/security/pam_mount.xmland adding <volume> definitions. Here is a sample SSHFS volume:

<volume fstype="fuse" path="sshfs#%(USER)@slave1.brainvitamins.net:/home/%(USER)/shared" mountpoint="~

See the pam_mount documentation for details on configuring pam_mount.

6.4. Testing and Validation

Users and groups defined in the LDAP directory should now be present in the output of

getent passwd and getent group. Shared folders should be available after login.

7. Caching

For mobile clients such as laptops, a connection with the Kerberos and LDAP servers is not always

available. In these cases, the mobile host must utilize cached credentials and account information.

Caching is can also be utilized on desktop clients to reduce server load.

7.1. Hostnames

Dnsmasq is commonly used to cache DNS queries. For connections managed by Gnome's



NetworkManager, resolvconf takes the pain out of /etc/resolv.conf.

7.2. Credentials

The pam_ccreds PAM module caches login credentials. Install it as follows:

$ sudo apt-get install libpam-ccreds

8. LDAP Authentication

It is possible to configure clients to authenticate using credentials stored in the LDAP directory

instead of Kerberos authentication. The following section describes this method. See also

LDAPClientAuthentication, particularly for caching.

8.1. Installing required packages

You need to install these packages on all machines on your network where you want to be able to

use SSO. At the command line, type the following:

sudo apt-get install ldap-auth-client libpam-krb5 krb5-user libpam-foreground libsasl2-modules-gssapi-

8.1.1. Configuring LDAP

The ldap-auth-config package (depended upon by ldap-auth-client) has a debconf script to help you

create the LDAP configuration file. This script will be run automatically when you install the

package.

The first step is to enter the URI for your LDAP server. If you followed this howto's

instructions on installing your server, this URI will be ldaps://<your server IP>/.



Next, you need to enter the DN of your search base. Use the same DN that you used as the

base for your user database.

You will only be using LDAPv3, so choose the default on this screen.



There's no need for local root to have full privileges over your LDAP server, so answer no

here.

If your LDAP server allows anonymous binds, you can answer 'no' here too. If you're ok with

the script dropping a plaintext password in /etc/ldap.secret, then you can enter the

password here. Otherwise, you answer 'no', but you have some work to do [XXX which is not

documented here yet].



8.1.2. Configuring Kerberos

krb5-config has a debconf script to set up client-side Kerberos properly.

sudo dpkg-reconfigure -plow krb5-config

Enter your realm (EXAMPLE.COM, for example) when prompted. If you have set up DNS records

to point to your KDC, answer yes to the relevant question. If not, you will be asked to specify the

hostname of your KDC and admin server.

edit /etc/ldap/ldap.conf and include the following lines:

BASE YOUR-BASEURI ldaps://SERVER-NAMETLS_REQCERT allow

Replace the SERVER-NAME & YOUR-BASE with the correct values.

edit /etc/ldap.conf and include the following lines:

bind_policy soft

8.1.3. Configuring PAM and NSS

auth-client-config gives us an easy way to configure NSS and PAM. It doesn't come with a

configuration for LDAP and Kerberos.

edit /etc/auth-client-config/profile.d/krb-auth-config and include the

following lines:



[krb5ldap]nss_passwd=passwd: files ldapnss_group=group: files ldapnss_shadow=shadow: files ldapnss_netgroup=netgroup: files ldappam_auth=auth sufficient pam_krb5.so auth required pam_unix.so nullok_secure use_first_passpam_account=account sufficient pam_krb5.so account required pam_unix.sopam_password=password sufficient pam_krb5.so password required pam_unix.so nullok obscure min=4 max=8 md5pam_session=session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ session optional pam_krb5.so session optional pam_foreground.so

[krb5ldap.cached]nss_passwd=passwd: files ldap [NOTFOUND=return] dbnss_group=group: files ldap [NOTFOUND=return] dbnss_shadow=shadow: files ldapnss_netgroup=netgroup: files ldappam_auth=auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth [default=ignore success=1 service_err=reset] pam_krb5.so use_first_pass auth [default=die success=done] pam_ccreds.so action=validate use_first_pass auth sufficient pam_ccreds.so action=store use_first_pass auth required pam_deny.sopam_account=account sufficient pam_krb5.so account required pam_unix.sopam_password=password sufficient pam_krb5.so password required pam_unix.so nullok obscure min=4 max=8 md5pam_session=session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ session optional pam_krb5.so session optional pam_foreground.so

Now we can do the actual configuration. It's probably a good idea to have a root shell open while

doing this, just in case something breaks.

sudo auth-client-config -a -p krb5ldap

At this stage, everything should work! Try getent passwd and getent group to check that

users and groups from LDAP are appearing properly. Log in as one of the LDAP users, and use

klist to confirm that you were automatically granted a TGT. Running passwd should change

your Kerberos password.

8.1.3.1. Cached Credentials

sudo apt-get install nss-updatedb libnss-db libpam-cracklib libpam-ccreds

sudo nss_updatedb ldap

sudo auth-client-config -a -p krb5ldap.cached

8.2. Reverting



If your login fails and the troubleshooting procedures don't help, head over to your lifesaving root

shell, and use auth-client-config to revert the settings.

auth-client-config -a -p krb5ldap -r

You may then debug at a later date without the risk of not being able to log into your system.

9. Troubleshooting

9.1. Common Error Messages

nslcd: ldap_start_tls_s() failed: Connect error

TLS connection failed. Often indicates the connection URI doesn't match the server name in the

TLS certificate. Troubleshoot with ldapsearch -ZZ

k5start: error getting credentials: Client not found in Kerberos database

Usually means the client's FQDN doesn't match what's in the Kerberos database. The output of

hostname -f must match the hostname in the Kerberos database exactly. If a DNS server is the

authoritative source for FDQNs, put "dns" first on the "hosts" line in /etc/nsswitch.conf

SASL authentication failure: No worthy mechs found

Usually indicates SASL is not installed or configured correctly. Verify libsasl2-modules-gssapi-mit is installed.

9.2. Kerberos

Check for connectivity with ping.1.

Verify users can obtain TGTs with kinit:

$ kinit

Type the user's password when prompted. If authentication succeeds, the command will return

silently and no error messages will be displayed.

2.

Verify kinit acquired a Ticket Granting Ticket (TGT) from the KDC:

$ klist

The response should look something like this:

Ticket cache: FILE:/tmp/krb5cc_5001_PpRNvF Default principal: [email protected]

Valid starting Expires Service principal 05/28/06 08:18:09 05/28/06 18:18:09 krbtgt/[email protected] renew until 05/29/06 08:18:06

3.



Kerberos 4 ticket cache: /tmp/tkt5001 klist: You have no tickets cached

Repeat the last two steps on another computer on the network.4.

Verify hostname -f returns the host's FQDN. It may be necessary to adjust the hostname

lookup procedure in /etc/nsswitch.conf. /etc/hosts and /etc/resolv.conf` are also

relevant configuration files.

5.

See the Kerberos wiki page for further information on troubleshooting Kerberos.

9.3. OpenLDAP

Verify connectivity with ping.1.

Verify the host can obtain Kerberos tickets:

$ sudo kinit -k -t /etc/krb5.keytab -p host/[email protected] $ sudo klist

The output should indicate a credentials cache has been successfully established.

2.

Use getent to verify the local system is pulling user and group information from the LDAP

directory:

$ getent passwd

The output should include all users and groups that are accessible in LDAP. If not, the host is

either unable to connect, or lacks access to the appropriate locations in the LDAP directory.

Verify access by reconstructing the host's query string with the ldapsearch tool (part of

the ldap-utils package). Use the option -Y GSSAPI to authenticate via Kerberos and

-b <basedn> to specify the base DN to search. The basedn used by nss-ldap is specified in

/etc/ldap.conf.

3.

Verify the settings in /etc/ldap.conf and /etc/nslcd.conf.4.

Review /var/log/auth.log, /var/log/daemon.log and /var/log/syslog for

error messages. The error "no worthy mechs found" indicates SASL is not installed or

configured correctly.

5.

Enable bootlogging and check the bootlogs for errors related to nslcd and k5start. If k5start

fails to load due to connectivity or DNS name resolution issues, see http://ubuntuforums.org

/showthread.php?p=8370410 for details on starting nslcd using Upstart.

6.

Log OpenLDAP stats (loglevel stats in slapd.conf or olcLevel stats in

cn=config), then follow the OpenLDAP log output while running getent.

7.

10. Service Configuration



10.1. SSH

See http://www.visolve.com/system_services/security/ssh.php for details on configuring Kerberos

authentication in SSH.

10.2. Apache

Apache can be configured to authenticate users via Kerberos. See the Kerberos wiki page for details.

10.3. NFS

NFSv4Howto contains information for Kerberized NFS access.

TODO:

information on configuring nss-updatedb and nscd to cache LDAP information

CategorySecurity

http://news.samba.org/announcements/3.2_press_release/ (1)1.

http://ubuntuforums.org/showthread.php?p=5762981#post5762981 (2)2.

SingleSignOn (last edited 2012-09-29 16:00:01 by enlightened-despot @

adsl-75-48-24-97.dsl.scrm01.sbcglobal.net[75.48.24.97]:enlightened-despot)



Ubuntu SingleSignOn

Documents

Transcript of Ubuntu SingleSignOn