One more update to this for now. But first, I want to commend the 389 team once more for all their work.
My never-ending bull-headed nature kept me poking around on this. I found that I can do another ldapmodify, and in dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config I can add nsDS5ReplicaReferral: ldaps://<server>:636..... Which overrides nsslapd-referral (reference for that: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference) And - yes, that eliminated my "Operation requires a secure connection" error. But I got a new one: "Anonymous Binds are not allowed" Welp, I dove into that rabbit hole and found an 8-year-old issue for SSSD (https://pagure.io/SSSD/sssd/issue/1836) where they wanted to address pw change requests by binding as the user trying to change their password. But they closed that issue as WontFix a year ago. However, I then found that I can set " ldap_chpass_uri" and point it to the suppliers. And that works. From: "Collins, Brian (CAI - Atlanta)" <[email protected]> Reply-To: "General discussion list for the 389 Directory server project." <[email protected]> Date: Friday, July 2, 2021 at 10:30 AM To: "discussion list for the 389 Directory server project." <[email protected]> Subject: [389-users] Re: Replica's nsslapd-referral uri is ldap: instead of ldap: Once a backend/suffix is replicated, the replication plugin apparently controls the referrals on the backends (which makes sense). I'm not sure why we don't honor the agreement's configuration. There could be a good reason for it, but we need to look into it closer... FYI: Indeed, and in this case the explicitly set referrals should then be configured in the replica config entry using nsds5ReplicaReferral attribute. If this attribute does not exist then automatic referrals computed from the RUV. IMHO the reason we don't honor the agreement's configuration is that the RUV elements are generated on their specific supplier (which does not have the agreement toward itself) That said, I think that if a supplier provides ldaps port, it should generate an ldaps url in the RUV rather than an ldap one. Thanks for that, Pierre. I was seeing exactly that: the RUV elements (in cockpit) I assume correspond with nsslapd-referral values in dse.ldif. Not sure whether that's helpful, but it sure baffled me. Thanks again for the help! From: Mark Reynolds <[email protected]><mailto:[email protected]> Reply-To: "General discussion list for the 389 Directory server project." <[email protected]><mailto:[email protected]> Date: Friday, July 2, 2021 at 9:00 AM To: "Collins, Brian (CAI - Atlanta)" <[email protected]><mailto:[email protected]>, "General discussion list for the 389 Directory server project." <[email protected]><mailto:[email protected]> Subject: [389-users] Re: Replica's nsslapd-referral uri is ldap: instead of ldap: On 7/2/21 8:35 AM, Collins, Brian (CAI - Atlanta) wrote: Thanks for the quick reply, Mark. Also, thank you to you and the folks at Red Hat for all the work in the newer releases. Two things stand out: dsconf and not having to run X. There is much more, but those two are a great benefit. Thanks, that's nice to hear! Wait until the UI rewrite is done ;-) So I executed the following, named fixreferral.ldif dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsslapd-referral nsslapd-referral: ldaps://auth01.example.com:636/dc%3Dexample%2Cdc%3Dcom nsslapd-referral: ldaps://auth02.example.com:636/dc%3Dexample%2Cdc%3Dcom Using: ldapmodify -x -D "cn=Directory Manager" -W -H ldaps://auth04 -f fixreferral.ldif Then issued: systemctl restart dirsrv@auth04 When I checked, however, it had reverted to: # grep nsslapd-referral dse.ldif nsslapd-referral: ldap://auth01.example.com:389/dc%3Dexample%2Cdc nsslapd-referral: ldap://auth02.example.com:389/dc%3Dexample%2Cdc BUT... dse.ldif.startOK has this: nsslapd-referral: ldaps://auth01.example.com:636/dc%3Dexample%2Cd nsslapd-referral: ldaps://auth02.example.com:636/dc%3Dexample%2Cd So it would appear to be reverting AFTER the restart. Which makes me think it's something that it is receiving from the supplier possibly? Ugh, so the replication plugin is probably rewriting it. Odd that it "worked" in 1.3.x because I don't recall any changes around referrals in a long time. We will need investigate it. Can you open a github issue describing the issue, and how it's blocking password updates? https://github.com/389ds/389-ds-base/issues/new/choose<https://urldefense.com/v3/__https:/github.com/389ds/389-ds-base/issues/new/choose__;!!Gh9pqc0J0AYYLQ!c-sQ54m9S8ingFdnckT8B6YSqccEdtmt_-nUXmAlk3vcKslQ0DOAmui3sCF6ylQlj2VxhA$> Thanks, Mark Thanks again, Brian From: Mark Reynolds <[email protected]><mailto:[email protected]> Date: Thursday, July 1, 2021 at 8:22 PM To: "General discussion list for the 389 Directory server project." <[email protected]><mailto:[email protected]>, "Collins, Brian (CAI - Atlanta)" <[email protected]><mailto:[email protected]> Subject: Re: [389-users] Replica's nsslapd-referral uri is ldap: instead of ldap: Hi Brian, You can just change nsslapd-referral attribute to use ldaps instead of ldap. Now you "should" be able to do that in the console, but I just found out that there is a bug in the console where we don't actually grab the referrals from the mapping tree entry. <sigh> Glad I found it now because the cockpit console is going through a rewrite (to migrate to Patternfly 4). So I will fix that, but it doesn't help you today. So for now you will need to use ldapmodify to change the nsslapd-referral attribute. I would say to use dsconf but it is also broken for properly setting referrals <sigh again>. Once I fix dsconf it would work like this: #dsconf slapd-supplier1 backend suffix set userroot --del-referral ldap://localhost:636 #dsconf slapd-supplier1 backend suffix set userroot --add-referral ldaps://localhost:636 Right now dsconf updates the referral on the wrong entry :-( We'll get this all fixed up! HTH, Mark On 7/1/21 6:04 PM, Collins, Brian (CAI - Atlanta) wrote: Good day, I am doing prep work for replacing our older 389 servers (1.3.8) running on RHEL 7 with newer ones on RHEL 8 and 1.4.4. I have the two RHEL 7 boxes in a multi-master replication setup. For this phase of testing I have one read-only replica on 1.4.4, as a consumer to the two current servers. I set up a Linux client to login using SSSD, bound to the consumer. It works fine except when I want to change passwords. I was getting "Operation requires a secure connection." After a lot of digging, I think I found the culprit there: on the consumer, in "dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" the nsslapd-referral uri for my two current servers is ldap: instead of ldaps:. Indeed, in the cockpit console, the Remote RUV list shows both servers as ldap:. But on the two suppliers, the old servers, the referral uri is ldaps. When I set up the replication agreement for the new consumer, I did it just as I did for the current setup, so I don't feel like that's where I went wrong. Thanks in advance for any pointers, Brian Collins _______________________________________________ 389-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1vE8XadpQ$> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines<https://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guidelines__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1s_zfh7yQ$> List Archives: https://lists.fedoraproject.org/archives/list/[email protected]<https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/[email protected]__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1ulQDpt-g$> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure<https://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure__;!!Gh9pqc0J0AYYLQ!acgEtZI1lyx3IQWOaMl40o5Te2xTGdhdalnHzWGiKuCdjfAIRLeaFR6hg0IeC1vN_sCmBg$> -- Directory Server Development Team -- Directory Server Development Team _______________________________________________ 389-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeclPEITIeA$> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines<https://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guidelines__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEecnnHa1F-w$> List Archives: https://lists.fedoraproject.org/archives/list/[email protected]<https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/[email protected]__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeckywgc36Q$> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure<https://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeckEMRbBVw$> -- Directory Server Development Team _______________________________________________ 389-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://urldefense.com/v3/__https:/docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeclPEITIeA$> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines<https://urldefense.com/v3/__https:/fedoraproject.org/wiki/Mailing_list_guidelines__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEecnnHa1F-w$> List Archives: https://lists.fedoraproject.org/archives/list/[email protected]<https://urldefense.com/v3/__https:/lists.fedoraproject.org/archives/list/[email protected]__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeckywgc36Q$> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure<https://urldefense.com/v3/__https:/pagure.io/fedora-infrastructure__;!!Gh9pqc0J0AYYLQ!a_yd7GJhuG03wtOj-ArBYsQdZSJLu3CihEYdPS78aGQiwhK3AoK6Dl1TJvOEeckEMRbBVw$> -- -- 389 Directory Server Development Team
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
