Apache 2.2 mod_auth_kerb SSO stopped working

Question

I'm all out of ideas why has it just stopped working, here's what I checked:

httpd-error.log:

[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1758): [client 10.105.5.131] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1758): [client 10.105.5.131] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1264): [client 10.105.5.131] Acquiring creds for HTTP/<FQDN>@<LOCAL.DOMAIN>
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1411): [client 10.105.5.131] Verifying client data using KRB5 GSS-API
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1427): [client 10.105.5.131] Client didn't delegate us their credential
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1446): [client 10.105.5.131] GSS-API token of length 22 bytes will be sent back
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1758): [client 10.105.5.131] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1264): [client 10.105.5.131] Acquiring creds for HTTP/<FQDN>@<LOCAL.DOMAIN>
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1411): [client 10.105.5.131] Verifying client data using KRB5 GSS-API
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1427): [client 10.105.5.131] Client didn't delegate us their credential
[Thu Jun 11 18:04:21 2015] [debug] src/mod_auth_kerb.c(1125): [client 10.105.5.131] GSS-API major_status:00090000, minor_status:00000000

-

sudo kinit -t /etc/krb5.keytab HTTP/<FQDN> 

works fine, no errors

sudo klist:

Credentials cache: FILE:/tmp/krb5cc_0
    Principal: HTTP/<FQDN>@<LOCAL.DOMAIN>

Issued                Expires               Principal
Jun 11 17:21:58 2015  Jun 12 00:01:57 2015  krbtgt/<LOCAL.DOMAIN>@<LOCAL.DOMAIN>

krb5.conf

[libdefaults]
 ticket_lifetime = 24000
 default_realm = <LOCAL.DOMAIN>
 dns_lookup_realm = false
 dns_lookup_kdc = false
 default_keytab_name = /etc/krb5.keytab
 rdns = false

[realms]
 KC.KPLUS = {
  kdc = <dc.ip>:88
  admin_server = <dc.ip>:88
  default_domain = <LOCAL.DOMAIN>
 }

[domain_realm]
 .<local.domain> = <LOCAL.DOMAIN>
 <local.domain> = <LOCAL.DOMAIN>



[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

.htaccess

AddHandler cgi-script .cgi .pl
Options +ExecCGI
DirectoryIndex index.pl
AuthName "<LOCAL.DOMAIN>"
AuthType Kerberos
Krb5Keytab /etc/krb5.keytab
KrbAuthRealm <LOCAL.DOMAIN>
KrbMethodNegotiate on
KrbServiceName HTTP/<FQDN>@<LOCAL.DOMAIN>
KrbMethodK5Passwd off
KrbSaveCredentials on
KrbVerifyKDC off
Require valid-user

Checked the traffic on the client side, apparently it starts Negotiate, agrees on KRB5 mech and sends the ticket. Receives 401 as a result.

I can't figure out what is wrong here, any ideas would be appreciated.

Solution

This happens when there's a mismatch between the SPNs listed in the keytab and the Principal Name provided by the client (the browser).

It could depend by the browser used (some browsers take the name from the URL, some other do a reverse lookup of the ip address they're connecting to).

The common solution to this is setting KrbServiceName to Any:

    KrbServiceName Any

This will relax the check, allowing any key in the server's keytab to be used.

Comments

[pupkinsen]

Ok I've changed KrbServiceName HTTP/<FQDN>@<LOCAL.DOMAIN> to KrbServiceName Any and it works. I'd still like to know why exactly did it work for a while and then just stop.

[Gagravarr]

On the client side, if you do a klist after trying and failing to authenticate from your browser, does it show a ticket for the HTTP/<FQDN>@<LOCAL.DOMAIN> service principal? And does your Apache keytab have any other entries in other than the HTTP principal?

[pupkinsen]

Sorry, I should have mentioned the system in the original question, it's FreeBSD 10.1. Apache version is 2.2 and didn't change.