Kerberos Web Authentiation with Apache and Solaris 10

Occasionally I hear or read requests from people wanting to use Kerberos authentication for Web access, especially with Firefox and Mozilla since they now have this capability. Below is a document I wrote up a while ago that explains how to do this with Solaris 10. Everything you need to set it up and use it are included in S10 - Mozilla, Apache, Kerberos, and GSSAPI - all are bundled and available today. Hopefully this is helpful...

Single Sign On Web Authentication

This document describes how to configure the various pieces needed to setup a web server to participate in a Kerberos single-sign on (SSO) environment using a standard web server such as Apache or Microsoft IIS. This does not describe specialized Web-SSO systems such as that offered by the Access Manager product.

Introduction

Web based SSO using Kerberos typically means following the specification that Microsoft released which describes how they do Kerberos auth for web. A copy of this (now expired) IETF draft is here.

SPNEGO is an IETF protocol that is used by GSSAPI applications to negotiate the underlying mechanism to be used. It is known as RFC 2478. This is NOT designed specifically for HTTP use and it was not written for the sole purpose of facilitating web-based SSO. There are other security protocols that make use of it, most notably SASL, which is used often for secure LDAP authentication.

There are 3 pieces needed in order to enable this functionality for Single-Sign On Web authentication:

  • A browser that supports the "WWW-Authenticate: Negotiate" header
  • A web server that supports the "Negotiate" authentication feature of HTTP
  • A Kerberos realm and working KDC that issues tickets to the users.

Browsers

Currently, there are 3 browsers that support the "Negotiate" authentication extension.

Mozilla and Firefox

Once you have the necessary browser, you must configure it to support the feature, it is not typically enabled by default. For Mozilla and Firefox, you may need to adjust a couple of private user preferences so that the authentication will be allowed on a non-secure connection (i.e. not SSL).

Setting the Preferences

In the URL window, enter about:config. This brings up a complete list of user preferences that can be set.

Parameters for Mozilla and Firefox

  • network.negotiate-auth.delegation-uris = https://,http://
  • network.negotiate-auth.trusted-uris = https://,http://

Be default, these are usually restricted to just work on "https://" connections (secured by SSL). You may add non-SSL to the allowed list by setting the value to look like this: https://, http://.

You change the values in this window by double-clicking on the preference you wish to set. This brings up a window that allows you to enter a new value.

Microsoft Internet Explorer

To configure IE to allow for SSO authentication:
  • click on the "Tools" menu in the toolbar at the top.
  • Select the "Internet Options" item at the bottom of the menu.
  • Select the "Advanced" tab in the options window that should appear.
  • Scroll down through the various options until you find the section for "security".
  • Click in the box next to "Enable Integrated WIndows Authentication" so that it appears with a check in the box to indicate that it is enabled.
  • Log out and log-back into Windows as a user in a Kerberos realm (either AD or SEAM/MIT) using your name and realm in the login window. Ex: wyllys@SUN.COM

This assumes your windows box is already participating in a Kerberos realm, either managed by Active Directory, or the box is configured to use a non-Windows KDC such as SEAM or MIT. Instructions for setting this up are here: Setting up Kerberos Interop on Windows.

Web Server Configuration

The other important part of the Web-SSO equation is having a properly configured HTTP server that supports the NegotiateAuth extension. Microsoft IIS already supports this and there are extensions for Apache that also enable this feature.

Solaris 10 Apache Configuration

Apache supports extensions to it's authentication system so third parties may add new features easily, without modifying the core Apache engine. There are a couple of extensions available that support the "NegotiateAuth" exchange.

Solaris 10 GSS Authentication Module

mod_auth_gss is an Apache module that enables support for the "NegotiateAuth" exchange on Unix/Linux systems which have GSSAPI support. It only uses GSSAPI to do send either SPNEGO or KRB5 authentication tokens. The user must have a valid Kerberos ticket in their personal credential cache in order for this to work correctly, no passwords are used by the protocol. The user is never prompted for a password and thus the authentication occurs without user interaction, thus "Single Sign On" is achieved.

The benefit of this module over the next one (below), is that it is purely GSSAPI based and does not require access to raw Kerberos libraries in order to compile or run, it only need to link with libgss.so.1. It will support GSSAPI authentication using either SPNEGO (if its available on the system) or Kerberos V5. Currently, only Solaris 10 and Microsoft Windows XP/2000/2003 have SPNEGO support. On other systems, it is assumed that GSSAPI-KRB5 tokens will be used by the client. Other open source Kerberos distributions like Heimdal will soon be (if they haven't already) be offering a SPNEGO mechanism now that the SPNEGO spec has been updated.

The module shipped in Solaris 10's Apache area supports both 1.x and 2.x versions of Apache. The use of SSL encryption is also recommended (but not required).

  • mod_auth_gss is bundled with Apache in Solaris 10. By default, it is installed in /usr/apache/libexec
  • Configuration Instructions

mod_auth_krb5

mod_auth_krb5 is an open-source module that enables support for Kerberos SSO authentication through the NegotiateAuth extension. This module supports the standard GSSAPI + SPNEGO token exchange used in the Microsoft implementation. It also has a couple of nice "extra" features such as the ability to use the password given in the authentication exchange and have the web server request a ticket for the user. This is quite different from the GSSAPI SSO model and is not secure on a non-SSL protected connection because the password passes over the wire virtually unprotected. This method is provided merely as a convenience feature and is not recommended for security.

The downside of this module is that it does not compile on Solaris and use the native Solaris Kerberos code because Solaris does not export the raw Kerberos APIs. Thus, this module requires that the user install a third party Kerberos implementation like MIT or Heimdal in order to build the module. Doing so, the implementor loses the features of the native Kerberos and GSSAPI on Solaris.

IIS Configuration

If you are testing with an IIS web server, the only thing to do is go into the IIS configuration and change the security properties for the areas that you wish to protect so they are using "Integrated Windows Authentication".

Configurating Kerberos

1. Set up Kerberos Server (if you don't already have one). Follow basic instructions given in the SEAM documentation at docs.sun.com.

The KDC should be a protected, standalone system. But for internal testing purposes it may be hosted on the same system as the Apache web server.

2. Create a Kerberos service key for the Apache server to use for authenticating the clients. Also create a user principal testing the browser later. The "Negotiate" method used by IIS and IE looks for a principal named "HTTP/f.q.d.n@REALM" (f.q.d.n == Fully Qualified Domain Name). To create this principal for use with the Apache module do the following: [As 'root', on the Apache server]


a. /usr/sbin/kadmin
- this assumes the KDC setup procedure was followed (step 1).
b. kadmin: addprinc -randkey HTTP/www.foo.com
c. kadmin: ktadd -k /var/apache/http.keytab HTTP/f.q.d.n
d. kadmin: addprinc tester
e. kadmin: quit


Testing the 'Negotiate' plugin with mozilla

1. The client system (Solaris 10) must be configured to use Kerberos. Setup /etc/krb5/krb5.conf to use the KDC created earlier

2. kinit to get a TGT as the "tester" principal created above in step 2d.
$ kinit tester ( enter password )

3. Use mozilla (with 'negotiateauth' extension installed) to access the Kerberos protected pages on your web server.

If it doesn't work, enable the "GSSDebug" variable in the Apache configuration file (see the the Configuration Instructions) and check the Apache "error_log" to see if any messages are being generated that might help indicate the problem.


Configuring mod_auth_gss

Before using GSSAPI authentication with Apache, the system must already have been configured to use Kerberos V5 authentication. All of the major Kerberos V5 implementation (MIT KRB5, Heimdal, Sun, IBM, HP, Microsoft) currently support Kerberos V5 GSSAPI mechanisms. Configuring Kerberos is beyond the scope of this document. Adding GSSAPI authentication support to the web extends Single sign on capabilities to the intranet and reduces the risks involved in having users constantly entering username/password combinations when accessing websites.

Configure a Service Principal

The default service principal that mod_auth_gss will try to use is "HTTP/f.q.d.n". The key for this principal must be stored in a keytab file that is readable by the Apache server, but it should be protected from access by anyone else, and should definitely not be stored in an area that can be browsed by clients.

Example: the Apache server is on host "www.foo.com". Create a principal called "HTTP/www.foo.com". Store the key for this principal in a protected keytab file. Using MIT Kerberos V5:


    $ kadmin
    $ kadmin> ktadd -k /var/apache/http.keytab  HTTP/www.foo.com
    $ kadmin> quit
    

Once the keys are created and stored, using GSSAPI authentication is very simple. Set up the authentication type for the directories being protected to be "GSSAPI". If the keytab or service name chosen is not the defaults ("HTTP" and "/var/apache/http.keytab", respectively), then you may use the above mentioned directives to override the default values. Example:

<Location /var/apache/htdocs/krb5>
	AuthType    GSSAPI
	ServiceName HTTP
	KeytabFile  /var/apache/http.keytab
	GssDebug    0
	Require valid-user
	AllowOverride AuthConfig
</Location>

GSSAPI authentication provides a more secure authentication system, but only works with supporting browsers.

It is recommended that this authentication method be combined with TLS security (mod_ssl, for example) to further secure the authentication data being exchanged.

Comments:

How can mod_auth_gss be best combined with mod_authnz_ldap for authorisation ?

Posted by Markus Moeller on February 28, 2009 at 03:48 AM EST #

In the release of Solaris 10 I tried (update 6), you need to add Auth to command names:
AuthType GSSAPI
AuthGSSServiceName Kerberos
AuthGSSKeytabFile /var/apache2/http.keytab
AuthGssDebug 1
Require valid-user

Posted by Robert Pouliot on July 22, 2009 at 05:18 AM EDT #

I've found this module to be the fastest/easiest way to integrate an Apache server running on Solaris with Active Directory. This module has certainly not got the PR it deserves !

However for integration with AD to really work (at lets be honest: most of us will be using AD as the KDC) some extra features are required:

- Strip off extra info from the username. AD will typically return 'johndoe@mydomain.com' but most likely you really only want the 'johndoe' part.

- Force upper case on the returned identity. Usernames in Windows are case insensitive. You do not want the identity name returned to depend on whether or not the user has logged in in lower case or upper case. I'm not sure if the module when talking to an AD server will return the username as typed when the user logged in or the username (and case) as defined in the AD database regardless of what was used to login. Even in the latter situation chances are that your AD administrator does not pay much attention to case (and being consistent with case) when he configures new users as this really does not matter on Windows. Forcing the returned identity string to upper case is a way to solve this.

I would go as far as saying that the mod_auth_gss module is unusable in Active Directory context without these features. Don't believe me? Try integrating a CMS or a Wiki with Active Directory and you will soon run into exactly these problems. These issues of interoperability are well documented on the Internet and the easiest place to solve them is in the auth module.

I've added these additional features to the module. You can find the new module here: http://kenai.com/projects/mod-auth-gss where you can also find a bit of extra info. Enjoy.

I would be happy to see these additional features of the mod_auth_gss module integrated into standard Solaris.

Posted by lejnar on January 09, 2011 at 08:27 PM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

wyllys

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today