8:43 a.m.
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 :-|
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.
12:33 a.m.
New subject: Antw: [EXT] creatorsname not correctly updated
>> <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.
4:02 a.m.
New subject: Antw: [EXT] creatorsname not correctly updated
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.
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.
>
>
>
>
7:17 a.m.
New subject: Antw: [EXT] creatorsname not correctly updated
>> 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.
>
>
>
>
6:44 a.m.
New subject: Antw: [EXT] creatorsname not correctly updated
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.
>>
>>
>>
>>
2:08 p.m.
New subject: Antw: [EXT] creatorsname not correctly updated
--On Thursday, March 10, 2022 3:44 PM +0100 Jean-Luc Bourguignon
<bourguijl(a)gmail.com> wrote:
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.
What OpenLDAP release are you using?
--Quanah
376
days inactive
378
days old
openldap-technical@openldap.org
5 comments
4 participants
participants (4)
-
bourguijl＠gmail.com -
Jean-Luc Bourguignon
-
Quanah Gibson-Mount -
Ulrich Windl