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.
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. MFA operates at the authentication points, so it includes FTP, ODBC, Telnet and access to IFS shares, not 5250 alone. 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.
An IPL for activation. Moving the security attribute from *DISABLED to *ENABLED is not immediate: it has to be planned within an outage window.
Profiles that cannot use it. A profile used by a scheduled process or an application integration has no operator able to supply the code at the moment of execution. These profiles have to be identified before proceeding, and for them protection has to be built otherwise: restricting authorities, controlling exit points, limiting source addresses.
Loss of the device leaves the profile unusable until the key is regenerated. The regeneration procedure and the people authorized to perform it therefore have to be defined in advance, together with keeping one administrative profile not subject to MFA for the duration of the rollout.
It requires IBM i 7.6, therefore Power10 or Power11: on Power9 the function is out of reach.
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. The two operations are independent and the requirement can be set on a profile with no key: the reverse order does not produce an error, it produces a profile that cannot sign on.
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.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up