Comments on: Swapping user profiles

By: teandy

teandy — Wed, 28 Oct 2009 15:09:07 +0000

Since none of this makes since and the cl is already not working, why not try recompiling the cl using user profile AM2000 and USRPRF *OWNER?

By: tomliotta

tomliotta — Tue, 27 Oct 2009 18:36:40 +0000

Nothing new from me that will help yet. I had coffee last weekend with an ex-IBMer who was heavily involved in the design of the OS/400 version 5 security model and asked if there was any way for USRPRF(*OWNER) to work by itself. The response was practically identical to mine -- it shouldn't have worked. Interest was expressed in any example. Any chance you have a *FILE server exit program that was in place? Even though the *FILE server doesn't support adopted authority in itself, I can imagine an exit program maybe being affected by something done by the USRPRF(*OWNER) program, if the coding allowed for it. But even swapping in the exit program is supposed to be ignored by the *FILE server. Tom

By: tomliotta

tomliotta — Thu, 15 Oct 2009 01:40:06 +0000

There is no profile-swapping “code”…

Then it never should have worked. I don’t know what else to add on that point. I’ve worked in this area for years and I’ve never seen credentials passing in this way. (We market commercial products for this.)

There is a separation between ‘authentication’ and ‘authorization’. Ownership and USRPRF(*OWNER) are involved with authorization, but they should not be involved with authentication. If Windows allowed access, then Windows was broken. The credentials being passed would be for the current job user. If current user wasn’t switched to AM2000, then current user will be the job user. Windows should have no way to know who the owner was.

I can’t say it “never worked”. I can only say it “shouldn’t have” worked. I am very willing to dig into the issue. I sure don’t know everything about it. I do, however, have some resources available. If you have a definite code example that you’re sure worked on V5R3 without switching and you can share it, I’ll run it through some significant V5R3/V5R4 tests to get to the bottom of it.

Tom

By: whatis23

whatis23 — Tue, 13 Oct 2009 23:20:29 +0000

I setup QNTC a few months ago and it is now being used extensively. Since it appears everything is setup up correctly with AM2000 as the OWNER and USRPRF(*OWNER), I would try looking at the programs and menus wrapped around it. Is it reading from the correct library and not, for example, QRPLOBJ? Or if it’s using a command from the menu, is that set to the correct library that the program is complied in? Sorry but there isn’t much i can think of since it does work manually.

By: choyle

choyle — Tue, 13 Oct 2009 11:23:30 +0000

Let’s focus on one CL program that was previously compiled by AM2000 with USRPRF(*OWNER) and AUT(*ALL). This is our standard for cross-network functions, due to user AM2000 being the only iSeries USRPRF that is also a network user name (with the same password). The CL simply executes a CPYFRMIMPF using a QNTC path to copy a network file to a PF on the iSeries. This has always worked for any user given a menu option that calls the CL. User AM2000 can still today log on and manually execute the same CPYFRMIMPF command, but now when other users run the menu option, they get a hard error that their own profile name had an issue exchanging credentials with the network. And of course their own profile name WOULD have a problem; but up until now their job always executed the CL “as AM2000″. There is no profile-swapping “code” in the program itself; I assumed up until now that the authority somehow came from the way the CL object was compiled, but since that hasn’t changed, I don’t know what has… We did move to V5R4 since the CL was last compiled, but that may be unrelated; it’s just the only thing I can think of that is different.

By: tomliotta

tomliotta — Tue, 13 Oct 2009 03:14:32 +0000

For us to understand — how do you know that AM2000 has the necessary authority? Can you show us the special authorities assigned to the AM2000 *USRPRF? Can you show us the detail authorities that AM2000 has to the AM2000 *USRPRF object itself? And did you check to see if AM2000 is *ENABLED? (Hmmm… I’ve never checked to see if a profile must be NetServer/LAN *ENABLED for outbound /QNTC access. Maybe you should check that if nothing else works.)

I’m not aware of any related API changes between V5R3 and V5R4. Depending on your program, code some changes might alter how the program responds to various events. A message-handler, for example, might run under the job profile rather than under the authority of AM2000.

If the program isn’t changing the current user, then clearly there is an error in how the program does the swapping. Either the program has changed, or there are authorities missing. Regardless, the program should report its failure, but that would normally be by returning an escape message to the calling program. The joblog would normally contain that message.

Does the program switch to AM2000 by supplying the password for AM2000? Or does it use the ‘*NOPWD’ special value?

Tom

By: choyle

choyle — Mon, 12 Oct 2009 11:39:57 +0000

Thanks to everyone for your responses, and sorry – I may not have made the issue clear enough… AM2000 does still have all the authority necessary. It’s just that suddenly the jobs are running “as the user” instead of “as AM2000″, although we haven’t changed anything in the programming except to recompile the CL with parms USRPRF(*OWNER) and AUT(*ALL), which has always been our standard for CL programs. We are now getting an error because the user is NOT authorized to the share (deliberately). Also, QUSEADPAUT is still set to AUTL(*NONE) as it always has been. Still need help if anyone has any other ideas… Thanks again!

By: tomliotta

tomliotta — Sat, 10 Oct 2009 05:21:38 +0000

First thing to try is simply to logon as AM2000 at your AS/400 and test access to the share with WRKLNK ‘/qntc/servername/sharename’. If that doesn’t work, go the the PC (or server) and check if AM2000 can logon there — with the same password, of course. The two logons tell part of the story, and the WRKLNK tells more about the networking aspect.

If either logon fails, then the fix should become obvious from the resulting messages. If WRKLNK fails to find the server or the share, then a path to determine the fix would be indicated. If WRKLNK locates the share but doesn’t give access, then permissions ought to be looked at.

Try the sequence and come back with results. Note that it might simply be that appropriate V5R4 PTFs aren’t loaded/applied yet.

Tom