On Dec 30, 2011, at 3:07 AM, Alexander Blair ablair@hostgator.com wrote:
Hello,
I've been working with FC 16 and SSSD for about two days now trying to get SSSD to properly talk to our Kerberos server, and it seems to continually ignore the fact I've got it configured to do so at this time. Tracking the logs has shown me nothing useful as of yet, and monitoring network traffic on the Krb server itself shows that there's no network communication happening.
I've even gone as far as to completely purge the working directory for it's caches, and force them to rebuild, restarting the box, nothing I've done so far seems to force SSSD to contact Krb for auth information, any ideas on where to take this would be most excellent.
I'm currently using SSSD 1.6.3 from the main FC repos. I've gone though as much troubleshooting information as I can, but as there does not appear to be any errors in my krb5_child.log log, or much else that appears to be useful, so I'm a bit stumped.
/etc/sssd/sssd.conf: [domain/domain]
ldap_id_use_start_tls = False cache_credentials = True ldap_search_base = dc=dc,dc=dc,dc=dc krb5_realm = this.is.a.valid.realm krb5_server = 192.168.100.100 id_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_uri = ldap://192.168.100.200/ krb5_kpasswd = 192.168.100.100 ldap_tls_cacertdir = /etc/openldap/cacerts
Try dropping the trailing slash from the ldap_uri. I'm not sure if we properly trim that offhand. (I'm responding to this from vacation, so I don't have the source handy).
Can you confirm that 'getent passwd user' (where user is a valid LDAP username) returns the expected information?
The way SSSD works is that it will only use the auth_provider for authentication if the user is found in the matching id_provider. This prevents information leaks by sending passwords to unrelated servers. So the first step is to ensure that the user is found in LDAP.
[sssd] services = nss, pam config_file_version = 2
domains = domain [nss]
[pam]
/var/log/sssd/sssd_nss.log -- Debug level 4: (Fri Dec 30 01:46:35 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected! (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>] (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default] (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups] (4): Requesting info for [user] from [<ALL>] (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups_search] (4): Requesting info for [user@default] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>] (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
Thank you, Alexander Blair _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel