Sign-On Server Exit Point Processing

[Guest.Visitor]

Here's our situation. We have a client (a group of people) running Windows 95/98 who need to access our system and applications. They come in over TCP/IP. They sign in on Client Access greenscreens using AS/400 user profiles we set up for them. However, they do not want to change their local Windows profiles and passwords to the ones they use on our AS400. So, for now, they are all connecting to our system as GUEST users. This represents several security and access-control problems. Let's say they have a Fred Jones there. His Windows profile/password is FJONES/kitty, and his AS400 profile/password is FREDJ/ZA2R93X. What I would like to do is "validate" his FJONES/kitty as OK to sign on to our system and use the appropriate AS400 profile for his security, instead of using GUEST. I think I might be able to do this with an exit program on exit point QIBM_QZSO_SIGNONSRV which I think is used by the TCP signon server job, QZSOSIGN. My understanding of exit-point processing is that the exit program merely returns a 1 if the request is to be allowed, any other value if not. The QZSOSIGN then does things. What I am thinking of doing is setting up an exit program that will look up the Windows profile/password in a table and allow the system signon if the user is one of ours or is in the table. This leads me to some questions: - Do I understand this correctly? - If Windows profile FJONES is validated as OK, but profile FJONES does not exist on our system, then what authority does that user acquire if I simply tell QZSOSIGN he's OK? - If Windows profile FJONES is OK, can I have the exit program swap profiles to FREDJ as well as tell QZSOSIGN he's OK? How and where? That would only swap it for the QZSOSIGN job, right? What about other jobs that I think use the Windows profiles, like file & print servers, or even just giving him a signon screen so he can sign on as FREDJ? I believe security checks using the Windows profile occur at all those points. When my AS400 password is near expiring, it'll ask me if I want to change before giving me a signon screen on my PC.... Thanks in advance, Ken

[Guest.Visitor]

Ken Rokos wrote: However, they do not want to change their local Windows profiles and passwords to the ones they use on our AS400. I must be missing something here. How can having different profiles on the AS/400 change the users' windows profile? Dave

[Guest.Visitor]

Ken - Are you wanting to do this to avoid the 'Signon to AS/400' Windows password dialog? Are these users 'green screen' users? If 'yes' to both, why not use another emulator? If 'no' to either, please explain the situation in more detail. Thanks, Steve

[Guest.Visitor]

David - the AS400 profile doesn't change the Windows profile. They want to retain the Windows profiles they're using and NOT change them to the AS400 profile. But automatically connecting to a Netserver/400 share uses the cached Windows profile/password, which currently forces us to use a GUEST signon. Steve - I believe the answer to both your questions is Yes. ("Are you wanting to do this to avoid the 'Signon to AS/400' Windows password dialog? Are these users 'green screen' users?") But switching to another emulator wouldn't change how the Netserver/400 share signon works. This all occurs BEFORE any greenscreen emulator is even started. However, I'm not sure I've adequately or accurately described the situation. I'm not sure what the exact sequence of events and security checks is when one of these remote users signs on -- what password is used at what point, for example. I can see that some of these users have QZLSFILE file-server jobs in use by their profiles, so perhaps they ARE signed on to Netserver under their AS400 passwords and not via GUEST. User GUEST has one QZLSFILE job in use. I'll have to check with our networking guy to see when and why we had to set up GUEST to let them use our system. He's actually the one behind this question; I'm just looking for solutions to it and didn't set up the configuration in question here.

[Guest.Visitor]

Ken - Aha! You didn't tell us you were using Netserver. I believe that Netserver is always going to use the cached password unless you have an 'alternate' user defined (in this case 'GUEST') but I'm not a Netserver expert. If you use an exit program, you can do all the processing that you described earlier but the signon is still going to go through the /400 signon routines. The exit program is merely a detour along the way, it does not replace the /400 routines. HTH, Steve

[Guest.Visitor]

Steve - Thanks. So I guess that means we can't tell Netserver "Use a different profile than the one you originally received"? Maybe I'll check the security and profile APIs; there's some new stuff at V4R5, but I think it just extends UNIX-like functionality.... Best, Ken