SingleSignOn

Differences between revisions 11 and 12
Revision 11 as of 2006-06-04 13:37:07
Size: 7051
Editor: 81-178-237-253
Comment: cat doc
Revision 12 as of 2006-06-08 18:48:57
Size: 8507
Editor: smithers
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
<!> WORK IN PROGRESS - This HOWTO is not complete! <!> <!> '''WORK IN PROGRESS - This HOWTO is not complete!''' <!>

attachment:IconsPage/IconWarning3.png '''IMPORTANT: Before you get started you must enable the Universe Repository!''' See AddingRepositoriesHowto for info on how to do this.
Line 7: Line 9:

There are two functions that a Single Sign On solution must perform:
 * Authentication: Determining if a user or server is who they claim to be and providing a mechanism for passing that information throughout the network.
 * Authorization: Information on what priviledges are possessed by authorized entities on the network

This solution uses Keberos 5 for authentication and OpenLDAP for authorization.
Line 12: Line 20:
/!\ '''Before you get started you must enable the Universe Repository!''' See AddingRepositoriesHowto for info on how to do this.
Line 17: Line 24:
This section describes how to install and configure a Kerberos 5 Key Distribution Center (KDC) and establish a realm for your network. The KDC will store password information for all users on your network. Kerberos allows users and services to securly authenticate with each other by passing around encrypted tickets. Tickets allow users and servers to know that each party is who they say they are. At logon, the KDC generates a ticket granting ticket (TGT) that the user can use with subsequent transactions to request access. A more detailed explaination of Kerberos is available at [http://web.mit.edu/kerberos]. This section describes how to install and configure a Kerberos 5 Key Distribution Center (KDC) and establish a realm for your network. The KDC is used to store password information for all users on your network. Kerberos allows users and services to securly authenticate with each other by passing around encrypted tickets. Tickets allow users and servers to know that each party is who they say they are. At logon, the KDC generates a ticket granting ticket (TGT) that the user can use with subsequent transactions to request access. A more detailed explaination of Kerberos is available at [http://web.mit.edu/kerberos].
Line 23: Line 30:
/!\ NEED TO ADD DNS CONFIG INFORMATION HERE
Line 37: Line 43:
The configuration file for Kerberos is /etc/krb5kdc/kdc.conf. Here is an example configuration file: The configuration file for Kerberos is /etc/krb5kdc/kdc.conf. This file provides settings for your Kerberos realm. Important settings here are the locations of the KDC's data files, and the default settings for the durations that tickets are valid. Here is an example configuration file:
Line 56: Line 62:
Kerberos uses an Access Control List (ACL) to specify the access a principle will have to the Kerberos admin deamon. This file is /etc/krb5kdc/kadm5.acl. Kerberos uses an Access Control List (ACL) to specify the access a principle will have to the Kerberos admin deamon. This file is /etc/krb5kdc/kadm5.acl.  The default, as shown below will suffice to get started. You may need to add additional ACLs depending on the needs of your network configuration.
Line 66: Line 72:
 * need instructions to create a host principal
Line 69: Line 77:
'''LDAP''' is the '''L'''ightweight '''D'''irectory '''A'''ccess '''P'''rotocol. 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 a given network. '''LDAP''' is the '''L'''ightweight '''D'''irectory '''A'''ccess '''P'''rotocol. 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 your network.
Line 84: Line 92:
Since you will be using OpenLDAP to provide authentication information to your network, you should encrypt all of the traffic between the server and clients. This will be done using TLS encryption. You must create keys for the server. See the [:OpenSSL:OpenSSL] page for info on how to create a certificate authority and your own tickets. Import your new CA certificate into /usr/share/ca-certificates, as described on the OpenSSL page, so that other software on your system will recognize your CA as trusted. Since you will be using OpenLDAP to provide authentication information to your network, you should encrypt all of the traffic between the server and clients. This will be done using TLS encryption. You must create keys for the server. See the [:OpenSSL:OpenSSL] page for info on how to create a certificate authority and your own certificates. Import your new CA certificate into /usr/share/ca-certificates, as described on the OpenSSL page, so that other software on your system will recognize your CA as trusted.

You must create a certificate with a Common Name (CN) that matches the hostname of the server where you are running slapd. Once you have this certificate signed, copy it to the /etc/slapd/certs directory.

=== Configuring OpenLDAP ===
 * need to add instructions on configuring OpenLDAP
Line 114: Line 127:

== Testing GSSAPI ==
 * test SASL binds to the OpenLDAP directory
Line 121: Line 133:
 * test kinit / klist
 * test SASL binds
 * modify /etc/ldap/ldap.conf, /etc/libnss-ldap.conf, /etc/nsswitch.conf
 * check that getent can retrieve user information from the LDAP server
 * modify PAM configuration to use LDAP and Kerberos
 * information on configuring nscd to cache LDAP information
Line 129: Line 147:
CategoryDocumentation CategoryDocumentation CategoryHomepage

Info <!> WORK IN PROGRESS - This HOWTO is not complete! Info <!>

attachment:IconsPage/IconWarning3.png IMPORTANT: Before you get started you must enable the Universe Repository! See AddingRepositoriesHowto for info on how to do this.

1. Introduction

This page describes how to set up network-connected Ubuntu machines to support Single Sign On (SSO). SSO refers to the capability to only enter your logon credentials one time and then have those crendentials automatically passed to authenticate you to other services available on your network. You will also have a central location that stores all username, groupname, and password data for the users on your network. This solution uses OpenLDAP to provide authorization and MIT Kerberos to provide authentication. This document is divided in to several sections that describe installation of required server software, testing, and installation of software on the client.

There are two functions that a Single Sign On solution must perform:

  • Authentication: Determining if a user or server is who they claim to be and providing a mechanism for passing that information throughout the network.
  • Authorization: Information on what priviledges are possessed by authorized entities on the network

This solution uses Keberos 5 for authentication and OpenLDAP for authorization.

2. Target Audience

To properly implement the practical steps found in this guide, the reader should be a user of Ubuntu who is 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 of this guide in order to broaden understanding of the technologies involved in SSO.

3. Server Installation

3.1. Installing MIT Kerberos 5

3.1.1. Overview of Kerberos

This section describes how to install and configure a Kerberos 5 Key Distribution Center (KDC) and establish a realm for your network. The KDC is used to store password information for all users on your network. Kerberos allows users and services to securly authenticate with each other by passing around encrypted tickets. Tickets allow users and servers to know that each party is who they say they are. At logon, the KDC generates a ticket granting ticket (TGT) that the user can use with subsequent transactions to request access. A more detailed explaination of Kerberos is available at [http://web.mit.edu/kerberos].

3.1.2. Pre-installation Decisions

Before you install the KDC, you must decide on the following:

  • What machine do you want to use as your KDC? Security of this machine is important, since compromising the KDC could compromise the security of your entire network.
  • Determine a name for your realm. The convention for realm names is to use the site's domain name fully capitalized. For instance, the site somerealm.com would use the realm name SOMEREALM.COM.

3.1.3. Software Installation

Once you have decided where to install the KDC, and determined your realm name, run the following on the machine that will be the KDC:

sudo apt-get install krb5-kdc

The package install will step you through defining the basic Kerberos configuration parameters. Recommended settings are:

  • disable Kerberos 4 compatibility mode
  • do not run krb524d (daemon to convert Kerberos tickets between versions)
  • defaults for the other settings are acceptable

attachment:IconsPage/IconWarning3.png IMPORTANT: You need to remember the admin username and password you create during this step!

The configuration file for Kerberos is /etc/krb5kdc/kdc.conf. This file provides settings for your Kerberos realm. Important settings here are the locations of the KDC's data files, and the default settings for the durations that tickets are valid. Here is an example configuration file:

[kdcdefaults]
        kdc_ports = 750,88

[realms]
SOMEREALM.COM = {
    database_name = /var/lib/krb5kdc/principal
    admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
    acl_file = /etc/krb5kdc/kadm5.acl
    key_stash_file = /etc/krb5kdc/stash
    kdc_ports = 750,88
    max_life = 10h 0m 0s
    max_renewable_life = 7d 0h 0m 0s
    master_key_type = des3-hmac-sha1
    supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm
    default_principal_flags = +preauth
}

Kerberos uses an Access Control List (ACL) to specify the access a principle will have to the Kerberos admin deamon. This file is /etc/krb5kdc/kadm5.acl. The default, as shown below will suffice to get started. You may need to add additional ACLs depending on the needs of your network configuration.

# This file Is the access control list for krb5 administration.
# When this file is edited run /etc/init.d/krb5-admin-server restart to activate
# One common way to set up Kerberos administration is to allow any principal
# ending in /admin  is given full administrative rights.
# To enable this, uncomment the following line:
*/admin@SOMEREALM.COM    *
  • need instructions to create a host principal

3.2. Installing OpenLDAP

3.2.1. Overview of LDAP

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 your network.

3.2.2. Software Installation

3.2.2.1. Installing OpenLDAP

sudo apt-get install slapd

3.2.2.2. Installing SASL

sudo apt-get install libsasl2-gssapi-mit

3.2.3. Creating SSL Certificates

Since you will be using OpenLDAP to provide authentication information to your network, you should encrypt all of the traffic between the server and clients. This will be done using TLS encryption. You must create keys for the server. See the [:OpenSSL:OpenSSL] page for info on how to create a certificate authority and your own certificates. Import your new CA certificate into /usr/share/ca-certificates, as described on the OpenSSL page, so that other software on your system will recognize your CA as trusted.

You must create a certificate with a Common Name (CN) that matches the hostname of the server where you are running slapd. Once you have this certificate signed, copy it to the /etc/slapd/certs directory.

3.2.4. Configuring OpenLDAP

  • need to add instructions on configuring OpenLDAP

4. Server Testing

4.1. Testing Kerberos 5

From the KDC, type the following:

$ kinit

Type your password when prompted. If this was successful, you won't receieve any error messages. Next, test that you got a Ticket Granting Ticket (TGT) from the KDC. To do this type the following:

$ klist

The response should look something like this:

Ticket cache: FILE:/tmp/krb5cc_5001_PpRNvF
Default principal: user@SOMEREALM.COM

Valid starting     Expires            Service principal
05/28/06 08:18:09  05/28/06 18:18:09  krbtgt/SOMEREALM.COM@SOMEREALM.COM
        renew until 05/29/06 08:18:06


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

Try these same two commands from another machine on your network. If these commands succeed, you have successfully installed the KDC.

4.2. Testing OpenLDAP

  • test SASL binds to the OpenLDAP directory

5. Client Installation

Rough Outline:

  • install packages
  • create host principal / add to client's keytab
  • test kinit / klist
  • test SASL binds
  • modify /etc/ldap/ldap.conf, /etc/libnss-ldap.conf, /etc/nsswitch.conf
  • check that getent can retrieve user information from the LDAP server
  • modify PAM configuration to use LDAP and Kerberos
  • information on configuring nscd to cache LDAP information

Packages to Install:

  • ldap-utils
  • libsasl2-gssapi-mit
  • libpam-krb5
  • libnss-ldap
  • nscd


CategoryDocumentation CategoryHomepage

SingleSignOn (last edited 2008-08-06 16:34:44 by localhost)