Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1766002[details]
customer script to set TokenPolicy
Description of problem:
Issue 1) TPS version 8 set a tokenPolicy: entry into the database for each token when it was created by the system, but TPS 9 does not appear to do so.
Issue 2) TPS Version 8 would reset the PIN_RESET=YES value back to PIN_RESET=NO after a Pin reset was executed (Or I believe that it did as the TPS 8 is no longer connected so can't confirm) The Comments in the CS.cfg State "If Present and agent changes PIN_RESET from NO to YES, User is allowed to do pin reset. This policy will be changed back to NO after pin reset" so would expect the system to set it back, but based on looking at the dogtag source code did not see anything setting the tokenPolicy, and based on testing different values of PIN_RESET and PIN_RESET_TO_NO have not found a combination that results in the PIN_RESET=YES being set back to PIN_RESET=NO. Only location in the source where I found PIN_RESET_TO_NO being exercised looked to be in the tps-client.
Issue 3) Even if I add tokenPolicy: to tokens by adjusting the tokenAdmin.py script to set the policy, when a token goes through its lifecycle of use from new -> formated -> enrolled -> terminated -> reuse the tokenPolicy is cleared when the token is marked for reuse removing the tokenPolicy.
Our TPS does not appear to be applying the tokendb.defaultPolicy to tokens, and the op.enroll.x.pinReset.enable=true or op.enroll.x.pinReset.enable=false do not appear to be updating the policy.
Version-Release number of selected component (if applicable):
RHCS 9.x
How reproducible:
Very
Steps to Reproduce:
1. Issue token
2. Also after formatting token
Actual results:
No default tokenpolicy is set.
Expected results:
TPS Version 8 would reset the PIN_RESET=YES value back to PIN_RESET=NO after a Pin reset was executed (Or I believe that it did as the TPS 8 is no longer connected so can't confirm) The Comments in the CS.cfg State "If Present and agent changes PIN_RESET from NO to YES, User is allowed to do pin reset. This policy will be changed back to NO after pin reset" so would expect the system to set it back
Additional info:
Attached is the Python script that we use to automate the Token Addition process to the TPS. It is a pretty much a pexpect wrapper to enter HSM, and nssdb passwords. around the pki cli to execute pki tps-token-add commands with a formatted Feed file. The feed file used by this version is similar to the following
534E065011112222333,3,4
First part of CUID up to where the CUID becomes unique, rest of first CUID in Range, rest of last CUID in range.
This Line would add tokens 524E-0650-1111-2222-3333 through 534E-0650-1111-2222-3334
Based on looking at the pki cli I can add --policy "PIN_RESET=NO;RE_ENROLL=NO;PIN_RESET_TO_NO=YES " to my tokenAdmin.py script to set the Policy by Default.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (pki-core bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:2315
Created attachment 1766002 [details] customer script to set TokenPolicy Description of problem: Issue 1) TPS version 8 set a tokenPolicy: entry into the database for each token when it was created by the system, but TPS 9 does not appear to do so. Issue 2) TPS Version 8 would reset the PIN_RESET=YES value back to PIN_RESET=NO after a Pin reset was executed (Or I believe that it did as the TPS 8 is no longer connected so can't confirm) The Comments in the CS.cfg State "If Present and agent changes PIN_RESET from NO to YES, User is allowed to do pin reset. This policy will be changed back to NO after pin reset" so would expect the system to set it back, but based on looking at the dogtag source code did not see anything setting the tokenPolicy, and based on testing different values of PIN_RESET and PIN_RESET_TO_NO have not found a combination that results in the PIN_RESET=YES being set back to PIN_RESET=NO. Only location in the source where I found PIN_RESET_TO_NO being exercised looked to be in the tps-client. Issue 3) Even if I add tokenPolicy: to tokens by adjusting the tokenAdmin.py script to set the policy, when a token goes through its lifecycle of use from new -> formated -> enrolled -> terminated -> reuse the tokenPolicy is cleared when the token is marked for reuse removing the tokenPolicy. Our TPS does not appear to be applying the tokendb.defaultPolicy to tokens, and the op.enroll.x.pinReset.enable=true or op.enroll.x.pinReset.enable=false do not appear to be updating the policy. Version-Release number of selected component (if applicable): RHCS 9.x How reproducible: Very Steps to Reproduce: 1. Issue token 2. Also after formatting token Actual results: No default tokenpolicy is set. Expected results: TPS Version 8 would reset the PIN_RESET=YES value back to PIN_RESET=NO after a Pin reset was executed (Or I believe that it did as the TPS 8 is no longer connected so can't confirm) The Comments in the CS.cfg State "If Present and agent changes PIN_RESET from NO to YES, User is allowed to do pin reset. This policy will be changed back to NO after pin reset" so would expect the system to set it back Additional info: Attached is the Python script that we use to automate the Token Addition process to the TPS. It is a pretty much a pexpect wrapper to enter HSM, and nssdb passwords. around the pki cli to execute pki tps-token-add commands with a formatted Feed file. The feed file used by this version is similar to the following 534E065011112222333,3,4 First part of CUID up to where the CUID becomes unique, rest of first CUID in Range, rest of last CUID in range. This Line would add tokens 524E-0650-1111-2222-3333 through 534E-0650-1111-2222-3334 Based on looking at the pki cli I can add --policy "PIN_RESET=NO;RE_ENROLL=NO;PIN_RESET_TO_NO=YES " to my tokenAdmin.py script to set the Policy by Default.