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_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.
