Hi,
I am in the process of setting up sssd for the first time, so apologies for any simple questions - but I have not been able to find the answer in the archives, docs or elsewhere.
I have two Samba4 Active Directory domain controllers on this site, and would like to configure sssd on each of them for local authentication of users (Samba doesn't support this yet - UID and GID mappings are inconsistent if using samba winbindd this way)
I believe I have sssd configured at a basic level, but am getting a strange error.
Both machines are CentOS 6.6 with sssd-*-1.11.6-30.el6_6.4 packages, Samba 4.2.1 built from source. My (sanitised) sssd.conf is as follows:
[sssd] config_file_version = 2 domains = domain.tld services = nss, pam
[domain/domain.tld] # Once sure everything working OK, change line below to false enumerate = true id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ldap_id_mapping = True ldap_schema = ad default_shell = /bin/bash fallback_homedir = /home/%d/%u
Samba4 works just fine on the machine, and indeed using samba's built in winbindd does work also (but no consistent uid/gid mapping between machines, hence I am trying to configure sssd)
I am starting sssd with "-i -d 0x03F0" flags to get debug information, and from the logs things seem fine up to the following point:
[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.domain.tld'
but then the execution after this looks like it only works 50% of the time, when the above line happens to resolve to the *other* DC (i.e. not the machine I am running sssd on).
I have been testing sssd on one server ("DC1") first of all. When the above DNS query, which I presume is a round-robin type query, resolves to DC1 i.e. the local machine, I get:
[be_resolve_server_process] (0x0200): Found address for server dc1.domain.tld: [1.2.3.4] TTL 900 [ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$@DOMAIN.TLD] [...] [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)] [fo_set_port_status] (0x0100): Marking port 389 of server 'dc1.domain.tld' as 'not working'
However, it's perfectly happy whenever this DNS query resolves to DC2:
[be_resolve_server_process] (0x0200): Found address for server dc2.domain.tld: [1.2.3.5] TTL 900 [ldap_child_get_tgt_sync] (0x0100): Principal name is: [DC1$@DOMAIN.TLD] [...] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$ [child_sig_handler] (0x0100): child [8505] finished successfully. [fo_set_port_status] (0x0100): Marking port 389 of server 'dc2.domain.tld' as 'working' [set_server_common_status] (0x0100): Marking server 'dc2.domain.tld' as 'working'
At first I thought it was something to do with the keytab file (which is a bit of a black box to me and which I don't quite understand). It looks to me as though samba4 has a keytab file containing entries for all users including DC1 and DC2; but I even extracted the keytab for just DC1 and told sssd to use it directly, which made no difference. I'm confused as to why DC1 would have a problem authenticating against itself, whereas DC2 is quite happy for it to do so, using the very same keytab file.
To test this theory I used: # samba-tool domain exportkeytab /etc/krb5-dc1.keytab --principal-DC1$ and added to sssd.conf: krb5_keytab=/etc/krb5-dc1.keytab
but it made no difference when compared to using the 'full' keytab file as I had originally.
I've also cleared cache via "# rm -f /var/lib/sss/db/* /var/lib/sss/mc/*".
Can anyone point me in the right direction? I imagine this works for someone else; but as I've never had sssd configured I'm not sure where to look next.
Thanks,
Jonathan
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:
On Sun, May 10, 2015 at 04:18:58PM +0100, Jonathan Hunter wrote:
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)]
Glad you found out. Yes, Kerberos can be picky about correct host names..
sssd-users@lists.fedorahosted.org