Re: [SSSD-users] Unexpected result from ldap: Referral(10), 0000202B: RefErr: DSID-0310082F
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error: (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$ (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372]. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn't get the reply to my mailbox, but read your answer on the archive web)
Best regards, Carl
On Wed, Jun 24, 2015 at 06:38:21PM +0000, Carl Pettersson (EXT BN) wrote:
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error: (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$ (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372]. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn't get the reply to my mailbox, but read your answer on the archive web)
Best regards, Carl
This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
On Wed, Jun 24, 2015 at 06:38:21PM +0000, Carl Pettersson (EXT BN) wrote:
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error: (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$ (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372]. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn't get the reply to my mailbox, but read your answer on the archive web)
Best regards, Carl
This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
Tickets seem fine: # kinit myuser@A.FOO.COM Password for myuser@A.FOO.COM: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: myuser@A.FOO.COM
Valid starting Expires Service principal 06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM@A.FOO.COM renew until 07/01/15 20:52:34
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
Carl
On Wed, Jun 24, 2015 at 07:03:26PM +0000, Carl Pettersson (EXT BN) wrote:
On Wed, Jun 24, 2015 at 06:38:21PM +0000, Carl Pettersson (EXT BN) wrote:
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error: (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$ (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372]. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully. (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn't get the reply to my mailbox, but read your answer on the archive web)
Best regards, Carl
This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
Tickets seem fine: # kinit myuser@A.FOO.COM Password for myuser@A.FOO.COM: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: myuser@A.FOO.COM
Valid starting Expires Service principal 06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM@A.FOO.COM renew until 07/01/15 20:52:34
I'm sorry, I wasn't specific enough. I wanted you to test the same identity SSSD uses, which is the machine account from the keytab (klist -k would show you the principals)
But I think even with the user principal, you found the issue..
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Would it help if you add a record to /etc/hosts?
This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
Tickets seem fine: # kinit myuser@A.FOO.COM Password for myuser@A.FOO.COM: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: myuser@A.FOO.COM
Valid starting Expires Service principal 06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM@A.FOO.COM renew until 07/01/15 20:52:34
I'm sorry, I wasn't specific enough. I wanted you to test the same identity SSSD uses, which is the machine account from the keytab (klist -k would show you the principals)
Oh, ok. How would I do that, though? The machine account doesn't have a known password, right? kinit 'MACHINE$@AD.EXAMPLE.COM' prompt for it. Nevertheless, I already had a ticket, according to klist -k.
But I think even with the user principal, you found the issue..
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket. Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
On Wed, Jun 24, 2015 at 07:42:48PM +0000, Carl Pettersson (EXT BN) wrote:
This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
Tickets seem fine: # kinit myuser@A.FOO.COM Password for myuser@A.FOO.COM: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: myuser@A.FOO.COM
Valid starting Expires Service principal 06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM@A.FOO.COM renew until 07/01/15 20:52:34
I'm sorry, I wasn't specific enough. I wanted you to test the same identity SSSD uses, which is the machine account from the keytab (klist -k would show you the principals)
Oh, ok. How would I do that, though? The machine account doesn't have a known password, right? kinit 'MACHINE$@AD.EXAMPLE.COM' prompt for it. Nevertheless, I already had a ticket, according to klist -k.
kinit -k 'MACHINE$@AD.EXAMPLE.COM'
that would use the keytab to authenticate (think of the keytab as a password on a disk)
But I think even with the user principal, you found the issue..
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket.
Interesting, I /thought/ that's what we did in SSSD as well..I'll check the code again.
Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
If you kinit with -k as shown above, then the acquired ticket should be used automatically.
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
I meant to use the public IP for machine.ad.example.com
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket.
Interesting, I /thought/ that's what we did in SSSD as well..I'll check the code again.
Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
If you kinit with -k as shown above, then the acquired ticket should be used automatically.
Ah, that did it! However, ldapsearch with this ticket gives the not found in database error:
SASL/GSSAPI authentication started 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)
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
I meant to use the public IP for machine.ad.example.com
Added that, but it seemed to have no impact on the results of ldapsearch.
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket.
Interesting, I /thought/ that's what we did in SSSD as well..I'll check the code again.
Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
If you kinit with -k as shown above, then the acquired ticket should be used automatically.
Ah, that did it! However, ldapsearch with this ticket gives the not found in database error:
SASL/GSSAPI authentication started 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)
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
I meant to use the public IP for machine.ad.example.com
Added that, but it seemed to have no impact on the results of ldapsearch.
I've contacted the administrators of the other domain and asked them to create the appropriate forwarder for our PTR records. While waiting for that, is there any explanation that it works for Windows clients? Can they do some Microsoft magic(tm) to get around this, or what is going on?
Best regards, Carl
On Thu, Jun 25, 2015 at 06:37:14AM +0000, Carl Pettersson (EXT BN) wrote:
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket.
Interesting, I /thought/ that's what we did in SSSD as well..I'll check the code again.
Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
If you kinit with -k as shown above, then the acquired ticket should be used automatically.
Ah, that did it! However, ldapsearch with this ticket gives the not found in database error:
SASL/GSSAPI authentication started 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)
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
I meant to use the public IP for machine.ad.example.com
Added that, but it seemed to have no impact on the results of ldapsearch.
I've contacted the administrators of the other domain and asked them to create the appropriate forwarder for our PTR records. While waiting for that, is there any explanation that it works for Windows clients? Can they do some Microsoft magic(tm) to get around this, or what is going on?
Best regards, Carl
To be honest, I don't know. Chances are they read much of the info from a PAC or don't require the A/PTR records to match.
I believe recent version of MIT Kerberos library is not picky regarding the A/PTR match anymore.
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 25 June 2015 10:28 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] Unexpected result from ldap: Referral(10), 0000202B: RefErr: DSID-0310082F
To be honest, I don't know. Chances are they read much of the info from a PAC or don't require the A/PTR records to match. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
On Wed, Jun 24, 2015 at 08:48:29PM +0000, Carl Pettersson (EXT BN) wrote:
Ldapsearch does not look good: # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=... SASL/GSSAPI authentication started 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 (Cannot determine realm for numeric host address)
And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse.
OK, then I think this is the issue. btw it help to add -N to the ldapsearch options to tell libldap to not canonicalize the hostnames?
Yes, -N allowed me to query the other domain, when I used the myuser-ticket.
Interesting, I /thought/ that's what we did in SSSD as well..I'll check the code again.
Removing that, however, I get the same error as before. I'm not familiar with ldapsearch, but I tried using -U 'MACHINE$@AD.EXAMPLE.COM' to make it use the machine ticket, but that didn't seem to work.
If you kinit with -k as shown above, then the acquired ticket should be used automatically.
Ah, that did it! However, ldapsearch with this ticket gives the not found in database error:
SASL/GSSAPI authentication started 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)
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
Would it help if you add a record to /etc/hosts?
My hosts-file contains only this row: 127.0.0.1 machine.ad.example.com machine localhost
Should that be enough, or do you mean some other row?
I meant to use the public IP for machine.ad.example.com
Added that, but it seemed to have no impact on the results of ldapsearch. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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@machine ~]# kinit -k 'MACHINE$@AD.EXAMPLE.COM'
[root@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@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@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@AD.EXAMPLE.COM [23554] 1435222083.725746: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@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@AD.EXAMPLE.COM [23554] 1435222083.725760: Requesting tickets for ldap/foo-ad02.a.foo.com@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@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@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@AD.EXAMPLE.COM [23554] 1435222083.737430: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/A.FOO.COM@AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [23554] 1435222083.737438: Requesting TGT krbtgt/A.FOO.COM@AD.EXAMPLE.COM using TGT krbtgt/AD.EXAMPLE.COM@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?
Best regards, Carl
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@machine ~]# kinit -k 'MACHINE$@AD.EXAMPLE.COM'
[root@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@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@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@AD.EXAMPLE.COM [23554] 1435222083.725746: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM@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@AD.EXAMPLE.COM [23554] 1435222083.725760: Requesting tickets for ldap/foo-ad02.a.foo.com@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@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@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@AD.EXAMPLE.COM [23554] 1435222083.737430: Retrieving MACHINE$@AD.EXAMPLE.COM -> krbtgt/A.FOO.COM@AD.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [23554] 1435222083.737438: Requesting TGT krbtgt/A.FOO.COM@AD.EXAMPLE.COM using TGT krbtgt/AD.EXAMPLE.COM@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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Jun 25, 2015 at 09:13:26AM +0000, Carl Pettersson (EXT BN) wrote:
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@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
After a bit of troubleshooting, there seems to be some problem in the RPC port negotiation between the domain controllers. "Verify trust" works on some domain controllers, but not all, and not the ones in the Site in which I'm testing sssd. I'll get to fixing the network issues.
Thanks for all the help!
Carl
Carl Pettersson (EXT BN) skrev den 2015-06-24 20:38:
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error:
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)]
Does MACHINE have a corresponding computer account in AD?
Regards Davor
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372].
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully.
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn’t get the reply to my mailbox, but read your answer on the archive web)
Best regards,
Carl
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Carl Pettersson (EXT BN) skrev den 2015-06-24 20:38:
No, it's a bug in SSSD.
6.6 is already quite old in SSSD terms, could you please try a newer
version from this COPR repo?
1.12.5 is more-or-less equivalent to what 6.7 will include..
Thanks! I installed that version, and now I get a different error:
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)]
Does MACHINE have a corresponding computer account in AD?
Regards Davor
Yes (in the ad.example.com domain)
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372].
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully.
(Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
(I hope this gets threaded properly, I didn’t get the reply to my mailbox, but read your answer on the archive web)
Best regards,
Carl
sssd-users@lists.fedorahosted.org
-
Carl Pettersson (BN) -
Davor Vusir -
Jakub Hrozek -
Ondrej Valousek -
Sumit Bose