MFA overview

Edit online

Multi-factor authentication (MFA) extends password authentication to include an additional authentication factor used to verify your identity.

The IBM i integrated MFA solution incorporates a time-based one-time password (TOTP) key which is stored in the user profile and is architecturally protected similar to the password. The TOTP key is used, along with the system time, to generate a TOTP value. The TOTP value is presented as an additional factor when authenticating. The IBM i implementation is based on RFC 6238 -TOTP: Time-Based One-Time Password Algorithm

The IBM i implementation follows RFC 6238, so any compatible client application such as a PC application, smart phone application, smart watch application, or physical token that is standards compliant can be used to generate a TOTP value. The user profile and compatible client application must have the same TOTP key or shared secret. The client application, after it is configured with the TOTP key, generates TOTP values based on the TOTP key and the current time on the device. The user enters the TOTP value as an additional sign-on factor when authenticating to the system. The operating system validates the user ID, password and TOTP value at the same time making it a multi-factor authentication.

Enabling MFA

The IBM i operating system integrated MFA solution requires the system be at a security level (QSECURITY system value) 40 or greater and a password level (QPWDLVL system value) 4 or greater.

MFA is enabled on your system when the Additional sign-on factor security attribute is set to enabled. When the additional sign-on factor is enabled, some interfaces will show an Additional factor field on the sign-on prompt along with the User and Password fields. This does not mean users will be required to enter an additional factor. The additional factor is only required if the user’s profile is changed to require it, otherwise the additional factor will be ignored. Enabling the additional factor for a user profile requires actions from both the user and the administrator. The frequency with which a user has to enter a TOTP value is configurable.

Interfaces that do not have an additional factor field require the additional factor value be appended to the password using a colon as the separator (password:additional_factor). The system administrator must educate users on how to use the password field on interfaces that do not provide an additional factor field.

For more information, refer to Additional sign-on factor security attribute.

When a user is required to enter a TOTP value, it requires the system time and client authenticator application time to be synchronized within a few seconds of each other. The Network Time Protocol (NTP) client can be used to keep the system time in sync with other devices in the network. For more information, refer to Network Time Protocol (NTP) time synchronization.

Security administrators must consider client application password usage when enabling MFA requirements for each user. The most challenging password usage examples are:
  • Cached password
    • The client application stores a user’s password and authenticates to the server multiple times, over multiple connections, during a variable time period. The time-sensitive TOTP requirement breaks authentication for these applications. Applications that ask permission to store the password can be identified while those doing it implicitly need to be discovered through testing.
    • Applications can be redesigned to prompt for credentials on each authentication or to eliminate additional connections/authentications.
    • Security administrators can allow password caching applications to work for individual user profiles by configuring the frequency that a TOTP value is required.
  • Password circumvention
    • An application’s server implementation bypasses the need for the user profile’s password. This happens when the application profile has authority to the user profile used on an interface that allows a special value for the password. An application may perform authentication independent of the user profile and/or password (such as Kerberos). Associating a user profile with this type of authentication that didn’t require a password, conflicts with MFA requirements.
    • Security administrators can use the QIBM_RUN_UNDER_USER_NO_AUTH function ID to control if this circumvention is permitted.

Host Connection Server

The Host connection server (HCS) allows a client to establish authenticated sessions with various host servers. HCS allows a client to authenticate one time and then use that authenticated session to transfer new connections to other host servers without having to re-authenticate. A user configured to always require a TOTP value only has to provide it one time eliminating the need to prompt for credentials multiple times. IBM i Access Client Solutions (ACS), IBM Navigator for i, and Digital Certificate Manager (DCM) have changed to use HCS. For more information, refer to Host connection server.

QIBM_RUN_UNDER_USER_NO_AUTH function ID

The ability to run actions as another user profile based only on having authority to that user profile should be considered. To achieve a complete MFA solution, it is recommended that user profiles require a TOTP value and also have their access to this function ID restricted. The IBM i integrated MFA TOTP implementation permits this password circumvention due to pervasive existing use. However, the Run under a user without authentication (QIBM_RUN_UNDER_USER_NO_AUTH) function ID should be used to block applications from bypassing the need to supply the user profile credentials. Security auditing can be used to assist with determining whether actions would fail if a user is denied access to the function ID. For more information, refer to QIBM_RUN_UNDER_USER_NO_AUTH function usage ID.
Note: The QIBM_RUN_UNDER_USER_NO_AUTH function ID does not require that MFA be enabled or used on the system.

IBM-supplied user profiles

There are IBM®-supplied user profiles with names that end in _NC, for “not changeable”. These user profiles are the same as the corresponding user profiles with names that don’t end in _NC, however they cannot be changed and do not have a password. These user profiles also cannot be denied access to the QIBM_RUN_UNDER_USER_NO_AUTH function ID. They are used in places where the non _NC user profiles were previously used, such as when submitting jobs, getting profile handles, or as the user profile a server runs under. They should also be used by applications in case the non _NC user profile is denied access to the QIBM_RUN_UNDER_USER_NO_AUTH function ID.
  • QPGMR_NC
  • QSECOFR_NC
  • QSYSOPR_NC
  • QUSER_NC

Enhanced profile tokens

Enhanced security protection is available with profile tokens. When a profile token is generated, you can specify a verification ID and/or remote IP address by changing the application to specify these parameters. The matching verification ID and/or remote port must also be specified on the set request for it to be successful. This ensures the profile token is not being used by a bad actor. For more information, refer to Enhanced profile token security protection.
Note: The enhanced profile token does not require that MFA be enabled or used on the system.

Single authentication exit point QIBM_QSY_AUTH

Independent Software Vendor (ISV) security solutions often depend on IBM exit points to implement security protections in addition to what is provided by the operating system. The QIBM_QSY_AUTH exit point provides a way for an exit program to be called during authentication processing for all applications performing an applicable operation. The exit program registered in the registration facility, under the QIBM_QSY_AUTH exit point, is called when a user profile is changed to require calling the exit program. The exit program is passed information to use to perform additional verification and can return success or failure indicators. Some information passed to the exit program will be blank if the application does not provide it on calls to the authentication interfaces. A high privilege user could be required to provide a password and TOTP value, and have the exit program called. The exit program could generate an out-of-band push notification to a phone that requires a fingerprint to continue. For more information, refer to *REGFAC authentication method.
Note: The authentication exit point QIBM_QSY_AUTH does not require that MFA be enabled or used on the system.

Application developer considerations

Some system authentication interfaces with a user password parameter have a separate additional authentication factor parameter. The user experience can be improved when applications expose an additional authentication prompt to their users. This can be accomplished if the application determines the Additional sign-on factor security attribute is enabled then uses the additional authentication factor parameter on authentication interfaces. The IBM i authentication interfaces also include parameters to provide the additional information required to be passed to the QIBM_QSY_AUTH exit program or to create an enhanced profile token. The QIBM_QSY_AUTH exit program can analyze more information when applications consistently provide the additional information on applicable interface calls. However, the IBM i integrated MFA solution is functional without application changes to use these parameters. For more information on the interfaces with the relevant parameters, refer to *REGFAC authentication method and Enhanced profile token security protection.

Service Tools support

System service tools (SST) and dedicated service tools (DST) support a separate MFA TOTP key implementation not connected to the operating system MFA support. The TOTP keys set for SST users have no relationship to the TOTP keys set for IBM i user profiles, specifically an SST user with a linked profile does not share a TOTP key with the linked profile. Another difference is that SST does not allow setting a frequency for providing the TOTP value, it is required every time a password is required. An SST administrator can enable MFA for SST without enabling it on the operating system. For more information, refer to Service tools Multi-factor authentication (MFA).