Swapping user profiles

100 pts.
Tags:
IBM iSeries
iSeries User Profiles
User profiles
We do not have single-sign-on, and have an iSeries user profile named "AM2000" that also exists on our network. Historically, by compiling CL programs as AM2000 with USRPRF(*OWNER), any user could execute the program and access network files "as AM2000". Something has changed (possibly moving from V5R3 to V5R4, possibly something else), and now compiling CL programs this way no longer works; the executing user gets an error that HIS profile name is not recognized by the network. Does anyone know what has happened, and/or how we can fix it? I'm aware that I can submit a job to run "as AM2000", but we have dozens of programs in question and I would hate to have to rewrite all of them. Thanks in advance!

Answer Wiki

Thanks. We'll let you know when a new response is added.

Sounds like an “Adoptive Authority” issue???

Voodoo

IN V5R4 many network actions start coming through as QUSER. It may be that QUSER isn’t authorized to the library, program or rmtcmd. Find the joblogs and see what user profile is being used. I’ve got a gripe with IBM over this and have told them frequently. Please do the same. Even with exit programs I can’t get some functions to run unless QUSER is authoirzed to your prod libs, which makes a joke of object level authority management.

__________________________

If use adopted authority is set to *YES, check the system value QUSEADPAUT.
Verify no change was made there.

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Choyle
    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!
    100 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Choyle
    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.
    100 pointsBadges:
    report
  • Whatis23
    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.
    5,665 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Teandy
    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?
    5,860 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following