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.
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.
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@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.
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.
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.
--On Thursday, March 10, 2022 3:44 PM +0100 Jean-Luc Bourguignon bourguijl@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
openldap-technical@openldap.org
-
bourguijl＠gmail.com -
Jean-Luc Bourguignon
-
Quanah Gibson-Mount -
Ulrich Windl