Reference Content — Authentication

You can specify what authentication mechanisms your users need to provide to access the service, as well as if and when multifactor authentication is required. For example, you can create a rule to require that users provide a password and text message confirmation code if they are coming from an IP address that is outside of your corporate IP range. To specify this requirement, you need to create a rule and associate it with an authentication profile.

This section contains the following topics:

Authentication Mechanisms

You can select the authentication mechanisms that will be available to users. However, the mechanisms ultimately offered to users on the login prompt depend on the account’s properties. For example, if you select all of the mechanisms but a user account has only a user name and email address, then the login prompt will only offer those two options.

To set the authentication mechanisms, see Creating Authentication Profiles.

The following mechanisms are available:

  • Password

    When you select this option, users are prompted for either their Active Directory or Privileged Access Service user password when logging in to the Admin portal.

  • Mobile Authenticator

    When you select this option, users authenticate using a one-time passcode displayed by the IBM Security application installed on their mobile devices.

    If devices are connected via the cell network or a wi-fi connection, users can send the passcodes from the devices. If the devices are not connected, users must manually enter the passcodes into the Admin Portal login prompt.

    This option requires users to have IBM Security application installed on their devices and those devices must be registered in Privileged Access Service.

  • Phone call

    When you select this option, Privileged Access Service calls the user using the stored phone number (mobile or land line) and describes an action theuser must perform to complete the authentication. The user completes theaction from the device to log in. If your tenant is configured on PrivilegedAccess Service 17.10 or newer, see Enabling Phone PIN because additional configuration is required.

    This option is disabled for new tenants by default. Contact IBM Security Support to enable this authentication mechanism.

  • Text message (SMS) confirmation code

    When you select this option, Privileged Access Service sends a text message to the user’s mobile phone with a one-time confirmation code and/or anauthentication link. Depending on the language setting, some languagesdisplay only the confirmation code while others display the confirmationcode and link. Users who are connected to the Internet can click/tap thelink. Otherwise, they need to enter the confirmation code in the login prompt.

    You can configure the confirmation code length (6 or 8 digits) in Admin Portal > Settings > Authentication > Security Settings > Email and SMS passcode length drop down option. The default is 8 digits.

    The link and confirmation code are valid for 20 minutes. If a user does not respond within this time period, the Privileged Access Service cancels the login attempt.

    This option is disabled for new tenants by default. Contact IBM Security Support to enable this authentication mechanism.

  • Email confirmation code

    When you select this option, Privileged Access Service sends a confirmation code and a link to the user’s email address. Users who are connected to the Internet can click/tap the link. Otherwise, they need to enter the confirmation code in the login prompt.

    You can configure the confirmation code length (6 or 8 digits) in Admin Portal > Settings > Authentication > Security Settings > Email and SMS passcode length drop down option. The default is 8 digits.

    The link and confirmation code are valid for 20 minutes. If a user does not respond within this time period, the Privileged Access Service cancels the login attempt.

  • FIDO2 Authenticator(s)

    FIDO2 is an authentication standard hosted by FIDO Alliance. This standard includes the Web Authentication ("WebAuthn") API, which is a specification written by the World Wide Web Consortium (W3C) and FIDO, with participation from additional third parties. The WebAuthn API is backward compatible with Universal 2nd Factor (U2F) keys.

    IBM Security leverages the WebAuthn API to enable password less authentication to the Privileged Access Service using either on-device or external authenticators. On-device authenticators are biometric authenticators integrated into the device hardware. Popular examples are Mac Touch ID, Windows Hello, and fingerprint scanners. External authenticators are security keys that you plug into the device's USB port; for example, a YubiKey.

  • Security Question(s)

    When you select this option, users are prompted to answer user-defined and/or admin-defined security questions. When creating the authentication profile, you can specify the number of questions users must answer. You can also specify the number of user-defined and admin-defined questions available to users. See Enabling Multiple Security Questions.Users create, select, or change the question and answer from their Account page in the Admin Portal.

  • OATH OTP Client

    This text string is configurable and reflects what you entered during the OATH OTP configuration. When you select this option, users can use a third party authenticator (like Google Authenticator) to scan a Privileged Access Service generated QR code and get a one-time-passcode (OTP). This authentication mechanism requires additional configurations. How to Configure OATH OTP.

  • 3rd Party RADIUS Authentication

    When you select this option, we communicate with your RADIUS server to allow for user authentication into Privileged Access Service.

What You Need for Each Authentication Mechanism

The following table lists the authentication mechanism and the associated Active Directory, LDAP, and IBM Security Directory account properties that must be set correctly. If a property is not set correctly, the user may not be able to log in.

Authentication mechanism Required user account property Active Directory/LDAP Properties tab IBM Security Directory Profile property
Password Login Name and Suffix User logon name on the Account tab NA
Mobile Authenticator Registered device Not applicable Not applicable
Phone call Mobile phone number Open the Telephones tab and set the Mobile field Set the Mobile Number field
Text message (SMS) confirmation code Mobile phone number Open the Telephones tab and set the Mobile field Set the Mobile Number field
Email confirmation code Any valid email address Open the General tab and set the E-mail field Set the Email address field
Security question(s) NA NA NA
OATH OTP client NA NA NA

Before you enable a specific authentication factor, confirm that each account has current contact information or a currently registered—and make account changes a day before you enable the authentication policy for the accounts. If the information needed for a user’s authentication is not current in Privileged Access Service, the user will not be able to log in.

If you need to modify a user’s Active Directory or LDAP account, any changes you make are not immediately updated in Privileged Access Service. For example, it can take up to 24 hours for changes made in Active Directory Users and Computers to be incorporated into the Privileged Access Service.

By contrast, updates made to IBM Security Directory accounts go into effect immediately.

Users can set their Active Directory or LDAP account’s mobile phone number from the profile tab. When users change their Active Directory or LDAP account’s mobile phone number using the Admin Portal, the change goes into effect immediately.

Temporarily Suspend Multifactor Authentication

If the user’s account information required for multifactor authentication is not set properly and it prevents the user from logging in, you can use the MFA Unlock command in Admin Portal to suspend multifactor authentication for 10 minutes—see User Management Commands. The user must still enter the correct user name and password and is still prompted to enter the additional authentication factor, however, the Privileged Access Service does not validate anything beyond the user name and password. Consequently, the user can, for example, enter any string of characters to fulfill the SMS confirmation code, and the Privileged Access Service accepts the entry.

To temporarily suspend multifactor authentication for a user:

  1. Log in to Admin Portal.

  2. Click Access > Users.

  3. Right-click the account for the user who is locked out.

  4. Select MFA Unlock

    The user has 10 minutes to log in.

Browser Cookies Associated with Authentication Policy Controls

When you enable authentication policy controls, Privileged Access Service leaves the following identity cookies in your users’ browsers:

  • After multifactor authentication: The Privileged Access Service leaves a cookie in the current browser after the user has successfully logged in to Admin Portal by using a multifactor authentication method.

    When the directory service finds this cookie, it does not prompt the user to provide an additional authentication method for subsequent logins. If you want to require authentication for subsequent logins, then ensure that you do NOT have an authentication rule using the Identity Cookie filter and specify the Default Profile for one that has the necessary authentication methods. See Creating Authentication Rules for instructions on creating authentication controls.

  • After IWA Authentication: The Privileged Access Service leaves a cookie in the current browser when the user has successfully logged in to the Admin Portal using Integrated Windows Authentication.

    When the Privileged Access Service finds this cookie, it ignores the multifactor authentication requirements and lets a user open a web application from the Admin Portal that is set with the “Restrict app to clients within the Corporate IP range” policy regardless of their IP address (see Removing an application).

Users are required to provide multifactor authentication if the cookies are deleted or they use a different browser to log in.