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@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@DOMAIN.TLD: # ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started SASL username: myusername@DOMAIN.TLD SASL SSF: 56 SASL data security layer installed. dn: