[SSSD-users] Unexpected result from ldap: Referral(10), 0000202B: RefErr: DSID-0310082F
Jakub Hrozek
jhrozek at redhat.com
Wed Jun 24 19:52:39 UTC 2015
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 at A.FOO.COM
> > > Password for myuser at A.FOO.COM:
> > > # klist
> > > Ticket cache: FILE:/tmp/krb5cc_0
> > > Default principal: myuser at A.FOO.COM
> > >
> > > Valid starting Expires Service principal
> > > 06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM at 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
More information about the sssd-users
mailing list