Sorry to reply to my own post, but I think I have tracked this one
down and resolved in the meantime - so am posting to the archive for
posterity in the hope it may help others, also.
I think I have tracked this down to a reverse DNS issue - which was
non-obvious to me.
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(a)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(a)DOMAIN.TLD:
# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
SASL username: myusername(a)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