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-4667: Why "getent passwd <user>" returns /bin/centrifyda shell, not logon shell

Auditing and Monitoring Service ,  

12 April,16 at 11:47 AM

Applies to:
 
Centrify DirectAudit 3.x
 
Problem:
 
On a Centrify audit server, the command "getent passwd username" returns shell as /bin/centrifyda & it returns /bin/bash when doing "getent passwd"
 
Is there an option in Centrify which can be used so that getent passwd user returns default shell rather than /bin/centrifyda without impacting business scripts which rely upon the same?
 
Package:

[root@localhost ~]# rpm -qa | grep -i centrify
CentrifyDC-5.1.2-378
CentrifyDA-3.1.1-121
 
[root@localhost~]# getent passwd p2181976
p2181976:x:2762:1014:Joe user :/home/p2181976:/bin/centrifyda
 
[root@localhost ~]# getent passwd | grep p2181976
p2181976:x:2762:1014:Joe user:/home/p2181976:/bin/bash
 
Cause:
 
Unfortunately this is by design.
 
This is how DirectAudit intercept through inserting itself in nsswitch.conf and replace the real shell with cdash or centrifyda in order to capture user activity.
 
There is no way we can distinguish and supply different answers for getpwnam queries for different caller.
 
The difference for getent passwd and getent passwd <user> is they use different nss function call:
 
getent passwd is actually using getpwent()
 
getent passwd <user> is using getpwnam()
 
DirectAudit intercept getpwnam() call but not getpwent() call
 
Workaround:
 
Attached to the KB is a sample shell script which can be deployed on a test system.
 
1. Customer should verify:
 
a. 'which getent' shows /usr/bin/getent

b. There is no file named /usr/local/bin/getent
 
2. If 'which getent' does not show /usr/bin/getent, edit the script to use the correct path for getent.
 
3. If there is no file named /usr/local/bin/getent, copy the script to /usr/local/bin/getent.  
 
4. Make sure that the file is owned by root and world executable.   
 
5. If there is another file named /usr/local/bin/getent, find a directory that getent does not exist and is in  the user's path ahead of /usr/bin
 
This getent script just executes 'getent passwd |  grep user' if 'getent passwd user' is called; otherwise it calls the original getent with all the arguments.
 
(or)
 
Customer can switch to command-line auditing.
 
Resolution:
 
None
Attachments:
sample script for getent.zip

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

Related Articles

 articleKB-7555: Unable to login as root after upgrade to Centrify Suite 2016 (CDC 5.3.0) articleKB-1861: SSH fails/Access denied if the shell /bin/bash does not exist articleKB-5940: Placed into emergency shell when logging in articleKB-2981: Deployment Manager returns with an operation timeout if login contains an interactive prompt articleKB-6041: How to show current license type in use by adclient articleKB-6040: How to change the license type in use after adclient successful joined to the AD? articleKB-6056: How to report the group policy settings that are in effect for the local computer? articleKB-2064: Understanding the AD user log-on process articleKB-6038: How to specify the license type to use when joining the server to AD using adjoin?