Re: Antw: [EXT] creatorsname not correctly updated
by Jean-Luc Bourguignon
hello Quanah,
2.5.7.
Brgds,
J-L.
On Thu, Mar 10, 2022 at 11:08 PM Quanah Gibson-Mount <quanah(a)fast-mail.org>
wrote:
>
>
> --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
>
>
>
>
1 year
creatorsname not correctly updated
by bourguijl＠gmail.com
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.
1 year
syncprov olcSpNoPresent not being honoured
by lisa.parratt＠bjss.com
Hi,
I have an OpenLDAP server I'm upgrading from 2.4.58 to 2.6.0. The server is configured with the syncprov plugin, with "olcSpNoPresent: TRUE".
Previously, on 2.4.58, we would never see any Present phase data originating from the server. However, post upgrade, we are seeing this, and it's causing problems with the consumers. I've tried looking at the code, but I must admit I got lost trying to trace through the propagation of this flag.
Are there undocumented circumstances where olcSpNoPresent will not be obeyed, or is this a regression?
Thanks!
Lisa
1 year
how to set LDAP ACL permissions on one subtree for a groups without modifying it for other users or groups?
by International Security Providers
I use commands like this to set permissions for some custom gorups/users.. now I want to set the permissions without overwriting them for all the other groups/users, what do I need to add to my ACL-Entrys?:
```
access to dn.subtree="cn=myContainer,dc=mydomain,dc=tld"
by set="user & [cn=myGroup,cn=groups,dc=mydomain,dc=tld]/uniqueMember*" write
by set="user & [cn=Domain Users,cn=groups,dc=mydomain,dc=tld]/uniqueMember*" read
```
1 year
Delta-sync replication: is it possible to force resync delta?
by skeletor
Hi.
I use delta-sync replication on version 2.4. Sometimes, some records
don't send to slave. Insofar as this is delta-sync after a new update
slave receive only last update. Therefore slave and master are not
consistent. Is it possible run force resync from accesslog to consistent
check if all records are present on slave?
May be this is a bug on version 2.4 and it already has been fixed in
newer version?
master 2.4.57
slave 2.4.55
1 year
disable SSL/TLS renegotiation
by Stefan Bauer
Hi,
our security scanner reports
SSL/TLS: Renegotiation DoS Vulnerability (CVE-2011-1473, CVE-2011-5094) for
port TCP/636.
I could not find a way to disable SSL/TLS renogitation for openldap.
How can this be disabled?
Any help is greatly appreciated.
Thank you.
Stefan
1 year
Problem with ppolicy overlay and userPassword attribute
by Frederic Dussurget
Hi,
We're facing the following issue :
* From one side, we have to store two values (same password with two different encodings) within the userPassword attribute (eg. https://datatracker.ietf.org/doc/html/rfc4519#section-2.41)
* On the other side, we do have to use the ppolicy overlay in order to hash to Argon2 automatically passwords that are sent in cleartext, in order to to use the pwdLastSuccess attribute (storing last authentication date) and pwdAccountLockedTime (account deactivation), but this overlay does not seem to support multiple values in the userPassword attribute as it looks to be described in the following abstract : https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-1... and https://www.openldap.org/software/man.cgi?query=slapo-ppolicy&sektion=5&a...
We're not able to add a user account with two values in the userPassword attribute :
[root@openldap25 ~]# cat testuser_add.ldif
dn: uid=testuser,ou=people,dc=my-domain,dc=fr
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
uid: testuser
cn: testuserCN
sn: testuserSN
userPassword: password
userPassword: drowssap
[root@openldap25 ~]# ldapadd -H ldaps://localhost:636 -x -D "cn=Manager,dc=my-domain,dc=fr" -W -f testuser_add.ldif
Enter LDAP Password:
adding new entry "uid=testuser,ou=people,dc=my-domain,dc=fr"
ldap_add: Constraint violation (19)
additional info: Password policy only allows one password value
However, we're able to add a user with a single value in the userPassword attribute, then, adding a second value thru the next LDAP request :
[root@openldap25 ~]# cat testuser_add.ldif
dn: uid=testuser,ou=people,dc=my-domain,dc=fr
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
uid: testuser
cn: testuserCN
sn: testuserSN
userPassword : password
[root@openldap25 ~]# ldapadd -H ldaps://localhost:636 -x -D "cn=Manager,dc=my-domain,dc=fr" -W -f testuser_add.ldif
Enter LDAP Password:
adding new entry "uid=testuser,ou=people,dc=my-domain,dc=fr"
[root@openldap25 ~]# cat testuser_mod.ldif
dn: uid=testuser,ou=people,dc=my-domain,dc=fr
changetype: modify
add: userPassword
userPassword: drowssap
[root@openldap25 ~]# ldapmodify -H ldaps://localhost:636 -x -D "cn=Manager,dc=my-domain,dc=fr" -W -f testuser_mod.ldif
Enter LDAP Password:
modifying entry "uid=testuser,ou=people,dc=my-domain,dc=fr"
[root@openldap25 ~]# ldapsearch -x -H ldaps://localhost:636 -D "cn=Manager,dc=my-domain,dc=fr" -W -LLL -b "ou=people,dc=my-domain,dc=fr" "(uid=testuser)" userPassword
Enter LDAP Password:
dn: uid=testuser,ou=people,dc=my-domain,dc=fr
userPassword:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkZjlPc3NtRFZ
DWmlzQk1IVEhWczRMZyRsMVAvbWdEdTA1bEpBc2pxcVF6aERYaENMV1BudnQyeDlRTDdweXFnVDFV
userPassword:: e0FSR09OMn0kYXJnb24yaWQkdj0xOSRtPTY1NTM2LHQ9MixwPTEkVk5ST1FMZFp
2Q0ptajNIcHQxYWtZdyRRcjJDYUpKSjZSWlhvZjFicDJmNGNOaGlRa3E5czlCU0FTbEtVNFoxYjBj
Considering configuration, we're running an OpenLDAP 2.5.7 server (LTB project) on a RHEL8 OS.
* ppolicy overlay
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
olcPPolicyDisableWrite: FALSE
olcPPolicySendNetscapeControls: FALSE
olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-domain,dc=fr
* default password policy
dn: ou=ppolicies,dc=my-domain,dc=fr
objectClass: organizationalUnit
objectClass: top
ou: ppolicies
dn: cn=default,ou=ppolicies,dc=my-domain,dc=fr
objectClass: pwdPolicy
objectClass: organizationalRole
cn: default
pwdAttribute: userPassword
pwdLockout: TRUE
* password storage
dn: olcDatabase={-1}frontend,cn=config
olcPasswordHash: {ARGON2}
Question :
* Is that behaviour normal ?
* May we keep on leaning on this behaviour without fearing that this ability of adding a second value to the userPassword attribute will be revoked in the future versions/fix/patches of the service ?
Thank you in advance for your assistance.
Best regards,
Frédéric Dussurget / Maxime Schmutz
Université Lumière Lyon 2
1 year
