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 [EMAIL PROTECTED] ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_1
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
11/27/08 02:11:09 11/28/08 02:10:41 krbtgt/[EMAIL PROTECTED]
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 [EMAIL PROTECTED] richm]# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
--
7 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32)
3 ldap/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1)
3 ldap/[EMAIL PROTECTED] (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@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
smime.p7s
Description: S/MIME Cryptographic Signature
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
