When pkispawn logs in in order to create a clone, dogtag creates a session and stores the data in the directory.
Unfortunately this can result into issues logging in as the same user later, because the session object contains a 'uid' attribute with the user name, just like the username object in ou=People and when dogtag tries to check the user's password it will search the directory with a very simple filter (uid=<username>) and will search the whole database suffix. This search filter will match 2 objects, the real user object and the previous session object. Depending on luck (which object is returned first in the LDAP results) then authentication may succeed or fail because dogtag uses the DN of the first result as the user's DN to attempt a simple bind.
Needed for IPA 4.3. The issue is important to fix since in IPA the KRA subtree is inside the CA subtree, so potential conflics will be greater.
According to simo this is blocking IPA 4.3 development.
Fixed in master:
Cherry-picked to DOGTAG_10_2_6_BRANCH:
Cherry-picked to DOGTAG_10_2_BRANCH:
Don't have a reliable reproducer?
Metadata Update from @simo: - Issue assigned to edewata - Issue set to the milestone: 10.3.0
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2139
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.