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
Thanks,
Mark
Thanks again,
Brian
*From: *Mark Reynolds <[email protected]>
*Date: *Thursday, July 1, 2021 at 8:22 PM
*To: *"General discussion list for the 389 Directory server project."
<[email protected]>, "Collins, Brian (CAI - Atlanta)"
<[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 <ldap://localhost:636>
#dsconf slapd-supplier1 backend suffix set userroot --add-referral
ldaps://localhost:636 <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 [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]
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
