Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-2119: The impact of winbindd on Centrify Enabled Samba

12 April,16 at 11:08 AM

Applies to: All versions of Centrify-Enabled Samba


When running winbindd (by default it is running when Centrify-Enabled Samba starts up), access to Samba shared files is denied to users belonging to but not specified in the Unix group. 

Is this expected?



With Active Directory, a user is a member of all the groups it belongs to, EXCEPT the primary group. By stopping winbindd, Samba now relies on NSS to resolve group memberships where CentrifyDC is involved. Given adclient.get.primarygroup.membership=true, adclient will now add the users to the primary group's member list. So Samba will see the user in the "valid users" group.

1. Impact of stopping winbindd.

Very little, if any. Here is a description of winbindd from Samba:

"winbindd is a daemon that provides a number of services to the Name Service Switch capability found in most modern C libraries, to arbitrary applications via PAM and ntlm_auth and to Samba itself."

Since CentrifyDC has taken over NSS and PAM, the need for winbindd has been obviated. 

In short; with CentrifyDC in place and machine joined, winbindd is not really needed. 

2. Impact of specifying adclient.get.primarygroup.membership=true

This means, for a given group - adclient will now have to lookup all users that have this group as primary group and add them to the member list as opposed to just returning with what AD returns. 

Impact depends on how many users found in this case. In general, it is not significant as in most cases the lookup can be done in a single search request, but if the answer produced is too big for one exchange, then it will take longer. 

Note also that mostly adclient will answer from its own cache. It only has to do this on cache miss or data refresh.

3. When adding user to the group, or deleting, how long will it take to show?

This depends on the cache object expiration interval and type of change. 

Cached object expiration is governed by adclient. The cache expiry default in /etc/centrifydc/centrifydc.conf is 3600, when an object expires, adclient will check if the object has changed from last time (e.g. user changed). If so, it will refresh it, otherwise it will just report from cache. 

On the AD side, adding user to a group is a change to the group. However, creating a new user whose primary group is this group does not update the group (as is deleting the user object). Changing user primary group from A to B, however is a change to both A (add user to member list) and B (removing user from member list). 

For example, user Joe belongs to group A, B and C, with A being the primary group. adclient will notice that B and C are changed, but not A. Changing primary group from A to B, will trigger the change to both A and B. 

3a. There is a parameter in centrifydc.conf that tells adclient to get rid of ancient objects: 

adclient.cache.object.lifetime: 0

Default is 0, meaning: Never

Centrify suggests setting this to 1 (hour) so that an object that is one hour old will be removed. 

So now the group requests for a group that is an hour old is likely to get a cache miss. 

The group then will have to be rebuilt to pick up any unseen changes. 

4. The Centrify distribution of Samba is basically standard Samba distribution with configuration change (and adbindd) so it can co-exist with CentrifyDC. 

Default distribution always starts smbd, nmbd, winbindd and adbindd (Centrify). 

The user can modify /etc/init.d/centrifydc-samba to customize it.