By Robert MacAdams on Friday, 09 November 2018
Category: Uncategorized

IBM i 2FA Two-Factor Authentication FAQ

IBM i Two-Factor Authentication (2FA) is a quick and simple to implement Multi-Factor Authentication solution that ensures a user’s identity before granting access to critical or sensitive data on your system. IBM i 2FA can be enforced for various connection types, including interactive 5250 telnet signon sessions, and for most TCP/IP connections where users logon thru an exit point, such Database Server for ODBC and JDBC connections, Signon Server, FTP Server and File Server for accessing the IFS, which can help prevent ransomware and other forms of malware from damaging your system. IBM i MFA can also be used for securing SSH and sFTP connections, which does use an exit program to intercept the connection to grant access. IBM i security exit programs have various methods for checking a user’s permissions, however invoking Two-Factor Authentication can provide a simple second layer of security to ensure only authorized individuals have access to your IBM i.

IBM i Two-Factor Authentication is a multi-layer security process that requires users to verify their identity utilizing two or more identification categories, which include something the users Knows, Possesses or an inherent biometric feature.  Since a User ID and Password are both from the same “knowledge” category, this type of authentication is only considered single factor authentication. Adding an additional identification requirement from a different category is what delivers Two-Factor Authentication, also known as 2FA, Multi Factor Authentication or MFA. The lesser of these other two authentication categories is the “something the user possesses”, such as a token or physical card like a smart card. Companies may use various forms of delivery, such as an application running on cell phone or workstation, an email, printer, or like device for delivery, but a second factor must always exclude criteria from first category in order for the process to be considered ‘Two-Factor’. The most strict additional authentication factor is the biometric feature, because these identity factors are essentially unique to each individual and hardest to circumvent.

Frequently Asked Questions

How long does implementing IBM i 2FA take?
Installation typically takes 15-20 minutes, basic setup takes about 10 minutes and configuring a Two Factor Authentication rule for an interactive 5250 Telnet connection takes another 5-10 minutes (assuming the MFA rule is using the built in authenticator included with product that runs on the IBM i). If a customer wants to integrate with an authenticator a company already has in place, this may take another 10-20 minutes to setup.  IBM i 2FA supports third-party authentication solutions and services such as RADIUS Server used by RSA, Okta, Symantec, PingID, CrowdStrike, and Proxy Servers used by DUO, Microsoft Entra for Azure and Office 365, as well as other well-known MFA service providers.

What external resources are needed to implement 2FA on the IBM i?
IBM i 2FA is an 100% native OS400 solution, and even includes its own authenticator that resides on the IBM i. The IBM i 2FA solution does not have any external requirements. Although using the IBM i Two Factor Authentication product’s built in authenticator can save a company money and a bit of hassle by not having to involve the network team, using it is entirely up to the customer. The IBM i 2FA product support third-party’s authentication services for integrating with the corporate network’s existing MFA solution. Integrating the IBM I 2FA can be done with any RADIUS-based Server commonly used by RSA, Okta, Symantec, PingID, CrowdStrike, and Proxy Servers used by DUO, Microsoft MFA and MS Entra cloud based MFA using NPS with for Azure. The IBM i signon process can be integrated with almost any MFA service provider that supports PUSH notifications or the TOTP Password Authentication Protocol (PAP) protocol. All 2FA integrations require the IBM i to be added as a Client to the authentication server, and the IBM i admin simply adds the IP Address, Port and Shared Secret of the authentication server to complete the secondary authentication. As a result, your IBM i users will be authenticating with MFA the same way on the IBM i, as they do for the rest of the corporate network.

How can IBM i 2FA work when our User IDs on the network are different than our IBM i profiles?
The IBM i Two Factor Authentication product uses a file that maps the IBM I Profile with the User ID on the Authentication server. This is the case with most environments.

What types of logons or connections does IBM i 2FA secure?
Common use cases for IBM i Two Factor Authentication includes protection for 5250 Interactive Telnet Sessions, web applications, and almost any network connection type, including SSH, sFTP, FTPs, FTP, ODBC, JDBC, DDM, Signon Server, and File Server. Requiring MFA for File Server access is ideal for protecting the IFS in real-time from ransomware and other forms of malware damaging your system and beyond. Two Factor Authentication can also be invoked when users run specific commands, attempt to access sensitive libraries or files, or for when users need elevated authorities. There are many unique scenarios that admins may want to tighten security, and MFA would provide a very quick fix.

Our company has been using Two Factor Authentication for our IBM i systems for a long time, however it is a two step process, and we would like to implement the more secure one step 2FA approach. Can one step 2FA be implemented on the IBM i?
Yes, single step 2FA can be implemented very easily and quickly. The IBM i Two Factor Authentication product supports both one step and two step 2FA. One step 2FA involves initiating the second authentication factor on the initial Signon Screen and the IBM i’s response for the User ID, Password and second factor is returned all at once. One step is considered the most secure method, because there is no way of knowing which of the three were incorrect. One step requires using the IBM i 2FA product’s signon screen included with the product, which also runs in a dedicated subsystem for multifactor authentication.  Two step 2FA initiates the second authentication factor after the user is authenticated using their User ID and Password via the standard IBM i signon screen. Once authenticated, users either must authenticate using a third party authentication service, such as with a RADIUS server implementation that may use a PUSH notification or may require a passcode, token or network password + passcode the must be entered on a second screen.

Does Two Factor Authentication work for users that do not have access to a phone or email?
Users such as warehouse staff using devices that do not support traditional MFA mechanisms, can be setup to use question and answers for additional security. Although it does not meet the second factor criteria requirement being in different category than the ‘same knowledge category’, it does provide an additional layer for security.

We want to secure the IFS with MFA, but only interested in securing connections to file shares that have a mapped network drive. Can MFA rules target just these types of File Server connections?
Yes, for this 2FA use case, we would use an 2FA rule in conjunction with the File Server exit program and Job Name QZLSFILET which are “NetServer” jobs for SMB/CIFS requests.

We use RSA RADIUS for our Multi-Factor Authentication. Is your IBM i 2FA solution certified by RSA?
Yes, it is certified by RSA for SecureID to support integration with RSA RADIUS servers and RSA RADIUS cloud services using biometrics, such as a finger print or facial mage from a mobile phone, as well as traditional voice mail token, SMS token, and PUSH notifications.

What are the system requirements for IBM i Two Factor Authentication?
The IBM i 2FA solution requires OS400 V7R3 or higher for the base interactive 5250 telnet rules. Network access control with 2FA enabled will require corresponding supported exit programs. If using a third part authentication service, ports will need to be opened for communications.

What is the difference between One Step 2FA and Two Step 2FA?
One step authentication is considered the most secure and thereby the recommended method. One step authentication will prompts users for all identification and authentication factors on a single screen and validates all factors at one time. If authentication fails, the user does not know which of the factors was incorrect. Two step or multi step will prompt users for their User ID and Password for identification and confirm if authentication is correct or not before moving to the second factor for authentication. This multi-step process confirms which one is correct and incorrect. Some compliance regulations do not permit two step or multi-step authentication.

Can Password Self-Service PSS be implemented using Two Factor Authentication?
Absolutely. The IBM i 2FA solution includes User Self-Service rules that can allow users to change their password and re-enable their profiles securely. 

Can Two Factor Authentication be used to secure access to a file?
Yes, a 2FA rule can be created to control access to a Library, File and to control access to powerful commands. Use 4 Eyes Risk Control for Very Sensitive Data
Four eyes principle is a process used when requirements dictate two people to be present at the same time an access or change occurs. This extreme protocol is not very common, but a few environments may have a need to ensure very sensitive data has these safe guards in place, allowing supervision of access or changes where significant risk exist. IBM i MFA allows for Four Eyes principle to be invoked using its rules engine, so if a user needs to perform a sensitive change or operation, a designated supervisor will receive an email with a single-use token with the user’s information making the request. The supervisor will enter the token into the user's screen and observe the change or operation while it is being made.

We only want a certain subset of users like Admins and Programmers to have additional authentication. Can we choose which users must use two factor authentication?
Yes, IBM i Two Factor Authentication provides many selection criteria for determining which users will require additional authentication. You may also have as many authentication rules as you, of which can all function differently. i.e. some user groups will use RADIUS, some will use the built in authenticator running on the IBM i, and users with RF devices will use Question and Answers. There are many user profile and job attributes that can be used to invoke a 2FA rule, and can be used for other reasons other than logon. However, here are some of the user and job attributes that can be used as selection criteria and trigger a 2FA rule:

Caller Program + Library
Many User Profile and Group options with wildcards, plus ‘All User Profiles’, ‘a Specific User ID’, ‘a Static List of Users’, ‘a OS400 Group Profile and/or Supplemental Group, and various wild card options to include groups of users based on patterns. 
Registered profile (all profiles must be registered for any 2FA, MFA or User Self-Service feature to be enabled for the user)
Profile Description  
Special authorities 
Limit capabilities
User class
Accounting code
Profile Status
Specific Device
Language
Initial Program + Library
Initial Menu
IP Address or Range
Date & Time
System Name
IASP 
Subsystem
Job name
Job type
Job subtype

How does IBM i 2FA work?
IBM i 2FA forces users to authenticate with their User ID and Password, as well as an additional and different identification factor that is in a different category as the knowledge one the User ID and Password fall into. Requiring at least two authentication factors, there is a much less chance of unauthorized access. The different ‘factor’ categories and examples are below:
Something the user knows (example: password, PIN, answers to security questions, passphrase)
Something the user possesses (example: email account, smartphone, code-generating device or application)
Something inherent to the user (example: fingerprint, iris scan, voice or other unique biometric attribute)

Before choosing an IBM i Multi-Factor Authentication MFA solution, consider the following:

Does the solution support all the logon connection types you need to secure with 2FA or MFA?  
Interactive 5250 Telnet is the most common connection type for 2FA.  The next most common is Signon Server. Signon Server is used by a lot of third party applications, and even many IBM applications, such as IBM Navigator. IBM Navigator actually connects via a lot of exit points. When a user signs on to Navigator, the profile will often perform 3 to 5 different logons using various exit points depending on what the services the user uses. Both Database Server and File Server are probably the next two most commonly protected. Protecting the File Server with MFA is an ideal way to help protect the IFS from ransomware and other malware where there are users with a mapped network drive to a File Share that has more than Read authority. Web applications such as ERP and CRM are also more commonly being requested. Lastly, companies that allow external SSH and sFTP connections to their IBM i, should seriously consider requiring 2FA or MFA. Always do an evaluation and test your applications and various use cases before making a decision.

Does the solution offer one step 2FA or MFA as an option?
Even if your company does not have to implement one step 2FA today, if your company is in an industry with compliance regulations that are constantly changing, such as PCI or Health Care, it might make sense to chose a solution that supports one step today and not have to lose your investment and abandon your efforts in the future.

Is the 2FA solution flexible enough to be implemented how you envision and address your use cases?
The answer to this one is usually pretty straight forward, however doing an evaluation usually paints a clearer picture.

Is the 2FA or MFA solution 100% native to the IBM i?
If the 2FA or MFA solution required additional non-IBM i servers and services running, are you comfortable relying on these other groups within our company to implement, manage and maintain user access to your system?