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.