Trouble with service principal missing its realm

Rich McDonough rich.mcdonough at worldgaming.com
Wed Nov 26 21:41:42 EST 2008


I'm having a strange issue that is proving very troublesome to  
diagnose, and I've been unable to reproduce it on another network.  
We're working toward rolling-out Kerberos and OpenLDAP on our staging  
and production networks shortly, but are having a strange issue that  
is likely simple to solve, but still eludes us.

In short, our service principals look like this after trying to do an  
ldapwhoami or other such operations, and incidentally maybe the cause  
of an issue with mod_auth_kerb as well (though I won't stray into that  
right now):

staging [richm at mail ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_10000
Default principal: joe at STAGING.WG

Valid starting     Expires            Service principal
11/27/08 02:11:09  11/28/08 02:10:41  krbtgt/STAGING.WG at STAGING.WG
11/27/08 02:11:57  11/28/08 02:10:41  ldap/db.wg@

The missing @STAGING.WG seems to be causing issues with GSSAPI and  
LDAP as they are (rightly, I believe) returning an error 144 (wrong  
principal in request). I'm fairly sure that this is a configuration  
issue or course, and not really sure how I'm getting a service  
principal like this in the first place. Here's our krb5.conf:

[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  default_realm = STAGING.WG
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  STAGING.WG = {
   kdc = db.wg:88
   admin_server = db.wg:749
   default_domain = staging.wg
  }

[domain_realm]
  .staging.wg = STAGING.WG
  staging.wg = STAGING.WG

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

Also, lookups for hosts work both forward and reverse without issue, / 
etc/hosts files are in good shape and hostnames are certainly right.  
LDAP and Kerberos are both running on the same host (db), and the /etc/ 
krb5.keytab looks like this, and has been made world-readable (though  
once things are working I obviously want to move the ldap service  
principal to its own keytab):

staging [root at db richm]# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----  
--------------------------------------------------------------------------
    7 host/db.wg at STAGING.WG (DES cbc mode with CRC-32)
    3 ldap/db.wg at STAGING.WG (Triple DES cbc mode with HMAC/sha1)
    3 ldap/db.wg at STAGING.WG (DES cbc mode with CRC-32)

Finally, here is the kdc.conf from our system:

[kdcdefaults]
  v4_mode = nopreauth
  kdc_tcp_ports = 88

[realms]
  STAGING.WG = {
   #master_key_type = des3-hmac-sha1
   acl_file = /var/kerberos/krb5kdc/kadm5.acl
   dict_file = /usr/share/dict/words
   admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
   #supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal des- 
hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4  
des-cbc-crc:afs3
   supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal
  }

We're running CentOS 5.2 x64. Thank you for any assistance that you  
can give us!



Rich McDonough








More information about the Kerberos mailing list