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

Use the example that I supplied. Specify binary zeros as hex values — value( x’0000000000000000′ ).

Tom

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

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

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

Note that the modified code doesn’t need &H_PRF2. The call should be using &H_PRF1.

Tom

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

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

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

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