Novell Home

Single Sign-On to eDirectory 8.8.2 using the SASL GSSAPI Mechanism

Novell Cool Solutions: AppNote
By Anil Belur

Digg This - Slashdot This

Posted: 18 Jul 2007
 

Overview

This Appnote describes the SASL GSSAPI (Generic Security Services Application Programming Interface) authentication mechanism (for Kerberos V5) authentication with eDirectory 8.8.2. An overview of Kerberos is provided, followed by the high-level architecture, quick configuration steps, features, benefits, and deployment scenarios.

  • Topics: Networks, Security, Authentication, Single Sign-On, Trusted third Party Systems
  • Products: SASL GSSAPI 2.0, Novell Kerberos KDC 1.5, eDirectory 8.8.2
  • Audience: eDirectory Administrator and General Users
  • Prerequisite Skills: Understanding of LDAP and Kerberos
  • Operating Systems: OES Linux 2, SLES 10

Contents

Introduction to SASL GSSAPI authentication method for eDirectory 8.8.2
Kerberos Authentication from a User Perspective
Architecture
Kerberos Authentication with an LDAP Client
Installing and Configuring the SASL GSSAPI Method
Deployment Scenarios
Conclusion
References

Introduction to the SASL GSSAPI Authentication Method for eDirectory 8.8.2

SASL stands for Simple Authentication Security Layer. It is a pluggable authentication framework that allows adding multiple authentication mechanisms, without changes to the application. Using the SASL framework, the applications need not be modified or rewritten to support a newer authentication mechanism.

The GSSAPI (Generic Security Services Application Programming Interface) provides authentication, confidentiality and integrity services, and an industry-recommended standard programming interface for Kerberizing applications and accessing Kerberos services. The GSSAPI mechanism currently provides Kerberos V5 support, an industry-standard way of authenticating entities over the network.

Kerberos V5 is a standard authentication protocol used for authenticating users over the network. This protocol is built on a trusted third-party authentication that consists of three entities: client (user), server (Kerberized application service) and a trusted third party (authentication server). These entities belong to a Realm that defines the boundary of trust.

The three entities interact as follows:

1. A trusted third party authenticates the client and the server.

2. The client and the server trust each other based on the information provided from the trusted third party server (KDC ? Key Distribution Center).

3. The client and the Kerberized application server are registered as principals with the Authentication server (KDC). They share a secret key with the KDC used in the authentication process.

Bringing these technologies together, a user can authenticate to the Kerberos Authentication Server (KDC ? Key Distribution Server), acquire a TGT (Ticket Granting Ticket, also known as an initial ticket), start an LDAP client, and use the acquired TGT and bind to an LDAP server and access other LDAP services. In other words, the module helps the LDAP server to authenticate the eDirectory 8.8.2 users using Kerberos V5 credentials.

One of the advantages of using SASL GSSAPI mechanism over other methods is its ability to support integrity and privacy of data in addition to authentication. This is particularly useful for an application that uses eDirectory as a data store, where the query and retrieval of information go over an insecure channel. The GSSAPI mechanism (using Kerberos) provides Single Sign On, which does not require the user to provide his password (until the credentials expire) while accessing different LDAP servers over the network.

Kerberos Authentication from a User Perspective

The following diagram describes how the Kerberos authentication protocol works.

Figure 1 - Kerberos authentication

1. The workstation user authenticates to the Kerberos KDC authentication server and obtains a TGT (Ticket Granting Ticket) or a Service Ticket.

2. The Kerberos KDC Authentication server responds back with a TGT (Ticket Granting Ticket) or a Service Ticket for the specific service.

3. The workstation or Kerberos application client sends the Service Ticket to the Kerberized service (FTPD or SSHD).

4. The Kerberized service verifies the Kerberos tickets and provides access to the user.

Architecture

The overall architecture GSSAPI authentication architecture is shown below.

Figure 2 - GSSAPI authentication architecture

When the GSSAPI authentication module is installed on the Directory server (eDirectory 8.8.2), the server-side support of this functionality requires that the root DSE on the LDAP server displays "GSSAPI" as a listed mechanism in the supportedSASLMechanisms attribute. This mechanism must be publicly readable and have an anonymous bind. The LDAP server passes the LDAP bind (authentication) request to the SASL server, which redirects the request to the GSSAPI mechanism. This mechanism interacts with the SASL and NMAS server to complete the authentication and perform the policy checks. To verify the Kerberos tickets, the module interacts with the GSSAPI and Kerberos V5 libraries.

Features and Benefits

The following GSSAPI features are supported with eDirectory 8.8.2:

  • Single Sign-on to eDirectory users. A benefit here is that the existing infrastructures or user accounts and credentials can be used to access to eDirectory.
  • Support of stronger LDAP authentication using GSSAPI (Kerberos V5). This ensures message integrity and privacy of requests, in addition to authentication. Using message privacy (encryption) eliminates the need for LDAP packets to go over SSL/TLS.
  • Novell Kerberos KDC 1.5 and SASL GSSAPI mechanism can be installed on the same tree. The other way for configuring the mechanism with eDirectory 8.8.2 is to integrate with an already deployed MIT Kerberos setup.

Kerberos Authentication with an LDAP Client

The basic Kerberos authentication flow for an LDAP client is pictured below.

Figure 3 - Kerberos authentication flow

1. The user on the work station authenticates to the Kerberos Authentication Server (AS) and gets an initial ticket (TGT).

2. The Kerberos Authentication Server returns a TGT.

3. The user starts an LDAP application client that accepts the following as parameters:

  • Mechanism = GSSAPI
  • Server Host name

The LDAP application client internally calls ldap_sasl_bind() with the GSSAPI as the selected mechanism for authentication. The client performs a root DSE search and verifies whether the GSSAPI mechanism is supported. Once verified, the LDAP client sends a Kerberos tickets wrapped in an LDAP request to the LDAP server. The application client (using ldap_sasl_bind()) requests an LDAP server Service Ticket (ST) presenting the user's TGT. It is optional to provide the mechanism name, as the strongest supported mechanism is selected.

4. The Kerberos TGS (Ticket Granting Server) returns a LDAP service request.

5. The application client (ldap_sasl_bind()) sends the service ticket (ST) to the LDAP server. The LDAP server validates the tickets using SASL GSSAPI mechanism.

6. Based on the validation result, the ldap_sasl_bind() returns a Success or Failure to the application.

Installing and Configuring the SASL GSSAPI Method

This section explains how to install and configure the SASL GSSAPI method with eDirectory 8.8.2, using Novell Kerberos KDC 1.5.

Use the following steps to get a hands-on SASL GSSAPI setup with eDirectory. Steps 1 - 7 require eDirectory administrator privileges, and eDirectory and KDC can coexist on the same server or can be configured on different servers.

1. Install the GSSAPI method using nmasinst. This method is self replicated, so the installation is common to all the LDAP servers on the tree.

#nmasinst -addmethod admin.novell NOVELL.COM ./config.txt -h server1.novell.com 
Method Added.

2. Install Kerberos LDAP Extensions and restart the LDAP server. (This is optional if the administrator intends to manage the realm using the Kerberos iManager plug-in; in that case it is not required during authentication.)

3. Install Novell Kerberos KDC 1.5 or MIT Kerberos and create a realm. (Refer to the Novell Kerberos KDC 1.5 Quick Start Guide).

4. Start the Kerberos KDC (Administration and Password server optional) server daemon.

#/etc/init.d/krb5kdc start
	Starting Novell KDC server ... done

	#/etc/init.d/kadmind start
	Starting Novell Kerberos Administration server ... done

5. Create an LDAP service principal using kadmin.local.

Note: If this mechanism is setup with MIT Kerberos, then the LDAP service principal Keytab must be extracted from MIT database using "kadmin" and imported into the eDirectory data store using the Kerberos iManager plug-in. This is not required when the GSSAPI mechanism is set up with Novell Kerberos KDC 1.5, as the service principal key is read from the eDirectory server. The administrator should ensure that every LDAP server configured under the same tree requires a separate LDAP service principal to be created for users to authenticate.

#kadmin.local:  add_principal ?randkey ldap/server1.novell.com
WARNING: no policy specified for ldap/serer1.novell.com@NOVELL.COM; defaulting to no policy
Principal "ldap/server1.novell.com@NOVELL.COM" created

6. Create a Kerberos user principal, using kadmin.local. The DN ?cn=user1,o=novell? is assumed to already exist.

#kadmin.local:  add_principal -x dn=cn=user1,o=novell user1@NOVELL.COM
WARNING: no policy specified for user1@NOVELL.COM; defaulting to no policy
Enter password for principal "user1@NOVELL.COM":
Re-enter password for principal "user1@NOVELL.COM":
Principal "user1@NOVELL.COM" created

7. Obtain a TGT for the user principal created above. The following steps are performed by user.

#kinit user1@NOVELL.COM
Password for user1@NOVELL.COM:

8. Launch the LDAP application client. (Here we are using the openldap ldapsearch client.)

9. Specify the mechanism name and perform an LDAP search.

Note: In case the ldapsearch client is run from a different machine other than the KDC servers, then appropriate configuration information (/etc/krb5.conf) must be provided on the client box.

Prerequisites: The following RPM's must be installed on the client machines, as this is being tested with openldap clients.

  • openldap2-client
  • cyrus-sasl-gssapi
#/usr/bin/ldapsearch -Y GSSAPI -b cn=user1,o=novell 

SASL/GSSAPI authentication started
SASL username: user1@NOVELL.COM
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <cn=user1,o=novell> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# user1, novell
dn: cn=user1,o=novell
uid: user1
messageServer: cn=server1,o=novell
sn:: IA==
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1

10. View the credentials obtained:

#klist -f
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user1@NOVELL.COM

Valid starting     Expires            Service principal
07/02/07 20:25:11  07/02/07 22:25:11  krbtgt/NOVELL.COM@NOVELL.COM
        Flags: I
07/02/07 20:25:25  07/02/07 22:25:11  ldap/server1.novell.com@NOVELL.COM
        Flags: T
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached

Deployment Scenarios

The mechanism executes within the Directory Server (eDirectory 8.8.2) address space. It can be configured either with Novell Kerberos KDC 1.5 or the MIT Kerberos setup.

With Novell Kerberos KDC

In this scenario, Novell Kerberos KDC 1.5 uses eDirectory 8.8.2 as a backend data store. Every LDAP identity or DN is mapped to a Kerberos principal (krbPrincipalName attribute) that contains the Kerberos principal name and key. An LDIF of user objects is present in eDirectory.

# user1, novell
dn: cn=user1,o=novell
krbExtraData:: AAJskYhGYWVzdXNlci9hZG1pbkBOS0RDX1JFQUxNAA==
krbPrincipalKey:: zIGSoAMCAQGhAwIBAaIDAgEBowMCAQCkfDB6MEOhQTA/oAMCARChOAQ2GACF QAxuPWsl1WikZ6qAgA1eL9E/LlN+aWDzSClirlQX0vWm2ZzfcqM9CEinYQzxt3/Z0YdEMDOhMTAvoAMCAQGhKAQmCACbyy10piF0W71KM6U68XBuHpepjupqinsWW5HsSUDVNFtWKZ8=
krbPrincipalName: user1@NOVELL.COM
uid: user1
sn: Kerberized User
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: krbPrincipalAux
objectClass: krbTicketPolicyAux
cn: user1

The interaction flow with Novell Kerberos KDC 1.5 is shown below.

Figure 4 - Novell Kerberos KDC 1.5 interaction with the GSSAPI

1. The user on the work station authenticates to the Kerberos KDC and gets an TGT and a service ticket.

2. Novell Kerberos KDC talks to the LDAP server for policy checks and to obtain user information before issuing the ticket.

3. The GSSAPI mechanism reads the LDAP service principal keys from the directory server to verify the Service Ticket received from the client's bind request.

The advantage here is that the realm can be administered using the Kerberos iManager Plug-in or NKDC 1.5 command-line utilities.

With MIT Kerberos

An existing MIT Kerberos deployment can be easily integrated with eDirectory 8.8.2 using the GSSAPI mechanism, providing access to users based on the Kerberos credentials. The existing MIT Kerberos user principal and the LDAP DN are mapped using a Kerberos foreign Principal attribute (krbForeignPrincipalName). The LDAP service principal keys present in the MIT Kerberos database must be imported into eDirectory for the GSSAPI mechanism. The task of mapping and importing the service principal keys is done via the Kerberos iManager interface. An LDIF of user objects is present in eDirectory.

# user1, novell
dn: cn=user1,o=novell
krbForeignPrincipalName: user1@NOVELL.COM
uid: user1
sn: Kerberized User
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: krbPrincipalAux
objectClass: krbForeignPrincipalAux
cn: user1

The interaction flow with MIT Kerberos is shown below.

Figure 5 - MIT Kerberos interaction with the GSSAPI

1. The user on the work station authenticates to the Kerberos KDC and gets an TGT and a service ticket.

2. The LDAP client presents the service ticket (via a call to ldap_sasl_bind) to the SASL GSSAPI method that runs in the eDirectory address space. Here LDAP service keys imported into the eDirectory server are required to be read by the GSSAPI mechanism for verifying user?s bind request.

Conclusion

In summary, the SASL GSSAPI authentication module helps organizations deploy a stronger authentication mechanism to eDirectory (LDAP Server). It also provides Single Sign-on capability using Kerberos credentials.

References

  • RFC 2222, Simple Authentication Security Layer (SASL)
  • RFC 1510, Kerberos Network Authentication Service (V5)
  • MIT Kerberos 5 documentation and installation information
  • Novell Kerberos KDC 1.5 Administration Guide
  • Novell Kerberos KDC 1.5 Quick Start Guide
  • Authentication to eDirectory through SASL-GSSAPI
  • Configuring SASL GSSAPI 2.0 wih eDirectory 8.8.2
  • Novell Kerberos KDC 1.5 Administration iManager plug-in


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell