Kerberos credentials not forwarded to openldap using mod_auth_kerb/Apache2, Authen::SASL/perl

Question

I'm writing a web frontend to manage our company's OpenLDAP server. I'm using Perl, Apache2, OpenLDAP, Cyrus SASL.

The problem is, I cannot authenticate to OpenLDAP as Kerberos-verified user when using web interface, because my Kerberos credentials are not forwarded, and Apache error log says:

Credentials cache file '/tmp/krb5cc_33' not found

where "33" is the uidNumber for Apache. Which makes sense, but doesn't solve the problem. Ironically, it all works from outside the realm, because then mod_auth_kerb asks for user name and password, authenticates, caches the tickets, and it all works.

I'm using mod_auth_kerb to authenticate to Apache2, and it works fine: password not prompted, protected page displayed to authenticated user (and rejected otherwise). The relevant fragment of config:

<Directory "/usr/lib/cgi-bin">
            AllowOverride None
            Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
            Order allow,deny
            Allow from all 
            AuthType Kerberos
            AuthName "Kerberos Login"
            KrbAuthRealms EXAMPLE.COM
            Krb5Keytab /etc/apache2/HTTP.keytab
            KrbServiceName HTTP
            KrbSaveCredentials on
            require valid-user
    </Directory>

Kerberos/GSSAPI/SASL authentication works fine as well, so this code gives OK when run from command line:

1 #!perl
  2 use strict;
  3 use warnings;
  4 use Net::LDAP;
  5 use Authen::SASL;
  6 
  7 my $l = Net::LDAP->new( 'ldap.example.com', onerror=>'die', );
  8 my $sasl = Authen::SASL->new(mechanism=>'GSSAPI');
  9 $l->bind( sasl=>$sasl );
 10 
 11 print "OK\n";

So, what might be the solution?

Answer 1

Web browsers do not forward Kerberos tickets by default. (Thankfully! It would be a huge security issue, since the browser would just be handing out your tickets to any web site in your local realm that asked for them.)

Unfortunately, getting the browser to do so requires some effort. For example, in Firefox, you have to go into about:config and customize network.negotiate-auth.delegation-uris to add the URLs to which you're willing to delegate tickets. (I think there's a similar procedure in IE to mark the web site as part of the trusted domain.)

Unless you have a lot of control over the browser environment, this is usually a dead end. Most people just have the web application authenticate as itself (rather than as the user) and give it general read access. Alternatively, you can use a more comprehensive site-wide web authentication system that supports credential delegation, but that may be overkill for your situation.

Two implementations that do support this are:

• WebAuth
• CoSign

These both are client/server enterprise web authentication systems that require setting up some infrastructure.