Requiring multi-factor authentication for PAM applications

If you select the “Multi-factor authentication required” system right in a role definition, the PAM applications you add to the role will require users to select a secondary form of authentication to log on successfully. You define the forms of authentication available and presented to the user in the authentication profile you have configured using the administrative portal for the Centrify Platform. For example, you might configure an authentication profile that require users to answer a phone call, click a link in an email message, or respond to a text message.

Note that some applications do not support multi-factor authentication and users might be denied access to applications that they would otherwise be able to use. For example, if a specific version of an application that you want to use only supports a single layer of authentication—such as a password challenge—users would be prevented from logging on and using the service even if they are assigned to a role with the predefined login-all PAM application right.

If you want to grant access to applications that only support one layer of authentication in roles where you are generally using the “Multi-factor authentication required” system right, you must add those applications to the list of applications for which you want to skip multifactor authentication. You can update the list of applications for which to skip multifactor authentication by enabling and modifying the “Specify programs for which multi-factor authentication is ignored” group policy or setting the pam.mfa.program.ignore configuration parameter in the centrifydc.conf file.

Before assigning roles with multi-factor authentication required to users, you should test access to all of the applications you expect users to access to verify they won’t be unexpectedly denied access simply because multi-factor authentication isn’t supported. Because the applications that don’t support multi-factor authentication will depend on the platforms and the versions of the applications you plan to support, testing in your own environment is the only way to determine which applications to add to the pam.mfa.program.ignore configuration parameter.

The most common applications that are known to only support a single password challenge and response for authentication are ignored for multi-factor authentication by default. For example, some versions of java and vsftpd do not support multi-factor authentication and are ignored by default.

Additionally, while some platforms support multi-factor authentication for all PAM applications, they may not allow you to require multi-factor authentication for GUI log in. For example, for users running AIX, Solaris, and HP-UX, multi-factor authentication for GUI login is not supported.

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. Whenthe stack of modules has been executed, and at least one required module hasfailed, PAM will return failure to the calling application. Moreover, thefailure is associated with the first failing module) The required controlflag 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 noprevious 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 theauthorization 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.