[Samba] sssd on a DC

[Jonathan Hunter]

OK, I've got a little further and I think I have tracked this down to
a reverse DNS issue - which was non-obvious to me, so here is a
write-up for the benefit of the archives.

The part that was failing was this:

[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: dc1$
[sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
[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)]

It turns out that the reverse DNS entry for DC1 led to
DC1.my-pre-AD-dns-domain.tld, rather than DC1.domain.tld. This had
been working perfectly for everything else - but evidently kerberos is
a little pickier. I now have sssd working, I think:

[fo_set_port_status] (0x0100): Marking port 389 of server
'dc1.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc1.domain.tld'
as 'working'

I used the following commands to test the GSSAPI element (easier than
reloading sssd and wading through logs):

Failure scenario (wrong reverse DNS):
# kinit myusername
Password for myusername at DOMAIN.TLD:
# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
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)

Success scenario (fixed reverse DNS):
# kinit myusername
Password for myusername at DOMAIN.TLD:
# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
SASL username: myusername at DOMAIN.TLD
SASL SSF: 56
SASL data security layer installed.
dn:


-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein