Options applied to the Centrify PAM module

The authentication service applies some options to the Centrify PAM module pam_centrifydc module. For example, in a RHEL system, you would see the following in the /etc/pam.d/system-auth file:

auth sufficient pam_centrifydc.so

auth requisite pam_centrifydc.so deny

account sufficient pam_centrifydc.so

account requisite pam_centrifydc.so deny

session required pam_centrifydc.so homedir

password sufficient pam_centrifydc.so try_first_pass

password requisite pam_centrifydc.so deny

In addition, you could see the following in the /etc/pam.d/su file:

auth sufficient pam_centrifydc.so enable_dzpamgate

For each management group, a set or stack of modules can be defined and used in turn. When an application calls the PAM library function (for example to authenticate), the PAM runtime will call each authentication function in each module— one at a time like cards from a stack. The order of calling is determined by the order in the configuration (service) file.

Be careful when changing the order in the stack; changing the order might have impact on the functionality considerably.

There are four types of PAM services:

  • Authentication service modules

  • Account management modules

  • Session management modules

  • Password management modules

There are four control flags:

  • Requisite: The requisite flag is probably the strongest of the flags. If a module is flagged as requisite, and it fails (returns not-OK), PAM will return to the calling application instantly and report the failure.

  • Required: The return code for a required module is stored. In the case of failure, execution is not stopped but continues to the next module. When the stack of modules has been executed, and at least one required module has failed, PAM will return failure to the calling application. Moreover, the failure is associated with the first failing module) The required control flag is useful in keeping unauthorized persons out of your computer, particularly since the other modules in the stack are applied as well.

  • Sufficient: A sufficient module can actually be quite strong. The processing of the stack is stopped if a sufficient module returns OK, if no previous required module has failed. If there are required modules after the sufficient modules, these modules are not called.

  • Optional: When a module is flagged as optional, a failure does not alter the execution of the stack as in the case of the requisite flag. Moreover, the return code is ignored, and neither failure nor success is taken into account.

The list of options that are applied to pam_centrifydc are as follows:

  • Deny: When it gets to this line, it will just deny the request

  • Try_first_pass, use_first_pass, get_first_pass: All three follow PAM standards.

  • Try_first_pass: Use the password from the previous stacked authentication module, and prompt for a new password if the retrieved password is blank or incorrect.

  • Use_first_pass: The default is to use the old password saved by a previous module, or if none, to ask for it. With use_first_pass it fails if there is no old password.

  • Requisite: This is an HP platform only option. The effect is the same as HP "pam requisite"

  • Unix_cred: This is Solaris only option to provide Solaris's pam_unix_cred

  • Homedir: Create user home directory

  • Enable_dzpamgate: This is a Centrify option to seal a potential pam security hole. In some systems, pam account module does not always gets called so the authorization checking in auth module is inserted with the enable_dzpamdate option.

In /etc/centrifydc/centrifydc.conf, the parameter equivalents are provided as:

pam_mkhomedir.so [umask=mode] [skel=skeldir]

pam.homedir.perms: 0700

pam.homeskel.dir: /etc/skel

To update the parameters, remove the # sign and change values as desired.