Centrify

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  >
article

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.

Question:

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

Answer:

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)
 
PROS
 
For NSS lookup ONLY, bypasses call to Centrify for local accounts

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

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

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

 articleKB-4803: What is the impact of placing files before centrifyda in /etc/nsswitch.conf articleKB-2835: DirectAudit 3.x and /etc/nsswitch.conf articleKB-1748: What are the list of system files changed by Centrify unix/linux agent installation? articleKB-4291: What files are modified by Centrify DirectControl or DirectAudit during install & adjoin process articleKB-8942: What are the steps to migrate a RHEL Brightstore cluster to Centrify articleKB-4057: adcheck reports incorrectly that dns is needed in nsswitch.conf in Fedora Core 20 articleKB-3925: How to add Centrify parameter to a group policy articleKB-5371: Account username and uid is not mapping articleKB-0616: Mapping home directories for AD users in Linux using automount and the Centrify adauto.pl script