Hello Ulrich,

After a deep analyze of this "problem", it seems the chaining process doesn't work when I use rootdn user to add entries in the DB via the replicas.
If I add them via providers, creatorsname takes the correct rootdn (as no chaining action here) but if I do it via replicas, I get replication user's DN.
The chaining process works fine for normal users and gets proxied from replicas to providers as I've authzto (regex) rules in the configuration of  my replication user.
I've tried to add a second authzto rule to my replication user as authzto {1} dn.exact: cn="rootdn" but it didn't work. Besides that, I created a fake rootdn entry in my DB, but same result.

My aim is to have the correct DN name in creatorsname when I use rootdn to add entries via replicas.
I suppose there should be the possibility to "keep" this rootdn creator name to be written in the creatosname attribute.

In fact I noticed this "issue" because I enable "auditlog" overlay.

Thx for your help.

Brgds,
J-L.


On Wed, Mar 9, 2022 at 4:17 PM Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>> Jean-Luc Bourguignon <bourguijl@gmail.com> schrieb am 09.03.2022 um 13:02
in
Nachricht <FC120422-779E-42EC-B7F3-3EF1E817A61F@gmail.com>:
> Hello Ulrich,
>
> I’ve to correct the information I gave at start of the tread. After
> investigation and some corrections on the 2MMR env, both environment gave me

> same result now.
>
> In fact, I’ve proxy configuration on this replication user which works fine

> for a normal user that add entries in the DB, creatosname is its name, but
> when I use the rootdn user, it’s the replication user is stored in
> creatorsname. I’ve added another rule authzTo rule in the replication user
> for the rootdn user but it doesn’t help to get entries created by him with
> his name in creatorsname attribut.

Hi!

Here I have "olcAccess: {0}to * by
dn.exact="uid=syncrepl,ou=system,dc=...,dc=de" read ..." for the syncrepl user
(no proxying).
Out of curiosity: Is only the creatorsName different, but also the
CreationTime?
Also If the objects are not re-created and you use deltasyncrepl, the
creatorsName probably wouldn't be updated until the objects is actually created
new (meaning: It won't fix existing inconsistencies)

What about modifiersName and modifyTimestamp?

Regards,
Ulrich


>
> Brgds,
> Jean-Luc
>
> On 9 Mar 2022, at 09:33, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
> wrote:
>
>>>>> <bourguijl@gmail.com> schrieb am 08.03.2022 um 17:43 in Nachricht
>> <20220308164344.5262.14565@hypatia.openldap.org>:
>>> Dears,
>>>
>>> I've a tricky issue with this attribute.
>>> I context of 4 MMR & 4 replicas, I've defined a rootdn and a replication
>>> user. When I create "ADD" a new entry in my DB with rootdn as user, the
>>> creatorsname is filled up with the replication username instead of rootdn

> one
>>> :-|
>>
>> Are you sure your replication user can read all attributes?
>>
>>> I've another configuration with 2 MMR & 2 replicas, normally same config
as
>>> above, but there, the ADD is correctly managed.
>>> In both configuration, replicas send their ADD request to masters VIP with

>>> olcUpdateRef attribut. and received update via masters VIP with
olcSyncrepl
>>> attribut.
>>>
>>> Any idea of any parameter, acl, schema to check ?
>>>
>>> Thx,
>>> J-L.
>>
>>
>>
>>