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.