Hello,
I got a chance to work on this/look into this, and getent passwd user is
returning the expected results with sssd on, and nothing with sssd off,
as should be expected. The addition or removal of the / on the ldap URL
had no results on my testing.
I tacked strace's onto the various processes as I was authenticating,
and verified that it did contact the ldap server, and was able to get
all the ldap related data. I have also verified that the server can
contact the Kerberos server at this time via kinit after a su <user> -,
where <user> is a user that only exists in the ldap directory, so it
appears that it's something with SSSD not properly contacting the Krb
server, I'm unable to track exactly how it should be doing this, so any
suggestions would be appreciated, and I'm happy to provide any
additional information I can about our setup related to this.
Thank you,
Alexander Blair
On 12/31/2011 07:14 AM, Stephen Gallagher wrote:
On Dec 30, 2011, at 3:07 AM, Alexander Blair<ablair(a)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(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel