Thanks Bruce

That’s it exactly. I am not using the RMTUSER parameter. So, the exit program is getting passed blanks, and everyone is getting disconnected thru Telnet when I chain this value against a file that I created which contains authorized users only.

Besides TELNET, are there any other progams that would also initially pass blanks to the exit program ?

Because if not, what I would like to do is test for blanks rather than check against a file of valid users. If blank, I could then end the TELNET session.

Otherwise, I will need to understand more about the RMTUSER paramater and how/where this value gets defined.

Please advise

Nick

Nick,

There are many IBM and 3rd party telnet client implementations available. Most that specifically support System i will have the option to allow automatic signon, which basically means your exit program would see a non-blank profile name. All of them though would also have the option of not automatically signing on, in which case the exit program could/would see blanks for the profile name. Generic telnet clients would only support manual signon (as automatic signon is a 5250 telnet extension). Given this environment I’m not sure how to answer your question. I believe it’s more a question of how you want to configure/secure your user environment.

Bruce

Hi Bruce

Thank you for this answer.

Here is my dilemma.

I do not want to allow a user the ability to get to the AS400 thru TELNET from a PC, from the RUN command, whereby he(she) would type in telnet xxx.xxx.xxx.xxx. Yet, at the same time, I do want to allow this same user the ability to get to the AS400 by opening up a client access session.

Whenever I add this exit program, it prevents a user from getting in thru client access as well as thru telnetl. This will not work !

At this point, I am not certain that I even need an exit program. But, this is what I am trying to accomplish.

Thank you for all your assistance

Nick

Hi Piano,

I think that you have to face this from the PC side. Any server will just listen to a connection request, but the way of sending this request is a client issue.

Maybe you should try an administrative solution from the client’s side (being it MS Win, *nix, etc).

Good luck.

Hi Bruce

I had a thought. I am wondering if there is a way to require RMTUSR paramter to be keyed in, when typing telnet from the pc RUN command.

Because if there is a way to do this, then, I may be able to utilize the telnet exit program that you provided.

Again, as long as I can still get to the AS400 thru a client access session. This has been my problem all alond. I only want to affect the pc RUN command with my exit program. Otherwise, noone can get to the AS400 from C/A which would not be good.

Please advise

-nick

Hello

As a reminder, my dilemma is this. Whenever I screen for a user id in the sample exit program that I am currently testing, tthe program works fine. By works fine II mean that the user exit program will screen for the user id and when blank, the AS400 telnet connection will disconnect. Unfortunately, my user exit program also blocks local users from connecting to the AS400 thru a Client Access Session.
Evidently, the user id must come in as a blank here as well.

For an update, I just installed a different exit program off the Internet to test. Namely DEVINIT2. This program enbles you to change the MAP file in QTXTSRC thru SEU. So, I went ahead and changed the user id to be NICK instead of (wildcard or any user id). It didn’t work. when screening the user id it allowed any user id to get in, even after I saved the change in SEU and put in a specific user id in one of the parameters.

I failed to mention that when I say let me in thru TELNET, I mean thru the PC RUN command telnet xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the I/P address of the AS400.

Does anyone have any ideas? I really would like to get either exit program to work. Seems simple enough in that all I am really trying to do, is prevent people from accessing the AS400 from a PC, thru the PC run command TELNET.

Thanks for your thoughts and ideas

-Nick

Does anyone have any ideas?

Just to close this issue, the approach simply won’t work. It’s based on a misunderstanding of what the &Usr_Info contains as well as how it should be used.

In general, a telnet user isn’t identified until a signon happens. A signon will happen as soon as the telnet connection is established and the signon panel is displayed and a user ID is typed into it.

But if the session is rejected, then the session never gets as far as the signon panel. (A panel cannot be displayed until after a connection is established.)

But actually that explanation is incomplete. The term “signon” isn’t defined well enough.

TN5250 has the capability of passing a user ID and password to the telnet server and even bypassing the signon panel entirely. For this to happen, the telnet client on the PC must be configured to request and send user ID/password.

The resolution is to ensure that client PCs are appropriately configured. To do that, the exit program probably shouldn’t be rejecting connection attempts during the first few days it’s being used. It should be logging connection IP addresses that don’t supply a user ID. The log can be used to find and correct whichever PCs need to be set correctly.

Once a significant majority of PCs are set appropriately, the exit program can start rejecting unidentified connections. With a little experience, all users will know the appropriate reaction when connections fail.

Tom