On Mon, Apr 24, 2023 at 03:54:30PM -0400, Rob Crittenden via FreeIPA-users wrote:
Sam Morris wrote:
> On Mon, Apr 24, 2023 at 12:07:16PM -0400, Rob Crittenden via FreeIPA-users wrote:
>>> 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...
>> , and there don't appear to be any. This is fine.
>>
>> I don't think you need to do anything here.
>
> But here's what I see from ds-replcheck:
>
> $ ds-replcheck -v state -Z /etc/ipa/nssdb -m ldap://ipa0.ipa.example.com:389 -r
ldap://ipa1.ipa.example.com:389 -D
uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com -w ... -b o=ipaca
> Connecting to servers...
> Validating suffix ...
> Gathering Supplier's RUV...
> Error: Supplier does not have an RUV entry
>
> That error is caused by the tombstone search returning no entries. But
> with the directory manager, I get:
>
> $ ds-replcheck -v state -Z /etc/ipa/nssdb -m ldap://ipa0.ipa.example.com:389 -r
ldap://ipa1.ipa.example.com:389 -D cn='Directory Manager' -W -b o=ipaca
> Enter password:
> Connecting to servers...
> Validating suffix ...
> Gathering Supplier's RUV...
> Gathering Replica's RUV...
> Getting Supplier's replica ID
> Replication State: Supplier and Replica are in perfect synchronization
>
> Hence I figured I needed to add some ACIs somewhere. But the ones I've
> tried adding to 'cn=mapping tree,cn=config' aren't sufficient.
>
> Here's the search that I think ds-replcheck is doing:
>
> $ 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
> # extended LDIF
> #
> # LDAPv3
> # base <o=ipaca> with scope subtree
> # filter:
(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))
> # requesting: nsds50ruv
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> ... and here it is, run as the directory manager:
>
> # ldapsearch -LLL -o ldif-wrap=no -s sub -b o=ipaca
'(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))'
nsds50ruv
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> nsds50ruv: {replicageneration} 5cb8bedf000000060000
> nsds50ruv: {replica 14 ldap://ipa0.ipa.example.com:389} 610ad7470001000e0000
6446aa160000000e0000
> nsds50ruv: {replica 12 ldap://ipa1.ipa.example.com:389} 6082f5e10001000c0000
6446ae080000000c0000
> nsds50ruv: {replica 18 ldap://ipa2.ipa.example.com:389} 628d6a07000100120000
6446afa4000000120000
>
I don't use this tool so I don't know the details on the searches it
performs. If you can get a quiet LDAP server and run as your bind user
and Directory Manager and provide the access logs we can try to figure
out what is going on.
Sure, here's the command used:
$ ds-replcheck -v state -Z /etc/ipa/nssdb -m ldap://ipa0.ipa.example.com:389 -r
ldap://ipa1.ipa.example.com:389 -D DN -w PASSWORD -b o=ipaca
Here are the logs when running it using the root DN:
[25/Apr/2023:08:09:38.547193776 +0000] conn=1529 op=1 BIND dn="cn=Directory
Manager" method=128 version=3
[25/Apr/2023:08:09:38.547501267 +0000] conn=1529 op=1 RESULT err=0 tag=97 nentries=0
wtime=0.010675418 optime=0.000343664 etime=0.011014089 dn="cn=directory
manager"
[25/Apr/2023:08:09:38.556818128 +0000] conn=1529 op=2 SRCH base="o=ipaca"
scope=0 filter="(objectClass=*)" attrs=ALL
[25/Apr/2023:08:09:38.557355407 +0000] conn=1529 op=2 RESULT err=0 tag=101 nentries=1
wtime=0.000350868 optime=0.000545608 etime=0.000878460
[25/Apr/2023:08:09:38.558868700 +0000] conn=1529 op=3 SRCH base="cn=config"
scope=2 filter="(&(objectClass=nsds5replica)(nsDS5ReplicaRoot=o=ipaca))"
attrs=ALL
[25/Apr/2023:08:09:38.561344851 +0000] conn=1529 op=3 RESULT err=0 tag=101 nentries=1
wtime=0.000338392 optime=0.002481952 etime=0.002814677
[25/Apr/2023:08:09:38.565951829 +0000] conn=1529 op=4 SRCH base="o=ipaca"
scope=2
filter="(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))"
attrs="nsds50ruv"
[25/Apr/2023:08:09:38.567222484 +0000] conn=1529 op=4 RESULT err=0 tag=101 nentries=1
wtime=0.000293867 optime=0.001279436 etime=0.001568497
[25/Apr/2023:08:09:38.574172428 +0000] conn=1529 op=5 UNBIND
... and with my repl-mon user:
[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
It's the 3rd query for the tombstone object's nsds50ruv attribute that
returns nothing when run as repl-mon.
Either my ACIs are wrong, or there's something funky about how the
tombstone query works; note that the search base is o=ipaca, but the DN
of the entry in the result is not within o=ipaca:
[root@ipa0 ~]# ldapsearch -Q -LLL -o ldif-wrap=no -s sub -b o=ipaca
'(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))'
nsds50ruv
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds50ruv: {replicageneration} 5cb8bedf000000060000
nsds50ruv: {replica 14 ldap://ipa0.ipa.example.com:389} 610ad7470001000e0000
64478b160000000e0000
nsds50ruv: {replica 12 ldap://ipa1.ipa.example.com:389} 6082f5e10001000c0000
64478b840000000c0000
nsds50ruv: {replica 18 ldap://ipa2.ipa.example.com:389} 628d6a07000100120000
64478293000000120000
--
Sam Morris <
https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9