Created attachment 1509424 [details] rhds cockpit webui Description of problem: Creating Replication Manager from webui fails if uid=repman is used While creating a replication agreement using webui, If uid=repman is choosed, It fails with error. [28/Nov/2018:04:44:13.449798112 -0500] conn=70 op=8 ADD dn="uid=repman,cn=config" [28/Nov/2018:04:44:13.478054359 -0500] conn=70 op=8 RESULT err=65 tag=105 nentries=0 etime=0.0028324086 - attribute "uid" not allowed cn=repman,cn=config works correctly. This used to work for older version & lot of customers uses uid=<name> syntax. Version-Release number of selected component (if applicable): cockpit-389-ds-1.4.0.19-2.module+el8+1+36e60e1d.noarch 389-ds-base-1.4.0.19-2.module+el8+1+36e60e1d.x86_64 389-ds-base-libs-1.4.0.19-2.module+el8+1+36e60e1d.x86_64 How reproducible: 100% Steps to Reproduce: Login to Cockpit Webui Select Instance Go to replication click on Configuration Add replication manager as uid=<name> Actual results: It should work Expected results: It fails with error=65, Adding screenshot for more clarity Additional info: This was legacy configuration which used to work previously Lot of existing environment uses same convention. It should work for both uid=name & cn=name.
Created attachment 1509425 [details] rhds cockpit webui
Yeah lib389 limits this to just cn for replication managers. I know it will not be easy to change it because of how it's all laid out, but it should be possible.
Upstream ticket: https://pagure.io/389-ds-base/issue/51113
Created attachment 1700605 [details] verification Build tested: 389-ds-base-1.4.2.12-3.module+el8dsrv+6923+6ab1d5c5.x86_64 cockpit-389-ds-1.4.2.12-3.module+el8dsrv+6923+6ab1d5c5.noarch I can now create a Replication Manager's entry using "uid" as the RDN attribute from the WebUI. Also, replication between instances is working fine. 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:3171