Hi Slawomir,
As you requested, I have tested VERIFY PASSWORD for KDFAES on my development system and it seems to work for me fine. For your convenience, this is the job that was used for this test:
<== Add a valid jobcard for your job here
//CKR EXEC PGM=CKRCARLX
//STEPLIB DD DISP=SHR,DSN= <== Add your steplib name here
// DD DISP=SHR,DSN= <== Add your loadlib name here
//SYSPRINT DD SYSOUT=*
//CKAPWDCT DD DISP=SHR,DSN= <== Add your dictionary data set name here
//CKAPWUSR DD DISP=SHR,DSN= <== Add your user data set name here
//SYSIN DD *
option pl=0
ALLOC TYPE=RACF ACTIVE
VERIFY PASSWORD redo
newlist type=racf
select class=user segment=base key=USERXX
sortlist key(8) pw_default pw_trivial pw_indict
In my system that shows that the pw_indict flag was successfully set to Yes.
This was tested with zSecure version 3.1.0 GA and produced:
P R O F I L E L I S T I N G 28 Sep 2026 15:21
Profile PwD PwT PwI
USERXX No No Yes
When your job completes with an RC=0 and without any error/warning messages written in the SYSPRINT work data set that could provide a clue to what the issue is at hand, I suggest that you open a problem ticket with our zSecure Support team to get this further diagnosed.
Hope this helps, best regards Tom
------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
------------------------------
Original Message:
Sent: 09/25/26 11:12 AM
From: Sławomir Bujniak
Subject: VERIFY PASSWORD REDO
Hi Tom,
Looks like the primary active RACF db is updated - at least for 'trivial' type of passwords (seems this works well) - but still not for 'dictionary' ones. If you find a few minutes on your system could pls try a tests with dictionary and show your a sample if possible.
Thank you
------------------------------
Regards
Sławomir Bujniak
Kyndryl
------------------------------
Original Message:
Sent: 09/25/26 08:28 AM
From: Tom Zeehandelaar
Subject: VERIFY PASSWORD REDO
Hi Slawomir,
OK, so that rules out the UPPERCASEing of the password value as the root cause for this issue.
There are some other documented restrictions:
- It only works when an ACTIVE RACF database has been selected as input source for zSecure Audit. Can you confirm that you use the active RACF database as input?
- Running VERIFY PASSWORD against a password directory with less than 50 entries requires you to have CONTROL access to XFACILIT resource CKR.VERIFY.PASSWORD. Did you check that as well?
If all is well, the VERIFY PASSWORD function writes the flags that are used in the user audit reports PWDFLT (flag field pw_default), PWTRIV (flag field pw_trivial), and PWDICT (flag field pw_indict) as user data entries for affected users. The following sample CARLa reports whether on your system there are any users with a default, trivial, or dictionary password value:
newlist type=racf
select c=user (pw_trivial=yes or pw_default=yes or pw_indict=yes)
sortlist key(8) name pw_trivial pw_default pw_indict
On my test system it produces:
P R O F I L E L I S T I N G 25 Sep 2026 14:21
Profile Name PwT PwD PwI
CRMBGUX GUUSX Yes No No
CRMBGUZ No Yes No
Regards, Tom
------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
------------------------------
Original Message:
Sent: 09/25/26 05:36 AM
From: Sławomir Bujniak
Subject: VERIFY PASSWORD REDO
Hi Tom,
Unfortunately it didnt help me - I have added upper case and low case as well - is it possible to add some addition logs ? e.g DEBUG mode ? or check somehow in RACF db user record ?
Perhaps my process do not update RACF db ad all ??
Thx
------------------------------
Regards
Sławomir Bujniak
Kyndryl
------------------------------
Original Message:
Sent: 09/25/26 04:45 AM
From: Tom Zeehandelaar
Subject: VERIFY PASSWORD REDO
Hi Slawomir,
At first glance I cannot see anything that you have done wrong in your described scenario. I would also have expected the userxx being flagged in the PWDICT user report.
However, there's one thing that I can think off that could cause VERIFY PASSWORD to not flag the password that you fed it in the dictionary data set. For environments where mixed case passwords are enabled, the VERIFY PASSWORD function evaluates the password values in the exact same case as they are entered in the dictionary data set. Could it be that your ALU command uppercased the password for userxx to PASS1234 and that is not a match to pass12234 that you put in the dictionary data set?
I hope this helps,
Regards, Tom
------------------------------
Tom Zeehandelaar
z/OS Security Enablement Specialist - zSecure developer
IBM
------------------------------