[30478] in Kerberos
Re: Trouble with service principal missing its realm
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Thu Nov 27 04:02:10 2008
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <492E61C9.6020406@secure-endpoints.com>
Date: Thu, 27 Nov 2008 04:00:57 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: rich.mcdonough@worldgaming.com
In-Reply-To: <9050CEE9-E490-447D-BD59-4F2F9FF21775@worldgaming.com>
Cc: kerberos@mit.edu
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1884298512=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1884298512==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms030108020701050406060502"
This is a cryptographically signed message in MIME format.
--------------ms030108020701050406060502
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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@mail ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_10000
> Default principal: joe@STAGING.WG
>
> Valid starting Expires Service principal
> 11/27/08 02:11:09 11/28/08 02:10:41 krbtgt/STAGING.WG@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@db richm]# klist -ek /etc/krb5.keytab
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
> 7 host/db.wg@STAGING.WG (DES cbc mode with CRC-32)
> 3 ldap/db.wg@STAGING.WG (Triple DES cbc mode with HMAC/sha1)
> 3 ldap/db.wg@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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--------------ms030108020701050406060502
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX
DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI
zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6
6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe
N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK
3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs
/Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1
vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE
+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA
LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU
lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89
93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo
CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn
5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6
TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze
xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wODExMjcwOTAwNTdaMCMGCSqGSIb3DQEJBDEWBBQMj7kx
zzC6H7uvzL124Pbdv1C4gTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ
KoZIhvcNAQEBBQAEggEAMY4+RAcWHjGV7zXvGMYQt1DwcWsk9HY69pLqdhhZ09breyPKHhzh
cpBYbtBSZzLU9e2Ufb4pH7WkeJoWqlYL+IROMV2SVn3MK+tK0wk2xKw6iTZkix/Qe5MtRlif
MRq828DhuGNMEvQO4X/sHqKb9LY2+tGTE9ZjEAnfAwe6qivS+dzR42a6FhEc56kFnSBF4+XS
F4boKvDhKBncRx1zXZb5v/7pf5YQJIrDD3UMMOm/1ounyAD/BD+GU3txiUo+urHWDtxpAADL
pQdxtXaV4hTgSNJ2Oj/YVDUIWFI8lxDBPSr7XC72E76dvFxm12oQSZOaHpupPC1sCdztJPz8
6QAAAAAAAA==
--------------ms030108020701050406060502--
--===============1884298512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1884298512==--
