[SSSD-users] Unexpected result from ldap: Referral(10), 0000202B: RefErr: DSID-0310082F

Sumit Bose sbose at redhat.com
Thu Jun 25 10:32:36 UTC 2015


On Thu, Jun 25, 2015 at 09:13:26AM +0000, Carl Pettersson (EXT BN) wrote:
> > Do you by chance have 'rdns = true' in krb5.conf (or not set at all, because the default is true). If this is the case please set it to 'rdns = false'.
> > 
> > If there are still issues please send the output of
> > 
> > KRB5_TRACE=/dev/stdout ldapsearch -Y GSSAPI ....
> > 
> > which will give more detailed information about Kerberos authentication.
> > 
> > HTH
> > 
> > bye,
> > Sumit
> 
> I did not have that option set, thanks for the suggestion! It did not seem to do much good, unfortunately. Here's some output:
> 
> [root at machine ~]# kinit -k 'MACHINE$@AD.EXAMPLE.COM'
> 
> [root at machine ~]# KRB5_TRACE=/dev/stdout ldapsearch -h foo-ad02.a.foo.com -N -Y GSSAPI -b OU=XYZ,DC=a,DC=foo,DC=com
> SASL/GSSAPI authentication started
> [23554] 1435222083.725320: ccselect can't find appropriate cache for server principal ldap/foo-ad02.a.foo.com@
> [23554] 1435222083.725550: Retrieving MACHINE$@AD.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [23554] 1435222083.725601: Getting credentials MACHINE$@AD.EXAMPLE.COM -> ldap/foo-ad02.a.foo.com@ using ccache FILE:/tmp/krb5cc_0
> [23554] 1435222083.725666: Retrieving MACHINE$@AD.EXAMPLE.COM -> ldap/foo-ad02.a.foo.com@ from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [23554] 1435222083.725695: Retrying MACHINE$@AD.EXAMPLE.COM -> ldap/foo-ad02.a.foo.com at AD.EXAMPLE.COM with result: -1765328243/Matching credential not found
> [23554] 1435222083.725708: Server has referral realm; starting with ldap/foo-ad02.a.foo.com at AD.EXAMPLE.COM
> [23554] 1435222083.725746: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM at AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
> [23554] 1435222083.725753: Found cached TGT for service realm: MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM at AD.EXAMPLE.COM
> [23554] 1435222083.725760: Requesting tickets for ldap/foo-ad02.a.foo.com at AD.EXAMPLE.COM, referrals on
> [23554] 1435222083.725826: Generated subkey for TGS request: aes256-cts/78C8
> [23554] 1435222083.725842: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac
> [23554] 1435222083.726499: Sending request (1456 bytes) to AD.EXAMPLE.COM
> [23554] 1435222083.727195: Sending initial UDP request to dgram 192.168.130.2:88
> [23554] 1435222083.731057: Received answer from dgram 192.168.130.2:88
> [23554] 1435222083.731166: Response was from master KDC
> [23554] 1435222083.731208: TGS request result: -1765328377/Server not found in Kerberos database
> [23554] 1435222083.737234: Local realm referral failed; trying fallback realm A.FOO.COM
> [23554] 1435222083.737351: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/A.FOO.COM at AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [23554] 1435222083.737390: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM at AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
> [23554] 1435222083.737399: Starting with TGT for client realm: MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM at AD.EXAMPLE.COM
> [23554] 1435222083.737430: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/A.FOO.COM at AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> [23554] 1435222083.737438: Requesting TGT krbtgt/A.FOO.COM at AD.EXAMPLE.COM using TGT krbtgt/AD.EXAMPLE.COM at AD.EXAMPLE.COM
> [23554] 1435222083.737467: Generated subkey for TGS request: aes256-cts/DCAC
> [23554] 1435222083.737476: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac
> [23554] 1435222083.737569: Sending request (1449 bytes) to AD.EXAMPLE.COM
> [23554] 1435222083.737710: Sending initial UDP request to dgram 192.168.130.2:88
> [23554] 1435222083.739749: Received answer from dgram 192.168.130.2:88
> [23554] 1435222083.739823: Response was from master KDC
> [23554] 1435222083.739839: TGS request result: -1765328377/Server not found in Kerberos database
> ldap_sasl_interactive_bind_s: Local error (-2)
>         additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)
> 
> One thing I just noticed is that it seems that there is actually never any communication with the trusted domain, whose servers are in the 10.28-subnet. Ours are in 192.168.130. Does this indicate an issue with the trust, or with the machine I'm working from?

I would say it indicates an issue with the trust.

You are taking to 192.168.130.2 (a DC from AD.EXAMPLE.COM) to get a
cross-realm TGT krbtgt/A.FOO.COM at AD.EXAMPLE.COM which would allow you to
get service tickets for a service in the A.FOO.COM realm form a DC of
the A.FOO.COM realm. But 192.168.130.2 returns 'Server not found in
Kerberos database'. So it either does not know A.FOO.COM or there is a
one-way trust going to the wrong direction.

Btw, is A.FOO.COM a domain in the AD.EXAMPLE.COM forest or is it form a
different forest. If it is from a different forest but not the forest
root you might have to add a [capaths] section to krb5.conf helping
libkrb5 to find what it the forest root of the trusted forest. We
already have code in SSSD to add this to the Kerberos configuration but
so far it is only available for the IPA provider since the AD provider
currently does not support forest trust.

HTH

bye,
Sumit

> 
> Best regards,
> Carl
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users


More information about the sssd-users mailing list