On 21/09/2015 17:06, Sumit Bose wrote:
On Mon, Sep 21, 2015 at 03:10:50PM +0100, John Beranek wrote:
> Where I work I've just spent a fair amount of time tracing down an issue we
> were having with Linux servers (CentOS 6) which authenticate against the
> company Active Directory domain.
> We found that SSSD 1.12.4-46.el6 clients were failing to work correctly
> against a particular DC in one of our sites. Looking in the SSSD logs I
> discovered it was a Kerberos "TGS-REQ" issue, whereby it would do a
> and get back "Principal unknown".
> Given we didn't believe the 3 extra PTRs were performing any useful
> function, we deleted them, and started SSSD again. SSSD now happily
> connected to the DC, and is functional.
> So, is there any reason why these PTRs would have upset SSSD like they
> appear to have?
SSSD tries to detect the environment mostly with DNS SRV requests. In
general it tries a DNS query for _ldap._tcp.domain.name. In an AD
environment where you have sites SSSD first tries to determine the site
with the help of a CLDAP request to a DC and then use a query like
_ldap._tcp.sitename._sites.domain.name to only get the DCs for the given
site. The names returned by the query are considered a valid host names
for which Kerberos service tickets can be requested.
Well, in this case I've
disabled site selection in order to force SSSD
to connect to the troublesome DC, so it doesn't do that...
I don't understand quite why SSSD might be performing a reverse lookup
on a selected DC's IP, and then using that in a Kerberos request, if
that is in fact what it's doing.
are special names in
which return all DCs in the forest or in the domain respectively.
is a special AD SRV record. All do not represent a
single DC but a collection of them and hence cannot be used to get a
Kerberos ticket. Since they do not relate to a single host I think they
should not have a PTR record assigned.
It does appear that only one of our DCs had
those PTRs defined, and
apparently manually, not automatically added by the DC.
> I can supply SSSD logs and/or pcap files off-list if helpful...
SSSD logs would be nice. I would like to understand why SSSD fails here
and does not continue until the finds a name for which a Kerberos ticket
can be returned successful. Feel free to send the log to me directly.
log files and config file to Sumit directly.