>
> 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?
Cheers,
Steve