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

steve steve at steve-ss.com
Fri Apr 19 05:39:52 UTC 2013


On 04/18/2013 11:45 PM, Dmitri Pal wrote:
> On 04/18/2013 05:07 PM, steve wrote:
>> On 04/18/2013 10:29 PM, Dmitri Pal wrote:
>>> On 04/18/2013 05:30 AM, John Hodrien wrote:
>>>> On Thu, 18 Apr 2013, steve wrote:
>>>>
>>>>> Having the user login has no effect. getent still shows him as
>>>>> memberOf (he appears alongside his now primary group and not, as
>>>>> should happen, alongside his secondary group).
>>>> Perhaps I was misunderstanding.  I thought you were changing a user's
>>>> primary
>>>> group, and weren't seeing that updated.  I'd expect you to have to
>>>> wait to the
>>>> cache to clear, or do:
>>>>
>>>> sss_cache -u thatuser
>>>>
>>>> Maybe I was misunderstanding what you're trying to do.
>>>>
>>>>>> Can I just query one thing?  Why on earth are you changing user
>>>>>> attributes
>>>>>> for users so frequently?
>>>>> Yes. Thanks. We have to justify from winbind, nslcd or sssd for a
>>>>> situation where 600 users can login to any one of around 80 machines
>>>>> in a Samba4 domain. Adding/removing a user to a group is quite
>>>>> common. This is not recognised on the clients unless root intervenes:
>>>>> Impossible! Less common, but common enough in our environment is
>>>>> moving a user's home directory.
>>>> It's not recognised on the clients until the cache expires, but I
>>>> don't see
>>>> how that can not be the case.  This'd also be the case with windows,
>>>> where the
>>>> user's PAC will be used to verify group membership, which often means
>>>> forcing
>>>> a user to log off and back on again to update group membership.
>>>>
>>>>> We've eliminated winbind and are left with nslcd which is time
>>>>> consuming to implement (but which passes all the tests), and sssd
>>>>> with it's point and click configuration. We'd really like to go with
>>>>> sssd but we have to prove in a test lab that what we do will be
>>>>> covered. We simply have to maintain the domain centrally. We cannot
>>>>> visit 80 clients everytime a change is made.
>>>> Group membership changes propogate in our environment just fine
>>>> within a
>>>> reasonable period of time.  What should we be talking by default, 5
>>>> minutes?
>>>>
>>>>>> Forget the effect sssd has, you're completely hanging out to dry any
>>>>>> running
>>>>>> processes of these users everytime you do this.
>>>>>>
>>>>> As I say, nslcd copes with this. I'm trying to get to the stage where
>>>>> we can configure sssd to do it too. sssd is like nslcd running with
>>>>> nscd:
>>>>> sssd = nslcd + nscd?
>>>> If you're just talking about changing group membership, then yes.
>>>> But I
>>>> thought you'd also talked of changing uids of existing users.  Equally
>>>> why
>>>> would you be changing primary group membership of users on a frequent
>>>> basis?
>>>>
>>>> Either you have a cache, or you don't.  If you just disabled the cache
>>>> (as I
>>>> believe has been suggested) does it behave as you think you want?
>>>>
>>> Yes, I agree with John.
>>>
>>> There is a bit of confusion here.
>>> 1) The UID and GID of the user are not frequently changed. It is a bad
>>> practice to change them because all the files owned by user also need to
>>> be chowned. We do not have a good solution for addressing that. We have
>>> a ticket to design something in future bu so far if you change the
>>> UID/GID of the user you have to clean the caches on the systems the user
>>> has access to. This is the flip side of the caching. So think twice
>>> changing UID/GID
>>> 2) Changing home directory is fine and would propagate when the user
>>> logs next time. You can't view UID/GID and home directory as similar
>>> attributes. They have different meaning and implications.
>>> 3) Group membership is also updated when user logs in or there is a
>>> lookup for user information. Several cache parameters define how
>>> frequently that would happen. Everything is currently optimized for
>>> performance of the applications running on the client. If you want to
>>> get less latency you would have to give up some of the performance gains
>>> the caching presents.
>>>
>>>    
>> Hi
>> Thanks for the explanation. There seem to be two different caches for
>> sssd.
>> 1. the cache for the user authentication credentials
>> 2. the cache for ldap attributes (like nscd)
>>
> There are several different caches at different levels.
> Let us split the authentication and identity lookups.
> With authentication there are two types of caching:
> * your password hash can be stored in the sssd cache database so that
> you can log offline (optional)
> * your password in clear is stored in the kernel key ring when you log
> while not connected to the network so that when you get on the VPN a
> kerberos ticket can be automatically acquired (optional).
>
> With identity lookups you have several caches:
> 1) fast cache that was added in 6.4 that is equivalent of the NSCD. It
> works for users and groups and its purpose is to provide caching for the
> cases when a process does multiple lookups per second for the same ID.
> 2) normal sssd cache. It has a complex algorithm of keeping it up to
> date. For more about it see man sssd.conf and parameter
> entry_cache_nowait_percentage
>
> When user performs online authentication SSSD would try to fetch the
> latest information from the server. At least this is how earlier
> versions of SSSD worked. If you do not see this in the 1.9 that might be
> a bug. But before opening it please make sure that your client actually
> has the connectivity to the server at the moment you re-authenticate. We
> would want to see your sssd logs for the authentication attempt with
> high debug_level value to detect what is wrong and why you do not see
> the group membership coming to the client in a reasonable time.
>
> 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


>
> The group change should be propagated because the user has authenticated
> and we refetch user data on the re-authentication.
> Otherwise if you do not re-authenticate the cache would be updated but
> at much slower pace as Jakub mentioned.
> If you do not see the changes in groups then send us the sanitized sssd
> log for the default domain. Do not forget to set  debug_level to 8 or 9
> before running the test.
>
> HTH
>
>
>




More information about the sssd-devel mailing list