Description of problem: Account lockout settings changed from cockpit is not set correctly. Uncheck "Lockout Account Forever" in Account Lockout Settings for RHDS, but it will be checked again even if save the settings. Version-Release number of selected component (if applicable): - 389-ds-base-1.4.1.10-1. - cockpit-196.3-1.el8 - cockpit-389-ds-1.4.1.10-1.module+el8dsrv+575+0d8b81fc How reproducible: Always Steps to Reproduce: 1. Install the package to manage RHDS from cockpit # yum install cockpit-389-ds 2. Log in to cockpit UI 3. Click 'Red Hat Directory Server' on Left pane 4. Click the menu in this order: "Server Settings > Password Policy > Global Password Policy" 5. See 'Account Lockout Settings' 6. Check "Enable Account Lockout" 7. Check "Time Until Account Unlocked" and make sure "Lockout Account Forever" is unchecked 8. Press save button at the bottom of the page. Actual results: - "Lockout Account Forever" is checked again after pressing save button. - The attribute passwordUnlock doesn't exist. Expected results: - "Lockout Account Forever" keeps unchecked after ressing save button. - The attribute passwordUnlock is set to on.
cockpit-389-ds is built by the 389-ds project, so reassigning.
This was fixed in the upcoming RHDS 11.1 build: cockpit-389-ds-1.4.2.9-1.module+el8dsrv+6001+1cbc6dcf.noarch When I modify "Do Not Lockout Account Forever", I see that the change also happens on the server side: time: 20200320044359 dn: cn=config result: 0 changetype: modify replace: passwordUnlock passwordUnlock: on - replace: modifiersname modifiersname: cn=Directory Manager - replace: modifytimestamp modifytimestamp: 20200320084359Z - time: 20200320044401 dn: cn=config result: 0 changetype: modify replace: passwordUnlock passwordUnlock: off - replace: modifiersname modifiersname: cn=Directory Manager - replace: modifytimestamp modifytimestamp: 20200320084401Z -
Build tested: cockpit-389-ds-1.4.2.12-1.module+el8dsrv+6328+f04d7471.noarch I see the same behaviour as in comment #2, marking as VERIFIED.
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, 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-2020:1961