Comments on: Is there a way a user who is the owner of is userprf enable is disabled id without logging in to the systemhttp://itknowledgeexchange.techtarget.com/itanswers/is-there-a-way-a-user-who-is-the-owner-of-is-userprf-enable-is-disabled-id-without-logging-in-to-the-system/
Sun, 02 Aug 2015 08:47:57 +0000hourly1By: johnsonmumbaihttp://itknowledgeexchange.techtarget.com/itanswers/is-there-a-way-a-user-who-is-the-owner-of-is-userprf-enable-is-disabled-id-without-logging-in-to-the-system/#comment-91077
Tue, 19 Apr 2011 08:58:19 +0000#comment-91077Thanks 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.

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

]]>By: johnsonmumbaihttp://itknowledgeexchange.techtarget.com/itanswers/is-there-a-way-a-user-who-is-the-owner-of-is-userprf-enable-is-disabled-id-without-logging-in-to-the-system/#comment-90863
Thu, 14 Apr 2011 12:41:11 +0000#comment-90863Error 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?

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.

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.

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»Ð° ‘

]]>By: tomliottahttp://itknowledgeexchange.techtarget.com/itanswers/is-there-a-way-a-user-who-is-the-owner-of-is-userprf-enable-is-disabled-id-without-logging-in-to-the-system/#comment-90585
Fri, 08 Apr 2011 18:47:36 +0000#comment-90585I 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.

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.