[SSSD] [SSSD-users] ldap config

Brandon Foster brandon.foster at liferay.com
Fri Apr 26 16:33:06 UTC 2013


On Fri, Apr 26, 2013 at 9:19 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Forwarding back to the sssd-users list, because it contains useful
> information that other developers might need to see. Please make sure
> to keep this list in all replies.
>
> So this confirms my hypothesis. Something is happening during the
> RootDSE lookup that is causing the SSSD to freeze forever here. The
> monitor notices this after 30s and sends a SIGTERM, which is never
> handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
>
> Brandon, can you tell us the exact version of SSSD you are using? You
> can get this by running 'rpm -q sssd'. Please report the entire string
> it gives back.
>
>
> - -------- Original Message --------
> Subject: Re: [SSSD-users] ldap config
> Date: Fri, 26 Apr 2013 09:13:13 -0700
> From: Brandon Foster <brandon.foster at liferay.com>
> To: Stephen Gallagher <sgallagh at redhat.com>
>
> On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher <sgallagh at redhat.com>
> wrote:
>> On 04/25/2013 05:49 PM, Brandon Foster wrote:
>>> No, i never tried to log in during that time, and I did not shut
>>> it down manually, it must have crashed.
>>
>>> So adding in that time out line seems to have done something.
>>> Now with the timeout line it wont even search ldap for my user.
>>> the search does not show up in sssd_default.log, and it still
>>> returns no such user.
>>
>>> here is my sssd.conf with the timeout line:
>>
>>> ------------------------- [sssd] config_file_version = 2 services
>>> = nss, pam domains = default
>>
>>> [nss] filter_users =
>>> root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
>>
>>> [pam]
>>
>>> [domain/default] timeout = 5400 auth_provider = ldap debug_level
>>> = 9 enumerate = True cache_credentials = True chpass_provider =
>>> ldap entry_cache_timeout = 600 ldap_chpass_uri =
>>> ldaps://66.117.7.48:11389/ id_provider = ldap ldap_group_member
>>> = uniquemember ldap_group_object_class = group
>>> ldap_id_use_start_tls = False ldap_pwd_policy = none
>>> ldap_search_base = ou=Liferay\,
>>> Inc.,ou=Organizations,ou=liferay.com,o=Liferay ldap_tls_cacertdir
>>> = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri =
>>> ldaps://66.117.7.48:11389/ ldap_user_gecos = displayName
>>> ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn
>>> ldap_user_object_class = user -----------------------
>>
>>> good news is it isnt crashing anymore. but still not working
>>
>>
>> Ok, so what that suggests to me is that the problem was never
>> *actually* a crash, but instead may have been a tight loop
>> problem. The sssd_be may have gotten into an infinite loop, which
>> prevents it from replying to the ping from the service monitor,
>> which eventually kills it forcibly.
>>
>> Let's try to verify this hypothesis. Please add 'debug_level = 9'
>> to your [sssd] section, remove the 'timeout = 5400' from the
>> [domain/default] section, truncate or delete the logs in
>> /var/log/sssd and restart sssd.
>>
>> Then *run the user login* and send us /var/log/sssd/sssd.log and
>> /var/log/sssd/sssd_default.log
>>
>> This should hopefully give us enough to go on. Sorry for the
>> repeated back-and-forth, but debugging without being able to
>> reproduce the problem locally is tricky.
>>
>>
>> Side-note: I notice you are using "uniquemember" for the member
>> attribute, but you're not setting ldap_schema = rfc2307bis. If I
>> remember correctly 'uniquemember' (like 'member') stores the
>> user/group DN, not the username. If that's correct, you really need
>> to set 'ldap_schema = rfc2307bis' or you won't see group
>> memberships correctly.
>
> thanks again for your help.
>
> as far as the uniquemember, what should this be to be the username?
> Also i dont know which schema my ldap is but i've tried both and
> neither has worked with the current set up.
>
> just as an example i have a user who's dn is:
> cn=testuser,ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=domain
>
> and i want him to log in as testuser. would I then set ldap_group_member
> to cn?
>
> i've attached the complete sssd.log and sssd_default.log
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlF6qPcACgkQeiVVYja6o6OvvgCfShTffrzINj64pTg/sWgqQiDn
> GdwAn1qLAuMkzG9yzxoJaBxz3DnANHH5
> =fwPX
> -----END PGP SIGNATURE-----


yep sorry, was getting lazy with hitting reply.

here is my ssd version
------
root at virt-vm-99:~> rpm -q sssd
sssd-1.9.2-82.4.el6_4.x86_64
--------



More information about the sssd-devel mailing list