0

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.

  • 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. – pupkinsen Jun 16 '15 at 7:51
  • 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? – Gagravarr Jun 17 '15 at 14:19
2
+200

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.

0

In case you're using Debian, have you recently updated from wheezy to jessie?. I had a similar problem and was that some ldap directives (AuthzLDAPAuthoritative) for apache 2.2 (wheezy) module were removed in apache 2.4 (jessie) module (Upgrading to 2.4 from 2.2). Maybe the same is happening for kerberos.

  • 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. – pupkinsen Jun 16 '15 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.