> > > > > 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$(a)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.