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-1274: Why is centrifyda/centrifydc before files in nsswitch.conf?

Auditing and Monitoring Service ,   Authentication Service ,   Mac & PC Management Service ,  

12 April,16 at 10:57 AM

Applies to:  All versions of Centrify DirectControl/DirectAudit running on all UNIX platforms.


Why is centrifyda, centrifydc before files in /etc/nsswitch.conf?


Centrify recommends nsswitch.conf to read: centrifyda, centrifydc, files.
This configuration assures that local users who you would like audited will be properly audited, that network accounts are serviced first for a faster end
user experience and that a local account is not created to override a network account.
Here are the Pros and Cons for changing the order of nsswitch.conf:
Changing the order of nsswitch.conf (files then centrifyda then centrifydc)
For NSS lookup ONLY, bypasses call to Centrify for local accounts

Only one file to manage, /etc/nsswitch.conf

1) Due to the way nscd works, making this change won't really buy you anything since nscd caches data locally anyways.  
Meaning the order doesn’t matter since nscd is caching users from all modules anyways (assuming nscd is turn on)
2) Customer would take the ownership of modifying the /etc/nsswitch.conf and setting Centrify’s autoedit feature to false
Leaving the domain via adleave will NOT revert nsswitch.conf back to its original state leaving that exercise to the end user
3) Customer would have to assure that AD accounts are not in the /etc/passwd file.  If the account does exist locally and in AD,
the users identity information (UID/GID, etc.) will come from the local system and not AD which could cause an unintended security breach. 
4) Changing the order DOES NOT affect PAM, therefore since Centrify is first in the PAM stack, users will authenticate to AD first while their UNIX identity information will be resolved by the secondary or tertiary module (or nscd if already cached)

5) Centrify does NOT test this configuration internally and therefore unexpected issues may come up