strpasthr problem

[Guest.Visitor]

Hi, I have 2 AS400 systems A and B connected, I want : users in system A can passthru to system B, but users in system B cannot passthru to system A. How can I do that?

[Guest.Visitor]

strpasthr problem

You could secure the STRPASTHR command...

[Guest.Visitor]

strpasthr problem

I am not the QSECOFR in system B. In fact, I can not do anything in system B, all I can do is to proctect system A.

[Guest.Visitor]

strpasthr problem

I may not have understood you properly, and am shooting from the hip, besides, so apologies if this misses the mark... Obviously, you can prevent anyone with a UsrPrf on system B from STRPASTHR to system A simply by not giving them a UsrPrf on A. Therefore, you must be concerned about someone who has a legitimate UsrPrf on both systems. You don't mind him signing on to A directly, but you do mind if he signs on to B then signs on to A via pass-through. It might help if you stated what you are really trying to do/prevent, because the above doesn't make much sense, does it? Since either route to system A simply leads to a signon screen, I don't think you can do what you say you need to. Unless a signon-exit pgm can call some API and pick up the source of the signon rqs? Another thing I don't know about is set-up for how devices, or rather a subsystem, is/are assigned to a rqs for an I/A session via pass-through. Also don't know if this can be customized to the "source" of the rqs. For example, you might not mind if the rqs comes from system C, it's just those wicked B folks who must be excluded.

[Guest.Visitor]

strpasthr problem

Thanks for the response. The simplest word of my worry is : I don?t want any user on system B access system A, neither a signon screen. Since there exists many IBM supplied USRPRFs such as QSECOFR on every system, if user on B get a signon screen on A, he may guess the password of those USRPRFs. The worst case is all USRPRFs on system A are disabled (system value QMAXSIGN on system A = 5 ), This is my concern. I have 2 ideas to solve the problem but I am not sure are those work. 1. As Peter said, a sigon-exit program can help to exclude the users from B. But the point is I can not identify the user comes from which system. Is there any command do this? 2. In the Configuration list (WRKCFGL), there has many parameters which control the access from other system. It may has something to prevent STRPASTHR from other system even to get a SIGNON screen.

[Guest.Visitor]

strpasthr problem

A program can determine if it's running under pass-through by calling Retrieve Device Description (QDCRDEVD) API, format DEVD0600. Position 831 contains a pass-through indicator. For example in REXX,

Data = Copies( '00'x, 4096 ) "RTVJOBA JOB( &Dsp )" "CALL QDCRDEVD ( &Data X'00001000' DEVD0600 &Dsp X'00000000' )" Pass = Substr( Data, 831, 1 ) Select When Pass = 0 Then Say "Not pass-through" When Pass = 1 Then Say "5250 emulation type display" When Pass = 2 Then Say "Virtual terminal using Virtual Terminal APIs" When Pass = 3 Then Say "Virtual terminal display using TELNET" When Pass = 4 Then Say "Pass-through device" End

[Guest.Visitor]

strpasthr problem

Kong, There is a way to do what you want. This is using the system value QRMTSIGN, you could make a program that recives the information necesary for make desicions even before show the signon screen. If you want an exemple of it send me an e-mail to jleal@vto.com.

[Guest.Visitor]

strpasthr problem

I still agree with Peter Meyers. If your concern is IBM-supplied profiles, then what about anyone who can get physical access to a workstation attached to the other computer? Have these profiles been changed from their original IBM-supplied passwords? Are you now or are you planning ever to have that AS/400 on your network? What about access from outside your network, besides pass through? These would all also pose the same security risk, I would think. Also, by trying to create whole new applications to secure from the possibilty, you're really adding a lot to your maintenance load down the line. And maybe even create a false sense of security... A lot of damage can be done with IBM-supplied profiles, if they are of high-enough authority. You might even think about disabling the unnecessary profiles, such as QPGMR, QUSER. No one should really be using them, and QSECOFR can always enable them again, if needed. I am not advocating deleting them, just making them inoperable. I have disabled my QSYSOPR user profile, for instance, and given QSYSOPR level authority to those user profiles who need it. For what it's worth.

[Guest.Visitor]

strpasthr problem

Re: disabling IBM profiles. I wouldn't recommend that, best idea is to set the password to *none, that way they cannot be used to log onto the system but can be used for batch processing etc etc.

[Guest.Visitor]

strpasthr problem

You can use a disabled user profile for batch processing, no problem that I've discovered, and I've been doing it for several years now. As I said, I disabled QSYSOPR, and then all my production jobs are scheduled to run under user profile QSYSOPR. The message queue is still available. Near as I can tell, so far, no bad effects. Password *NONE is a cool idea, too, though.