Integrated MFA in IBM i 7.6: benefits, risks, setup

Reviewed on

Log in to save

IBM i 7.6 includes multi-factor authentication in the operating system. At sign-on an enabled profile supplies, alongside the password, a time-based code generated by an authenticator application following the TOTP standard.

Enablement is per profile, not per system: the function is switched on globally but has no effect until it is required on a specific profile.

The three operations of activation. The security attribute and user enrolment have no effect on sign-on; only the per-profile requirement changes it.

What it adds

A compromised password is no longer sufficient. That is the purpose of the function, and it moves the point of attack from a value that can be stolen, guessed or reused across systems to a device the user carries.

It covers non-interactive access too. For a profile with *TOTP the code is required on every password authentication, not only in 5250. Interfaces without a dedicated field take it appended to the password, as password:code, as IBM's documentation says. This is the difference from menu security, which constrains interactive access and leaves untouched the interfaces reaching the database directly, the same ones examined in who controls network access.

It introduces no third-party product. No additional licence, no component to keep aligned with operating system releases and, above all, no new access path into the system to have approved. For an installation subject to periodic audits, that last point weighs as much as the cost.

It can be introduced gradually. The requirement is set one profile at a time, so the rollout can proceed by homogeneous groups rather than in a single window.

What it entails

A prerequisite that for some is a project in itself. QPWDLVL must be 4, which changes the format in which passwords are stored. From 2 or 3 it is a system value change with an IPL; from 0 or 1 it first requires cataloguing the clients authenticating with earlier protocols and having every active profile change its password. The subject is covered in QPWDLVL 4, the prerequisite that makes MFA a project.

An IPL for activation. Moving the security attribute from *DISABLED to *ENABLED is not immediate: it has to be planned within an outage window.

Applications that cannot cope with a time-based code. IBM names two families. Those that store the password and authenticate several times, over several connections, over time: the code expires and authentication breaks. For these the profile can be given an interval (TOTPOPTITV, 1 to 720 minutes) during which authentications after the first do not ask for the code. And those that bypass the profile's password: they are governed with the QIBM_RUN_UNDER_USER_NO_AUTH function. They have to be found before setting the requirement; those that cannot supply a code stay on *NONE with protection built otherwise: authorities, exit points, source addresses.

Losing the device locks the profile. IBM says the key is set by the user, not by the administrator: whoever loses the phone cannot regenerate it without signing on, and cannot sign on without the code. What remains is for an administrator to set the profile back to AUTHMTH(*NONE), for the user to generate a new key, and for the requirement to go back on. Who may do this has to be decided beforehand, and for the duration of the rollout it is worth keeping one administrative profile without MFA.

It requires IBM i 7.6, therefore Power10 or Power11: on Power9 the function is out of reach. Compatibility between generation and release is in which Power you need for which IBM i.

Prerequisites

QSECURITY at 40 or 50 and QPWDLVL at 4.

DSPSYSVAL SYSVAL(QSECURITY)
DSPSYSVAL SYSVAL(QPWDLVL)

Enabling the security attribute

CHGSECA ADLSGNFAC(*ENABLED)

If the Service Tools policy prevents the change, the command fails and the constraint has to be removed first:

CHGSSTSECA CHGADLSGN(*YES)

after which CHGSECA is run again. Moving from *DISABLED to *ENABLED requires an IPL.

Once the IPL is complete the system behaves as before for every profile: the attribute makes the function available, not mandatory.

User enrolment

The user generates their own key and registers it in the authenticator application. The intended path is Navigator for i: My Work → My Additional Authentication Factor → Manage My MFA Key, scanning the QR code. From the command line CHGTOTPKEY is available.

A user without *ALLOBJ signing into Navigator is taken directly to the key generation display, the only function they are authorized to in the default configuration: there is no need to widen their authorities in order to let them enrol.

The operation has no effect on sign-on: the key exists, but is not yet requested.

The per-profile requirement

CHGUSRPRF USRPRF(MROSSI) AUTHMTH(*TOTP)

From this point the profile must supply the time-based code in addition to the password.

Enrolment precedes the requirement, for every profile: IBM says that to set *TOTP the user must already have a key, and only the user can set it. Who has one shows in DSPAUTUSR or, in Navigator, Security → MFA Configuration → Users.

Example: rollout on a first profile

Prerequisites verified and IPL performed.

CHGSECA ADLSGNFAC(*ENABLED)

The user signs into Navigator for i, opens My Additional Authentication Factor, generates the key and registers it in the application. At this point they stop and verify an ordinary sign-on: it must work as before, since the requirement is not yet active. An anomaly at this stage is correctable without consequences for access.

Only afterwards:

CHGUSRPRF USRPRF(MROSSI) AUTHMTH(*TOTP)

At the next sign-on the display presents the Additional Signon Factor field, where the time-based code is entered.

A cycle on a single profile provides what is needed to size the rollout: enrolment time per user, support required, and the behaviour of the client applications in use.

Which versions this works on

Integrated MFA is a feature of IBM i 7.6. On 7.5 and earlier releases it is not available and requires third-party products.

QSECURITY and QPWDLVL exist on all releases: the prerequisite check can be carried out on any system, regardless of upgrade plans, and it is the way to know in advance whether adoption will be a value change or a project.

Sources

← Back to blog

Comments

No comments yet. Be the first to comment!

You need an account to comment. Log in · Sign up