One of the things I like best about my job is that I get to see a lot of different environments using many different parts of the operating system. This often gives me the opportunity to learn something new.
Recently, I was helping a customer implement SSO. After getting everything set up, we started testing. Everything worked but Telnet!
Hmmmm… the first clue was that the connection was made but the signon screen was being displayed.
So the first thing I checked was to make sure we changed the PC5250 configuration to use Kerberos. We had. The next thing I considered was whether there was a configuration problem with Kerberos or EIM. I realized, however, that a) the problem was affecting only Telnet — Netserver was working fine; and b) Telnet usually fails to display a screen at all if it’s a Kerberos or EIM problem. So I pretty certain that wasn’t the issue.
The next thing to check was the value of the QRMTSIGN system value. Some shops have this to force a signon screen (*FRCSIGNON). This needs to be set to verify (*VERIFY). This tells Telnet that authentication is required, but it doesn’t have to be done from the signon screen. It can use a userID/password passed on the connection request (rather than entered on the signon screen) or Kerberos.
This is where my education began.
Rather than being set to special value, QRMTSIGN was set to the name of an exit point program. Wow. Long time since I’ve seen that. I was vaguely aware that this exit point was used with PASSTHRU, but I wasn’t sure how or whether this setting affected Telnet connections. The customer still has some direct attached terminals and is still using PASSTHRU from these terminal.
My first stop was IBM’s online Knowledge Center. I found the QRMTSIGN system value description here. In the description of the “program-name library-name” value it says: “The program specified runs at the start and end of every pass-through session.” OK. It confirms my recollection that it was related to PASSTHRU and it allows the customer program to determine whether or not to allow the PASSTHRU session. But it says nothing about Telnet.
Then I took a look at “Controlling Telnet Access” in the knowledge center. This article shows the special value options for QRMTSIGN, but it doesn’t even mention program-name library-name as one of the options. The descriptions for the *VERIFY and *SAMEPRF options also contained a superscript that says: “A registered Telnet exit program can override the setting of QRMTSIGN by choosing whether to allow automatic sign-on for a requester (probably based on IP address).” OK. But there is nothing that says what the Telnet behavior is in the absence of a Telnet exit program and whether or not overriding that behavior affects the PASSTHRU exit program.
I spent a lot of time trying to find the right Google search string that would point me to the information I wanted. I began to assume that the behavior of Telnet — when QRMTSIGN was set to the name of a PASSTHRU exit point program — must be the same *FRCSIGNON. I didn’t want to recommend a Telnet exit point program to the customer until I was sure it wouldn’t affect the behavior of PASSTHRU. I finally resorted to phone calls and a couple of emails to IBMers (I really try to avoid this if at all possible. Don’t want to wear out my welcome J ).
After a little more than 24 hours I got the definitive answer from an IBM contact. Yes, indeed, the behavior of Telnet when QRMTSIGN is set to the name of a PASSTHRU exit point program is the same *FRCSIGNON. Further, the QIBM_QTG_DEVINIT exit point allows the exit program to override the setting the of QRMTSIGN – without affecting the behavior of PASSTHRU! Yeah! I had my answer and learned something new at the same time!
Then I went to the “Device initialization exit program” article in the knowledge center. Turns out the exit point logic was very straightforward. Just check if the value of QMTSIGN is set to a program name. If so, set the “allow autosign-on” output value to 1, and you’re done. No fuss. Not much muss!
All-in-all, while it was a bit frustrating to not be able to find the information I needed, I was eventually able to get the definitive description of what was happening and why. And because it was a whole new problem, it was actually kind of fun tracking it down. Now, had there not been such an easy fix, I might have had to describe an entirely different experience! Thanks to my contacts at IBM, though, I now know more than I did couple of weeks ago!
