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(a)rz.uni-regensburg.de> wrote:
>>> Jean-Luc Bourguignon <bourguijl(a)gmail.com> schrieb
am 09.03.2022 um
13:02
in
Nachricht <FC120422-779E-42EC-B7F3-3EF1E817A61F(a)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(a)rz.uni-regensburg.de>
> wrote:
>
>>>>> <bourguijl(a)gmail.com> schrieb am 08.03.2022 um 17:43 in
Nachricht
>> <20220308164344.5262.14565(a)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.
>>
>>
>>
>>