Sam Morris via FreeIPA-users wrote: > I've created a system account for replication status monitoring: > > uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com > > ... and I've added it to the permissions: > > "cn=Read Replication > Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example,dc=com" permission. > > While this allows the account to fetch info from underneath 'cn=mapping > tree,cn=config', it appears that ds-replcheck(1) insists on fetching the > nsds50ruv attribute from the replicated suffix, which is not granted by > the "Read Replication Agreements" permission. > > Here's the directory server's access log when running 'ds-replcheck > status -b o=ipaca': > > [24/Apr/2023:11:35:34.468602164 +0000] conn=789 op=1 BIND > dn="uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com" method=128 > version=3 > [24/Apr/2023:11:35:34.470810908 +0000] conn=789 op=1 RESULT err=0 tag=97 > nentries=0 wtime=0.020082546 optime=0.002246180 etime=0.022324130 > dn="uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com" > [24/Apr/2023:11:35:34.475518328 +0000] conn=789 op=2 SRCH base="o=ipaca" > scope=0 filter="(objectClass=*)" attrs=ALL > [24/Apr/2023:11:35:34.475918861 +0000] conn=789 op=2 RESULT err=0 tag=101 > nentries=0 wtime=0.000211040 optime=0.000406466 etime=0.000612026 > [24/Apr/2023:11:35:34.477210042 +0000] conn=789 op=3 SRCH base="cn=config" > scope=2 filter="(&(objectClass=nsds5replica)(nsDS5ReplicaRoot=o=ipaca))" > attrs=ALL > [24/Apr/2023:11:35:34.487675914 +0000] conn=789 op=3 RESULT err=0 tag=101 > nentries=1 wtime=0.000248974 optime=0.010471906 etime=0.010715383 > [24/Apr/2023:11:35:34.502207252 +0000] conn=789 op=4 SRCH base="o=ipaca" > scope=2 > filter="(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))" > attrs="nsds50ruv" > [24/Apr/2023:11:35:34.502647379 +0000] conn=789 op=4 RESULT err=0 tag=101 > nentries=0 wtime=0.000333635 optime=0.000446668 etime=0.000773723 > [24/Apr/2023:11:35:34.504273914 +0000] conn=789 op=5 UNBIND > > If I perform these queries manually using my repl-mon user then I see > that the problem is the third search returns nothing.
This is not a problem. The filter is different between the two searches. nsds50ruv is explicitly in the "Read Replication Agreements" permission so it isn't something missing from the ACI. > However, this attribute can be read from the second search! Although > it's not included in the results when 'ALL' attributes are requested, > explicitly adding it to the search query works fine: The third search is looking for tombstone entries, https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/tombstones , and there don't appear to be any. This is fine. I don't think you need to do anything here. rob > > $ ldapsearch -LLL -o ldif-wrap=no -H ldaps://ipa0.ipa.example.com -x -D > uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com -w ... -s sub -b > cn=config '(&(objectClass=nsds5replica)(nsDS5ReplicaRoot=o=ipaca))' '*' > nsds50ruv > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > cn: replica > nsDS5Flags: 1 > nsDS5ReplicaBindDN: cn=replication manager,cn=config > nsDS5ReplicaId: 14 > nsDS5ReplicaName: 11111111-22222222-33333333-44444444 > nsDS5ReplicaRoot: o=ipaca > nsDS5ReplicaType: 3 > nsState:: DgAAAAAAAAA0jUZkAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAAAAAA== > nsds5ReplicaBackoffMax: 300 > nsds5ReplicaLegacyConsumer: off > objectClass: top > objectClass: nsds5replica > objectClass: extensibleobject > nsds5ReplicaChangeCount: 5254 > nsds50ruv: {replicageneration} 5cb8bedf000000060000 > nsds50ruv: {replica 14 ldap://ipa1.ipa.example.com:389} > 610ad7470001000e0000 64468df50000000e0000 > nsds50ruv: {replica 12 ldap://ipa0.ipa.example.com:389} > 6082f5e10001000c0000 644695700000000c0000 > nsds50ruv: {replica 18 ldap://ipa2.ipa.example.com:389} > 628d6a07000100120000 64469383000000120000 > > Is there a particular reason that ds-replcheck(1) doesn't read the > nsds50ruv attribute from 'cn=o\3Dipaca,cn=mapping tree,cn=config' > returned by the 2nd search above (I expect if I knew more about how > replication is implemented the reason would be obvious...) > > I wonder what's the right way I should be doing this? > > * RFE against 389 Directory Server to make ds-replcheck ask for > nsds50ruv in the second search it performs above instead of making a > separate search for it in the replicated suffix's entry? > > * RFE against FreeIPA to make 'Read Replication Agreements' include > whatever ACI makes > the second search above work? > > I can't even figure out the correct aci at the moment. I've added the > following to 'cn=mapping tree,cn=config' (based on > <https://www.spinics.net/linux/fedora/389-users/msg20036.html>) > > aci: (targetattr = "*")(version 3.0;acl "for ds-replcheck"; allow > (read,compare,search) groupdn = "ldap:///cn=Read Replication > Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example,dc=com";) > aci: (targetattr = "*")(version 3.0;acl "for ds-replcheck"; allow > (read,compare,search) userdn = > "ldap:///uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com";;) > > but my user still can't see the nsds50ruv attribute when searching > with: > > $ ldapsearch -H ldaps://ipa0.ipa.example.com -x -D > uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com -w ... -s sub -b > o=ipaca > '(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))' > nsds50ruv > > Maybe because of the funky way that the search base is 'o=ipaca' but > the entry returned in the result (when it works, i.e. when I run it > as 'cn=directory manager') is 'cn=replica,cn=o\3Dipaca,cn=mapping > tree,cn=config'? > > * Write my own ACIs from scratch avoiding using IPA's 'Read Replication > Agreements' permission? If I can get the above to work then I could > do this as well. > > * A better idea? :) > > Regards, > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
