Is there a way a user who is the owner of is userprf enable is disabled id without logging in to the system

1,160 pts.
Tags:
AS/400
CL Program
iSeries
RCMD
USRPRF
Is there a way a user who is the owner of is user profile be able to enable is disabled id without logging in to the system. Eg. say by using rcmd? using ftp.

Software/Hardware used:
as400, iseries,v5r4, cl400
ASKED: January 27, 2011  12:10 PM
UPDATED: April 19, 2011  8:58 AM

Answer Wiki

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

This typically happens when a user by mistake disables his id by keying in his password wrong thrice, however remembers it later. Instead of himself enabling his id , he calls the helpdesk and has to wait for the helpdesk to enable is profile and thereafter respond.

We keep getting calls for such cases.

Discuss This Question: 30  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
  • Jaymz69
    I see my company has a login called ENABLE Then it calls a program that brings up user id the user keys in their id ENTER/ the *SIGNOFF happens as the menu then they are ENABLED
    765 pointsBadges:
    report
  • TomLiotta
    ...without logging in to the system. Eg. say by using rcmd? using ftp. Those require logging on to the system. FTP won't grant a connection for RCMD until you log the FTP session on. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    the user keys in their id Can a user key in someone else's ID? Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Tom, iam able to get the user id enabled by another user using rcmd. Is there a way by which the user himself can get his own user id enabled without using the help of another user id.(Since he is the owner of his own user profile)
    1,160 pointsBadges:
    report
  • JohnsonMumbai
    Another option is to empower an already logged in user to call the program which is used to enable the user id.
    1,160 pointsBadges:
    report
  • TomLiotta
    Is there a way by which the user himself can get his own user id enabled without using the help of another user id. Yes and no. At least one user id is necessary to run whatever process executes the enablement. A batch job may run under a *DISABLED profile. But there needs to be some *ENABLED profile that causes the initial process, so there will always be at least one *ENABLED profile involved in addition to the *DISABLED one. It might be that you will have a common profile that anyone may log on to. In order to have it enable other profiles, the password for the *DISABLED profile should be supplied. The common profile should have enough authority to switch to the *DISABLED profile using the supplied password. If the password is wrong, the switch should be rejected. If the switch succeeds, then the switch should be discarded. The process should switch back to the common profile. With a correct password, the process profile should then be able to set the problem profile to *ENABLED without concern. The password helps to confirm that the only user who can use the process is the one enabling his/her own profile. Otherwise, someone could test lots of passwords for someone else's profile and be able to re-enable it over and over. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    How do you switch? Also is it possible to automate the process. How would you supply the user id and password to the common id, which will enable the disabled id. I have not understood fully what you have mentioned.
    1,160 pointsBadges:
    report
  • JohnsonMumbai
    Also how do you track the number of attempts being made to get enabled a particular user id.?
    1,160 pointsBadges:
    report
  • Bigmac46
    I have add it happen to me where I have had a "Communication Problem" with A CA session. The session locks up for whatever reason and I end it but it shows as active I kill the jobwith tthe second session I usually have open. VARY IT off/on just because and when I try to log in it says my userprofile is disabled. I have tried to just reset the password to get back in but it gets diabled imediately unless I end the active job and drop the session on the PC before trying to use the session again. Don't know why it happens but I did not believe I was getting told the "TRUTH " by users who called for help until it happened to me. I thought they were just forgetting their passwords and blowing out the profiles. V5R4 not sure which CA version .
    1,000 pointsBadges:
    report
  • TomLiotta
    How do you switch? Also is it possible to automate the process. Review the discussion in the Swap a user ID in AS/400 jobs question. Look at the descriptions of the APIs that are mentioned and see if the discussion on the general programming method makes any sense. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    I have add it happen to me where I have had a “Communication Problem”... Emulator sessions might be set with the 'Auto-reconnect' attribute -- a temporary networking interruption might trigger attempts to 'reconnect automatically' behind the scenes and result in a number of rejected logons. Windows might have mapped drives that get disrupted -- a networking interruption might trigger attempts by Windows to re-authenticate to NetServer with a Windows password or some other cached password value that results in multiple rejected logons. Without seeing network traffic, it'd be hard to narrow down possibilities. (It's hard enough even if traffic is captured.) A review of all T/PW entries in the system audit journal might help. It should at least gave indications of which server jobs were being contacted. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Thanks Tom for the detailed response. But was hoping to get a simpler solution. Though our IT security team would not allow automatic enabling of user ids without getting details of which user id enabled which user id. Getting details of audit logs etc/sending of mail to the user whose id was enabled and also sending mail to the user id which performed the id enabling. Hence wanted to know if there was a way by which a user is able to enable his own user id as he any would have full access to his own userprofile.
    1,160 pointsBadges:
    report
  • Batman47
    Wouldn't that defeat the purpose of security?
    1,050 pointsBadges:
    report
  • TomLiotta
    But was hoping to get a simpler solution. How much simpler could it be? Users log onto the common controlling profile, enter their profile and password, and they're enabled. The common controlling profile would only have this one function as its initial program and *SIGNOFF would be the initial menu. All users could enable themselves as long as they know their passwords. Nobody could sneak into a different account unless they already knew the password. Any system administrator or security officer can enable users for unusual cases where the program can't be used (if any such cases ever come up). The program could send messages or e-mails or create log entries if you wished, though it's hard to see why they'd be needed. There isn't any big issue with users re-enabling themselves under normal circumstances. If the concern is that a terminated employee might enable an old profile, then set the password for such employees to *NONE (which should be done anyway) or simply change it anything else. About the only way it could be simpler would be not to require users to identify themselves by entering both profile and password. But that opens serious risks. Then it becomes necessary to add auditing and logging, and those need to be done securely -- you couldn't just send a message and write a record to a file since both of those could be tampered with. Tom
    125,585 pointsBadges:
    report
  • HMSSL2K
    You may want to take some basic iSeries class's to get a better understanding of security and system operations from IBM or some other vendor. Like Tom says, "It can't get any more simpler."
    3,175 pointsBadges:
    report
  • JohnsonMumbai
    Tom, You are right it couldnt get any simpler. But since Iam not familiar with API's hence the issue. Can API's be called from CL program.? I guess once i get familiar with handling API's I will be able to overcome the problem. Thanks once again for the inputs. Will revert once i succeed. Johnson
    1,160 pointsBadges:
    report
  • TomLiotta
    ...since Iam not familiar with API’s hence the issue. None of us were familiar with them until we tried to use them. And that's what sites such as ITKE are for -- to ask questions when you get stuck. Can API’s be called from CL program.? Sure. Why not? They're programs and procedures like everything else. Here is very basic code that accepts a user profile and switches the job to run under that profile. It returns handles for the original profile and the new current profile so they can be used later to return the job back to the original and to delete the handles:
    pgm    ( +
             &pUsrPrf    +
             &ph_Prf1    +
             &ph_Prf2    +
           )
    
       dcl   &pUsrPrf     *char   10
       dcl   &ph_Prf1     *char   12
       dcl   &ph_Prf2     *char   12
    
    
       dcl   &ToUsrPrf    *char   10
       dcl   &Pwd         *char   10     value( '*NOPWD' )
       dcl   &CurUsrPrf   *char   10
       dcl   &SecPwd      *char   10     value( '*NOPWD' )
       dcl   &h_Prf1      *char   12
       dcl   &h_Prf2      *char   12
    
    
    /* Get the current *usrprf...                              */
       rtvjoba     curuser( &CurUsrPrf )
    
    /* Get the *usrprf to emulate...                           */
       chgvar           &ToUsrPrf              &pUsrPrf
    
    /* Generate profile handles for the current user ID and    */
    /* for the user ID passed to this program...               */
    
       call       QSYGETPH      ( +
                                  &CurUsrPrf         +
                                  &SecPwd            +
                                  &h_Prf1            +
                                )
    
       call       QSYGETPH      ( +
                                  &ToUsrPrf          +
                                  &Pwd               +
                                  &h_Prf2            +
                                )
    
    /* Now, switch job CurrentUser to new user handle...       */
    
       call       QWTSETP       ( &h_Prf2   )
    
    
    /* We're now running under the &ToUsrPrf. Send handles out */
    /* so we can switch back later and release the handles...  */
    
       chgvar           &ph_Prf1               &h_Prf1
       chgvar           &ph_Prf2               &h_Prf2
    
       return
    
    endpgm
    The program should be compiled as USRPRF(*OWNER) and owned by a *SECOFR class user. It should also be secured so that it can only be called when appropriate. You might compile it as a module for a service program. Include a second module to switch back and clean up the handles. This code calls the Get Profile Handle (QSYGETPH) API twice to get the handles and the Set Profile Handle (QWTSETP, QsySetToProfileHandle) API once to do the switch. You'd create a second program (or module) that called QWTSETP once to switch back and the Release Profile Handle (QSYRLSPH, QsyReleaseProfileHandle) API twice to release the two handles. The programs need to run under (be owned by) a high-authority owner in order to avoid passing passwords around. If you read the API documentation, you'll see how passwords might be used if you want to do it differently. The example should work in most circumstances. It doesn't do anything but call the APIs, so you should add error handling to fit your site's standards. If you work with APIs and have trouble, post example code at this site and ask questions. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Tom, Where is the password stored on iseries can we acces those files and compare the password in the file with the password entered by the user.
    1,160 pointsBadges:
    report
  • TomLiotta
    Where is the password stored on iseries can we acces those files... The system doesn't store passwords in files. They are stored in an internal object that isn't exposed above the MI. While it can technically be accessed and can be decrypted, it must be done through low-level programming and with pretty sophisticated code. An alternative is to run the profile and password through the same encryption/encoding as the system does, and then compare the result against the output from the Retrieve Encrypted User Password (QSYRUPWD) API. That also takes pretty sophisticated code. Such methods can also be sensitive to version/release of the OS as well as changes to the QPWDLVL system value, so multiple code paths are needed. One way to verify a password is simply to use it with the Get Profile Handle (QSYGETPH) API. The user enters a password into your program, and the program calls the API with that password to see if it succeeds in generating a handle or not. (Note that failures will cause an "invalid password" event, and the profile can become disabled just like any other password error.) Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Tom, Was not able to pursue the issue due to year end issues. Now that i am free, i took your code and wrote couple of pgms. Below is the code i have writtern to enable a particular userid, the user id and password is input on the display screen and thereafter the following program is run, PGM ( &PWD + &PUSRPRF ) DCL &PUSRPRF *CHAR 10 DCL &PH_PRF1 *CHAR 12 DCL &PH_PRF2 *CHAR 12 DCL &PWD *CHAR 10 DCL &TOUSRPRF *CHAR 10 DCL &CURUSRPRF *CHAR 10 DCL &SECPWD *CHAR 10 VALUE(*NOPWDCHK) DCL &H_PRF1 *CHAR 12 VALUE(' ') DCL &H_PRF2 *CHAR 12 VALUE(' ') /* GET THE CURRENT *USRPRF */ DCL &PWD *CHAR 10 DCL &TOUSRPRF *CHAR 10 /* DCL &PWD *CHAR 10 VALUE(*NOPWD) */ DCL &CURUSRPRF *CHAR 10 DCL &SECPWD *CHAR 10 VALUE(*NOPWDCHK) DCL &H_PRF1 *CHAR 12 VALUE(' ') DCL &H_PRF2 *CHAR 12 VALUE(' ') /* GET THE CURRENT *USRPRF */ RTVJOBA CURUSER( &CURUSRPRF ) /* GET THE *USRPRF TO EMULATE */ CHGVAR &TOUSRPRF &PUSRPRF /* GENERATE PROFILE HANDLES FOR THE CURRENT USER ID AND */ /* FOR THE USER ID PASSED TO THIS PROGRAM */ CALL PGM(QSYGETPH) PARM(&CURUSRPRF &SECPWD &H_PRF1) MONMSG MSGID(CPF3C3C) /* GET THE *USRPRF TO EMULATE */ CHGVAR &TOUSRPRF &PUSRPRF /* GENERATE PROFILE HANDLES FOR THE CURRENT USER ID AND */ /* FOR THE USER ID PASSED TO THIS PROGRAM */ CALL PGM(QSYGETPH) PARM(&CURUSRPRF &SECPWD &H_PRF1) MONMSG MSGID(CPF3C3C) CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) MONMSG MSGID(CPF3C3C) CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) MONMSG MSGID(CPF3C3C) /* NOW, SWITCH JOB CURRENTUSER TO NEW USER HANDLE */ CALL PGM(QWTSETP) PARM( &H_PRF2) /* WE RE NOW RUNNING UNDER THE &TOUSRPRF. SEND HANDLES OUT */ /* SO WE CAN SWITCH BACK LATER AND RELEASE THE HANDLES */ CHGVAR &PH_PRF1 &H_PRF1 CHGVAR &PH_PRF2 &H_PRF2 CPF9872) */ /* NOW, SWITCH JOB CURRENTUSER TO NEW USER HANDLE */ CALL PGM(QWTSETP) PARM( &H_PRF2) /* WE RE NOW RUNNING UNDER THE &TOUSRPRF. SEND HANDLES OUT */ /* SO WE CAN SWITCH BACK LATER AND RELEASE THE HANDLES */ CHGVAR &PH_PRF1 &H_PRF1 CHGVAR &PH_PRF2 &H_PRF2 CALL PGM(QWTSETP) PARM( &H_PRF1) CALL PGM(QSYGETPH) PARM(&CURUSRPRF &SECPWD &H_PRF1) MONMSG MSGID(CPF3C3C) CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) MONMSG MSGID(CPF3C3C) CALL PGM(QSYGETPH) PARM(&CURUSRPRF &SECPWD &H_PRF1) MONMSG MSGID(CPF3C3C) CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) MONMSG MSGID(CPF3C3C) ENDPGM I however get the following error in the dump once i run the program, Value for parameter 2 not valid QSYGETPH ProfileHandle is not valid QSYPHDL Below is the value that appears in parameter 2 &H_PRF1 *CHAR 12 ' m & ª>^ ' I hope you can understand the problem iam facing. Awaiting your revert.
    1,160 pointsBadges:
    report
  • TomLiotta
    I however get the following error in the dump once i run the program, Value for parameter 2 not valid QSYGETPH ProfileHandle is not valid QSYPHDL Now that you have a little experience with the API, here's the trick: From the Get Profile Handle (QSYGETPH) API documentation:
    • To obtain a profile handle for a profile that is disabled, specify *NOPWDCHK for the password parameter.
    That means that you can't directly use the supplied password to get a profile handle for a disabled profile. You need to go by a slightly indirect route. Change the first part of your code to something like this:
    /* GET THE *USRPRF TO EMULATE */
    CHGVAR &TOUSRPRF &PUSRPRF
    
    chgusrprf  &TOUSRPRF  status( *ENABLED )
    
    /* GENERATE PROFILE HANDLES FOR THE  */
    /* FOR THE USER ID PASSED TO THIS PROGRAM */
    CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF1)
    MONMSG MSGID( CPF22E2 )  exec(  +
             chgusrprf  &TOUSRPRF  status( *DISABLED ) )
    
    /* NOW, release the HANDLE */
    CALL PGM( QSYRLSPH ) PARM( &H_PRF1 x'0000000000000000' )
    
    return
    endpgm
    The idea is that you enable the profile first, then see if you can generate a handle using the password. If the password works, then all is well. If the password is incorrect, then the MONMSG CPF22E2 tells you that the profile needs to be back at *DISABLED status. Actually, the MONMSG would be better as:
    MONMSG MSGID( CPF0000 MCH0000 )  exec(  +
             chgusrprf  &TOUSRPRF  status( *DISABLED ) )
    Any error at all should leave the profile back at *DISABLED status. Then release any handle that was generated and that's all there is. It's not necessary to swap. All you want to do is see if the supplied password is accepted for that profile. If it's accepted, the profile is enabled. If it causes an error, the profile is back to being disabled. You should also create a logging mechanism. The simplest would be a secured message queue. At the very start of the program, send a message to that queue to log the attempt to enable profile &PUSRPRF. The message will timestamp itself. You might also send an additional message every time an attempt fails. You might not need anything more than that to start and it can be expanded in the future. Programs such as this should be written in ILE CL and have all observability removed -- no debug info should be left in the program when it is in production. There are much better ways to get it done, but this is simple, straightforward, easy to understand and about as fool-proof as it gets without some detailed effort. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Tom, While i have changed the code as recommended by you, and the TOUSRPRF id gets enabled however when an invalid password is passed, this is not getting trapped using the MONMSG MSGID( CPF22E2 ) exec(chgusrprf &TOUSRPRF status( *DISABLED ) ). Hence even if user enters Invalid password the id does not revert back to disabled. What could be the reason?. I meanwhile continue to get the following errors which can be bypassed using MONMSG. Value for parameter 2 not valid QSYGETPH Error code parameter not valid QSYRLSPH Parameter 2 appears as below &H_PRF1 *CHAR 12 ' m ¥I»Ð° '
    1,160 pointsBadges:
    report
  • TomLiotta
    What could be the reason?. The first reason would be that CPF22E2 isn't the error being returned from QSYGETPH on your system. That's why I suggested that the code would be better with MONMSG MSGID( CPF0000 MCH0000 ) in order to catch every error no matter what it was. It might be useful if you showed what error was returned from QSYGETPH when an incorrect password was entered. If an error is returned other than CPF22E2, you could simply add that error ID to the MONMSG. But you'd still be better just catching all CPF and MCH errors. A second reason might be that the CALL to QSYGETPH was coded with an error code parameter. The error identifier would be passed through that parameter and not seen by MONMSG. Please show the CALL and the MONMSG commands used in your program. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    The call statement is CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) and the error that appears is 'Value for parameter 2 is invalid' and ' Function check. CPF3C3C unmonitored by OPIAPI' Parameter 2 appears as shown below in the dump &H_PRF1 *CHAR 12 ' m k , Ø ' We need to overcome this error inorder for the incorrect password error to get trapped. The error code for incorrect password is as mentioned by you ie CPF22E2. Johnson
    1,160 pointsBadges:
    report
  • TomLiotta
    CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF2) Note that the modified code doesn't need &H_PRF2. The call should be using &H_PRF1. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Error continues to be the same even if i change the variable to &H_PRF1. Below is the call command being used. CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF1) Value for parameter 2 not valid. Function check. CPF3C3C Unmonitored by OPIAPI The value is displayed as blank. Why is it? &H_PRF1 *CHAR 12 ' ' Johnson
    1,160 pointsBadges:
    report
  • TomLiotta
    CALL PGM(QSYGETPH) PARM(&TOUSRPRF &PWD &H_PRF1) Since this variation is actually using a password value, Make these changes:
       dcl   &ErrCode     *char    8     value( x'0000000000000000' )
       dcl   &lPwd        *int           value( 10 )
       dcl   &CCSID       *int           value( -1 )
    .
    .
    .
       call       QSYGETPH      ( +
                                  &TOUSRPRF          +
                                  &PWD               +
                                  &h_Prf1            +
                                  &ErrCode           +
                                  &lPwd              +
                                  &CCSID             +
                                )
    Parameter 2 can be either a "special value" such as '*NOPWDCHK' or an actual password. Your code attempts to use an actual password to see if it works. When actual passwords are used, the API needs to know the length of the password and the CCSID to use. Also, when those optional parms are added at the end, the error code parameter needs to be specified because it's in the parameter list before the last two parms. The value I chose for &lPwd is 10. That works for systems with system value QPWDLVL of '0' or '1'. If longer passphrases are in use, then the actual length of the password needs to be determined. The value for &CCSID that I used is (-1). That should work for a lot of systems, but you might need to use (0) or you might need an actual CCSID value. An actual CCSID value will take a little extra work. The value for &ErrCode is 8 bytes of binary zeros. That covers the first two fields of the error code structure and tells the API that errors should be returned as *ESCAPE messages. That's the same behavior that happens when the parameter is omitted. If you review the documentation for the API, you should be able to match everything up. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    The value for &ErrCode is 8 bytes of binary zeros. How do i define binary zeros in CL. When i use following code DCL &ERRCODE *CHAR 8 VALUE('00000000') i get the following error. CPF3CF1 40 ESC Error code parameter not valid. Johnson
    1,160 pointsBadges:
    report
  • TomLiotta
    How do i define binary zeros in CL. Use the example that I supplied. Specify binary zeros as hex values -- value( x’0000000000000000′ ). Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Thanks Tom for guiding me through this. Appreciate your patience. It worked. Now only issue is convincing the security team to get it implemented, as they need to ensure this is not picked up as a security issue during internal, external and statutory audit that our IT department needs to undergo every year. Johnson
    1,160 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