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-4235: local account unable to login if dad is down

Centrify DirectAudit ,  

12 April,16 at 11:41 AM

Applies to:
 
Centrify DirectAudit 3.1.2 and 3.2.x
 
Question:
 
A local user is unable to login to an audited server even though the below parameter is set to true. 
There was a segfault which resulted in the unavailability of dad daemon. 
 
Is there any reason for this?
 
[root@localhost]# cat centrifyda.conf | grep -i without
dash.cont.without.dad: true
 
Answer:
 
DirectAudit has an NSS module that modifies pw_shell for all  getpwxxx() calls to return /bin/centrifyda as the login shell if the DirectAudit daemon (dad) is running ; or return the user’s login shell when dad is not running.  
 
This results in login/sshd executing /bin/centrifyda (also known as cdash) so that it can determine the user login session is audited or not.

It communicates with the DirectAudit daemon (dad) to determine if the user session should be audited or not.  

If the user session is audited, it acts as a filter for all terminal I/O and audit the user session.  Otherwise, it will just invoke the user’s login shell and exit. 
 
Also, note that Unix nscd caches results for all getpwxxx() calls so that /bin/centrifyda may be returned even if the DirectAudit daemon (dad) is running.
 
 /bin/centrifyda needs to communicate with the DirectAudit daemon to send audit data.    The design objective is that if the DirectAudit daemon is stopped for whatever reason, it should only disallow any “audit required” user to login (or continue with their session); and allow the other users to continue.  

It also uses the local configuration parameter in /etc/centrifyda/centrifyda.conf the parameter  "dash.user.alwaysallowed", to allow for local override in case something really goes wrong (e.g., the audit level cannot be determined for whatever reason).    
 
However, there is a known issue in /bin/centrifyda that this is not checked correctly in one instance. 
 
This happens when /bin/centrifyda first tries to contact DirectAudit daemon and it continues only if the user is in the "dash.user.alwaysallowed" list.  So an “audit if possible” user can be blocked from login if DirectAudit daemon crashed and one of the following conditions exist:
 
1) The user was authenticated while DirectAudit daemon is still running;  
 
2) The user’s profile information (usually because of previous login) is still valid in nscd cache.
 
These two conditions are very hard to control or predict. 
 
To avoid potential issues, Centrify recommends implementing the suggested workaround by using the "dash.user.alwaysallowed" configuration parameter in /etc/centrifyda/centrifyda.conf.  

When modifying centrifyda.conf, run 'adreload' to take the effect on the latest configuration changes.
 
Note: the above parameter is undocumented and is available only with DirectAudit 3.1.2 which is available in Centrify Suite 2014.

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