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:
- steve3 logs in
- id
- logs out On the DC
- sudo samba-tool group addmembers staff steve3
- confirm: sudo samba-tool group listmembers staff
check: steve3 has a member attribute under the DN for staff Back on the client
- steve3 logs in
- id
- getent group staff
- logs out
- sudo service sssd stop
- 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.