Admin Alert: The Poor Manager’s 5250 Single Sign-On

July 21, 2010 Joe Hertvik

Properly implemented, single sign-on (SSO) is a blessing for i/OS shops. With it, users log on to their desktops once and then access all their servers without entering several different passwords. But it’s always been problematic enabling SSO for Power i machines, causing some administrators to skip the process all together. This week, I’ll present a workaround for making PC5250 sessions act like single sign-on participants without configuring SSO.

Same as Single Sign-On, Only Different

In earlier articles, I outlined how to set up an i/OS system for single sign-on. (See Related Stories below.) A true SSO environment provides access control to multiple related (but independent) software systems using a single password. Under SSO, a user logs in once to their desktop and then gains access to all the systems on their network (including their iSeries, System i, and Power i machines). Because sign-on credentials can be different for different servers, SSO also has a mechanism for translating desktop user names into corresponding user IDs on other servers, allowing the user to sign on to each server in the network, regardless of whether the user names and passwords are the same.

However, SSO can be difficult to implement on i/OS machines. In a Windows environment, it requires implementing a Kerberos server, modifying your Windows Active Directory environments, and setting up and maintaining an Enterprise Identity Mapping (EIM) server. SSO can also be overkill in a medium-sized i/OS environment where the organization may only want to eliminate PC5250 password entry without having to support a larger infrastructure.

Enter the Poor Manager’s PC5250 Single Sign-On (PMPSSO). With this technique, you can get many of the benefits of implementing SSO for PC5250 without incurring the costs of maintaining an SSO infrastructure. The downsides of implementing the technique are: a) it only works for enabling PC5250 for SSO (it doesn’t work with any other i/OS connectivity technique); b) you must use iSeries Access for Windows; and c) your user’s Windows passwords must be the same as their i/OS passwords.

How It Works

The Poor Manager’s PC5250 SSO consists of the following components.

Changing the PC5250 user ID signon information to always use Windows user name and password, no prompting as its default value when signing on to the designated iSeries, System i, or Power i machine.
Setting up your PC5250 session to enable the bypass signon feature.
Changing the i/OS remote sign-on control system value (QRMTSIGN) to allow i/OS to accept the user ID and password of the remote system as credentials for signing on to the system.

Now let’s look at how it all fits together.

Client Access Setup

Client Access setup is easy and similar to what you use to set up most PC5250 sessions. You set up the following parameters in your PC5250 configuration to enable PMPSS0 for this user session.

First, click on Communication, Configure from the PC5250 menu bar. This will bring up the Configure PC5250 screen. Click the Properties button on this screen and the PC5250 Connection screen will appear as shown below. Change the User ID signon information value to Use Windows user name and password, no prompting, if it isn’t already set to that option. Your screen will now look like this.

Click the OK button after you make the change. This will take you back to the Configure PC5250 screen. On this screen, check the Bypass signon check box. Your screen should now look like this.

Together, these two settings enable PMPSSO on your Windows desktop.

i/OS Configuration

The entire Poor Manager’s PC5250 SSO setup hinges on changing one i/OS system value: Remote sign-on control (QRMTSIGN). QRMTSIGN tells i/OS what to do when a client wants to sign on remotely. It is used to control whether or not a user sees an i/OS sign-on screen when he’s connecting to the system by using any of these methods:

A pass-through session started on another i/OS partition by using the Start Pass-Through (STRPASTHR) command.
Starting a PC5250 session by using the Display Emulator feature in iSeries Navigator.
Starting a TELNET session with the partition by using PC5250 or another emulation program.

By default, QRMTSIGN is set to Forced Signon (*FRSIGNON), which means that all remote sign-on sessions must go through normal sign-on processing. However, if you change QRMTSIGN to Same Profile (*SAMEPRF) or Verify (*VERIFY), i/OS allows the user to bypass the sign-on display and automatically log onto the system. You can view and change your QRMTSIGN value by running Work with System Values (WRKSYSVAL) command for QRMTSIGN and then placing a 2=Change in front of the QRMTSIGN entry and pressing enter.

WRKSYSVAL SYSVAL(QRMTSIGN)

This will give you a screen that looks like this.

If you change the Remote sign-on control parameter from *FRCSIGNON to *SAMEPRF, i/OS will check the passed-in Windows user ID and password for your PC5250 clients who are configured correctly. If their credentials match a corresponding user ID and password inside i/OS, the user will be automatically signed on to their PC5250 green-screen session. If the credentials do not match, the user will be presented with a sign-on screen. If after signing in, the unmatched user changes their password so that the user ID and password now match their signed-on Windows credentials, they will be able to automatically sign in on their next try.

See, I told you it was easy.

The Downsides

The biggest downside to this technique is that you have now opened up i/OS green-screen access to anyone who sits down at a PMPSSO-enabled desktop. Your users will no longer have to sign in to get access to your production data, which may also include financial data. If your users leave their desk without locking their Windows desktop, other users can sit down at the open desk and automatically sign on. You can mitigate that risk somewhat if your organization requires users to automatically lock their desktops after so many minutes of inactivity. With a self-locking desktop, you reduce the risk of unauthorized sign-on.

It’s also worth considering that many users have a PC5250 session open all day. If a user leaves their desktop with a connected PC5250 session signed on, it’s exactly the same risk as if another user clicks on a PMPSSO-enabled session and signs on automatically. The end result is the same: an unnamed user is getting into i/OS data using another person’s profile. A wise administrator should plan for either eventuality and configure their desktop protection to provide as little unauthorized usage as possible.

In this non-password environment, you may also want to consider the following items:

Research carefully if your systems are reachable by Telnet directly on the Internet, as this scenario can make your iSeries, System i, or Power i system more vulnerable. This technique works best in a closed network where your system is not exposed to the outside world.
If you enable automatic sign-on, you may want to restrict where security officer-enabled users can sign on by using the Limit security officer device access system value (QLMTSECOFR). Activating QLMTSECOFR restricts security officer users from logging onto any device that they are not explicitly authorized to use. For more information on using QLMTSECOFR, see this article on limiting security officer telnet access.