The IBM i Security enhancement in IBM i 7.6 that should draw your attention the most, is the enablement of MFA. Why is this so significant?
First, MFA provides a very important additional layer of security (more on this in a minute.) But it’s important because only IBM development has access to all of the interfaces that require authentication (that is, the interfaces that require you prove that you are who you say you are.) While business partners (including Kisco Systems) have provided MFA solutions, none of us could provide a complete solution because we didn’t have access to all of the interfaces until IBM provided access. This article is going to explore how one configures MFA on IBM i as well as why you’ll still want to consider using Kisco Systems’ MFA solution and how it will work once you upgrade to IBM i 7.6.
Before we get into implementation details, let’s re-visit the security benefits Multi-Factor Authentication (MFA) provides. Quite simply put, MFA prevents many attacks. Bad actors use a variety of ways to try to exploit stolen passwords. For example, they can purchase lists of known passwords and then attempt to access an organization via password spraying attempts. Phishing campaigns often try to get users to give over their passwords (which is shockingly successful). Or they convince Help Desks to enable and reset user profiles and passwords including profiles of individuals that have left the organization. In all cases, had MFA been enabled for the profile, the exploit would not have been successful. Finally, various laws and regulations (including PCI DSS) require MFA enablement. And, of course, MFA enablement is listed as a best practice in a variety of standards including the NIST Cybersecurity Framework and ISO27001.
No additional software has to be purchased to implement IBM’s version of MFA – it comes with the operating system; however, there are required settings for two system values that must be in place for you to be able to implement MFA: QSECURITY must be either 40 or 50. This shouldn’t cause issues for most organizations as the majority of systems are at one of these levels. Unfortunately, there are still systems running at level 20 or 30. That must be addressed prior to implementing MFA. The more likely setting that may cause work is the requirement to run at QPWDLVL (password level) 4. If the system is running QPWDLVL 2 or 3 and have had no issues, you should simply be able to change the system value to 4 and IPL. However, running at QPWDLVL 0 or 1 will require a project – or at least investigation and planning – prior to getting your system to QPWDLVL 4.
Once the system value requirements are met, the next step is to enable the system to perform MFA. This requires that you change the ‘Additional sign-on factor’ security attribute to *ENABLED. You can do this by running the following:
CHGSECA ADLSGNFAC(*ENABLED)
Or if using Navigator for i, go to Security -> MFA Configuration, open the Security Configuration Information, scroll down to Additional Signon Factor, right click and choose Change. Use the drop-down on the next display to change the value to Enabled and click Save. (I appreciate how Navigator for i conveniently provides all of the items Administrators need to configure for MFA all from this one window.)
Changes to this security attribute take effect after the next IPL. After the IPL, signon displays will now have an Additional Signon Factor field. In other words, signon displays will provide a new field where an MFA factor such as a one-time password, can be entered. Here are some examples:
Notes:
Lest you think that, once you IPL, all users will be required to enter an Additional Factor, rest easy. While the system is enabled for MFA, no profiles will have to enter an additional factor until they’re enrolled in IBM i MFA and the profiles are changed to require MFA.
The process of enrolling a user is a two-step process. If a user has enrolled in MFA somewhere else in your organization, the process of enrolling in IBM i MFA will look very similar. The user will need to have some authenticator app on their phone, such as Okta, Microsoft Authenticator, Duo, etc. User enrollment on IBM i is performed via Navigator for i. (Yes, a user can theoretically enroll via the green screen command Change TOTP key (CHGTOTPKEY) but this is a horrifically unusable interface.) If you are an administrator and have access to Navigator for i, go to My Work -> My Additional Authentication Factor -> Manage My MFA Key to enroll. By default, users without *ALLOBJ don’t have access to Navigator for i. In this case, when the user signs into Navigator, they’ll go directly to the Generate and save an MFA key display. (By default, this is the ONLY Navigator for i function non-*ALLOBJ users are authorized to.) All users will click Next and will see the following:
Scan the QR code with the phone’s authenticator app to complete the enrollment. You’ll be required to verify that the enrollment is complete by entering your password and the MFA code that’s returned from the authenticator app.
This completes step 1 of 2. Even though the user has enrolled in IBM i MFA, the system won’t require it until an administrator configures the user’s profile. In other words, they can still log in using only their user id and password.
To complete step 2 of the IBM i MFA configuration, change the profile to require MFA by running CHGUSRPRF USRPRF(profile_name) AUTHMTH(*TOTP) or via Navigator for i -> Users or the User section on the MFA Configuration page, right click on the profile name and select Enable Users for MFA Authentication. The user will now be required to use MFA to log onto the system.
Another parameter to consider when configuring the profile to require MFA is the TOTP optional interval. By default, the user will be required to use MFA every time they are required to authenticate (e.g. sign on to a 5250 emulator, use Run SQL Scripts, etc). You can make MFA optional for a period of time. Specify a time – in minutes – when MFA will not be required after the user successfully authenticates using MFA. For example, if you specify 60 (minutes) for the interval and the user successfully signs onto a 5250 emulation session at 8:00 am, the user will not be required to use MFA when they sign into Run SQL Scripts prior to 9:00 am. (A valid user id and password combination is still required.) However, when they signon to Navigator for i at 10:30, MFA will be required because it’s outside of the 60 minute window.
In addition to the convenience of not entering an additional factor for a period of time, not requiring MFA for a period may allow users to avoid the awkwardness of entering the additional factor in some interfaces such as SSH. SSH is a good example of an interface that requires authentication but doesn’t present the user a traditional signon display. So how does one enter the additional factor? Like so: password:Additionalfactor for example, Str0ngPassw#rd:559012 . That might not be such a problem if one was given any sort of hint that that’s what’s required but one has to know/be educated on this. In the example below, I’m using Putty as my SSH client. You can see that the prompt merely says “password” – nothing about an additional factor being required. The second attempt I entered the requisite password:AddlFactor and I was signed on.
If you’ve configured profiles using these interfaces to not require MFA for a period of time, they could conceivably sign on to a 5250 emulator or use some feature of ACS, enter their additional token there and then use SSH during the optional interval to avoid entering the additional factor on the SSH connection.
Finally, consider configuring the network time protocol (NTP) server if you haven’t already. The timestamp between the authenticator app and IBM i must be in sync for IBM i MFA to work.
If you’ve already using integrated MFA with SafeNet, or our standalone 5250 MFA product, i2Pass, don’t think you have to throw it out! On the contrary! You can use it in addition to IBM’s MFA solution. Or, you can use it INSTEAD of IBM’s solution while still getting the benefits of having it called every time a user is required to authenticate (provide a user id and password) and not just for selected exit points. For some organizations, this will be the preferred method of implementing MFA. Why? Because sending a push notification to a phone as the MFA authentication method may be preferable and more user friendly than entering a code on an IBM display or, in the case of SSH, know how to specify the additional token as part of the password. It’s also more flexible and can be used for profiles running processes that typically don’t see a signon request such as an automated ODBC connection from a Windows server to an IBM i database.
Should you choose to only use Kisco MFA, the system value requirements won’t be enforced. Meaning that your system’s password level (QPWDLVL) doesn’t have to be set to 4 nor does QSECURITY have to be at level 40 or 50 (although we highly recommend systems do meet these best practice settings.) In addition, you don’t have to enable the Additional sign-on factor security attribute. In other words, MFA configuration is much simplified. Implementation consists of the following:
Please note: We have updated our SafeNet exit point product roadmap to include full 7.6 MFA integration in early 2026. Customers already using SafeNet will be able to upgrade at no additional cost.
Regardless of whether you use IBM i MFA, Kisco MFA or a combination of both, the question is, which users are you going to require to use MFA? If you ask me and if you follow security best practices, you’ll enroll all profiles that are allowed to use a 5250 signon, ACS, Navigator for i, ODBC, etc. The good news is that all MFA solution combinations allow you to choose which profiles are enabled to require MFA and how quickly you implement MFA. At a minimum, you’ll want to enable your powerful profiles – that is, those profiles with *ALLOBJ special authority - to reduce the risk of those profiles being compromised.
To determine which profiles have been configured to require MFA – either IBM i MFA or Kisco MFA, use the new fields added to the QSYS2.user_info SQL view as shown below.
For additional considerations on implementing IBM i MFA in 7.6, see the new IBM manual Multi-factor authentication (MFA).
RELATED POSTS
BROWSE KISCO U
PRODUCT CONTENT
