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-3393: crontab works for local account but not AD users

Authentication Service ,  

28 April,17 at 04:17 PM

Applies to: All versions of Centrify DirectControl on RHEL platform
 
Question:
AD users are unable to issue crontab commands. Local users can run these commands fine.
 
The /etc/pam.d/crond and /etc/pam.d/system-auth files are correct. DirectAuthorize is configured correctly and was even disabled temporarily with no effect. cron.allow and cron.deny files are configured correctly.
 
Is there any reason why?
 
Snippets of Centrify debug logs show the following:
Authentication failure 
 
You (joeuser) are not allowed to access to (crontab) because of pam configuration.
 
Aug  7 10:23:05 fileserver.domain.com adclient[30359]: DEBUG <fd:16 crontab(25399)> client.crontab <- pam_sm_acct_mgmt, result=PAM_AUTH_ERR(7)
Aug  7 10:23:05 fileserver.domain.com adclient[30359]: DEBUG <fd:16 crontab(25399)> client.crontab <- pam_sm_acct_mgmt, result=PAM_AUTH_ERR(7)
 
Answer:
Based on the debug log extract above, one can infer the following:
/etc/pam.d/crond:
#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_env.so
auth       required   pam_rootok.so
auth       include    system-auth
account    required   pam_access.so
account    include    system-auth
session    required   pam_loginuid.so
session    include    system-auth
 
Purpose of sufficient module:
 
If the service module returns a "success" and no other preceding "required" modules return failures, it will immediately return success without calling any subsequent modules. 
If a failure is returned, it will treat the failure as an optional module failure, and will continue to process the PAM stack.
 
Effectively, the pam stack looks like this
 
account    required       pam_access.so
account    sufficient     pam_centrifydc.so
account    requisite      pam_centrifydc.so deny
 
From the log, deny is set so the third layer is called and an error is returned. That is a "requisite" flag, so the failure is returned. 
The second one is called and success is returned by pam_centrifydc.so and it should have been sufficient. 
But the first one is a "required" module, if that failed, the "sufficient" will not return success but will use the failure code from the "required" call.
 
Effectively this means pam_access.so failed the call. pam_access is controlled by RedHat's /etc/security/access.conf (Note: This is not a Centrify configuration file).
 
For more information, please contact the vendor or check the below man pages:
http://linux.die.net/man/5/access.conf (Link provided as a courtesy)
 
The local account worked fine as it was a member of the administrators group (wheel) which has access to "ALL" in access.conf.
 
This issue was fixed by using an AD group to control cron access, by removing cron.allow, creating an empty cron.deny, and then adding the line below in /etc/security/access.conf of a Centrify RHEL server:
 
+: group cronusers:cron (where cronusers is an AD group)
 
Centrify agent and cron daemon can be restarted (optionally) for changes to go into effect.
 
 

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

Related Articles

 articleKB-3925: How to add Centrify parameter to a group policy articleKB-7555: Unable to login as root after upgrade to Centrify Suite 2016 (CDC 5.3.0) articleKB-2735: How does Account Migration work on Mac OS X? articleKB-3008: AD accounts that previously worked with the built-in Apple AD plugin don't work when bound via Centrify articleKB-6040: How to change the license type in use after adclient successful joined to the AD? articleKB-1942: How to map local user accounts to AD accounts? articleKB-6041: How to show current license type in use by adclient articleKB-6038: How to specify the license type to use when joining the server to AD using adjoin? articleKB-6056: How to report the group policy settings that are in effect for the local computer?