[SSSD] debbuging, how to turn off cache [SOLVED]

steve steve at steve-ss.com
Fri Apr 19 14:48:15 UTC 2013


On 04/19/2013 02:24 PM, Jakub Hrozek wrote:
> On Fri, Apr 19, 2013 at 12:45:36PM +0200, steve wrote:
>>>> I suggest the following test:
>>>> log into a box via sssd
>>>> do id
>>>> change user membership on the server
>>>> lock screen/unlock screen (login/logout as a variant)
>>>> do id
>>> Hi
>>> Test performed using domain group staff (there is no local group
>>> called staff). User steve3 is not a member of staff.
>>>
>>> method:
>>>     On the client:
>>> 1. steve3 logs in
>>> 2. id
>>> 3. logs out
>>>     On the DC
>>> 1. sudo samba-tool group addmembers staff steve3
>>> 2. confirm: sudo samba-tool group listmembers staff
>>> check: steve3 has a member attribute under the DN for staff
>>>     Back on the client
>>> 1. steve3 logs in
>>> 2. id
>>> 3. getent group staff
>>> 4. logs out
>>> 5. sudo service sssd stop
>>> 6. tar made of the log files
>>>
>>> result:
>>> On the second login, id shows that steve3 is not recognised as a
>>> staff group member.
>>>
>>> conclusion:
>>> sssd has not read the user information from LDAP
>>>
>>> The logs at debug_level = 9 are here:
>>> https://dl.dropboxusercontent.com/u/45150875/sssd.client.log.tar
>>> Please note that entry_cache_timeout has no effect on these findings
>>>
>>> /etc/sssd/sssd.conf
>>> [sssd]
>>> debug_level = 9
>>> services = nss, pam
>>> config_file_version = 2
>>> domains = default
>>>
>>> [nss]
>>> debug_level = 9
>>>
>>> [pam]
>>> debug_level = 9
>>>
>>> [domain/default]
>>> debug_level = 9
>>> ldap_schema = rfc2307bis
>>> access_provider = simple
>>> enumerate = FALSE
>>> #entry_cache_timeout = 10
>>> cache_credentials = true
>>> id_provider = ldap
>>> auth_provider = krb5
>>> chpass_provider = krb5
>>> krb5_realm = DOLORES.SITE
>>> krb5_server = doloresdc.dolores.site
>>> krb5_kpasswd = doloresdc.dolores.site
>>>
>>> ldap_uri = ldap://doloresdc.dolores.site/
>>> ldap_search_base = dc=dolores,dc=site
>>> #ldap_tls_cacertdir = /usr/local/samba/private/tls
>>> #ldap_id_use_start_tls = true
>>> ldap_user_object_class = user
>>> ldap_user_name = samAccountName
>>> ldap_user_uid_number = uidNumber
>>> ldap_user_gid_number = gidNumber
>>> ldap_user_home_directory = unixHomeDirectory
>>> ldap_user_shell = loginShell
>>> ldap_group_object_class = group
>>> ldap_group_search_base = dc=dolores,dc=site
>>> ldap_group_name = cn
>>> ldap_group_member = member
>>>
>>> ldap_sasl_mech = gssapi
>>> ldap_sasl_authid = ALGORFA$
>>> ldap_krb5_keytab = /etc/krb5.keytab
>>> ldap_krb5_init_creds = true
>>>
>>> Thanks for your time,
>>> Steve
>>>
>> UPDATE
>> It seems that sssd can't contact the LDAP server, in this case a
>> stable Samba 4 installation. Samba 4 reports LDAP_PROTOCOL_ERROR
>> when a member logs in. We can however ldapserach, ldbsearch,
>> ldapmodify and ldbmodify just fine either using plain password or
>> GSSAPI. We have also tried using the domain Administrator to
>> authenticate rather than the machine account. Could this be a sssd
>> bug?
> If ldapsearch works, but sssd does not, then it might be a sssd bug. But
> can you check from the logs after which exact operation the
> LDAP_PROTOCOL_ERROR happens? Maybe we could then reproduce the bug
> locally or perhaps sssd is "just" using some kind of control it
> shouldn't.
Hi
The LDAP_PROTOCOL_ERROR occurs once during user authentication and again 
upon logging out. It does not occur with getent or at ny other time 
during the session. I'm almost certain that this has something to do 
with sssd; users authenticating against nslcd or winbind do not produce 
this response from the Samba4 ldap. I'll post over on samba-technical to 
see if they can help.
Cheers,
Steve



More information about the sssd-devel mailing list