Trouble with service principal missing its realm

[Jeffrey Altman]

A service ticket in the credential cache without a realm name
is a service ticket that was obtained using server side referrals.
The actual realm name was not specified by the client when
requesting the service ticket.

Your domain_realm mappings provide the client a mapping of
all hosts in the staging.wg domain as being part of the
STAGING.WG realm.  However, the hostname db.wg is not covered
by that mapping.  As a result, server side referrals are used
when requesting the service ticket.

You could work around the problem by providing in the krb5.conf
file a mapping for .wg or db.wg to the STAGING.WG realm.  However,
it would be useful to determine exactly which piece of code is
generating the error you are receiving.  Whichever it is, it
needs to be fixed to deal with server side referrals.

Jeffrey Altman


Rich McDonough wrote:
> 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
>
>
>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20081127/7c6d4d3b/attachment.bin