openldap-bugs

openldap-bugs@openldap.org

1 participants
20894 discussions

[Issue 7089] ppolicy adds PWDFAILURETIME to organizationalUnit
by openldap-its＠openldap.org 22 Mar '22

22 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=7089 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9813 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9810] New: slapacl peername
by openldap-its＠openldap.org 18 Mar '22

18 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9810 Issue ID: 9810 Summary: slapacl peername Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ratness(a)gmail.com Target Milestone: --- Found in 2.4.59 on a $WORK system, replicated in 2.6.1: [root@centos-s-1vcpu-1gb-ams3-01 ~]# rpm -qf /opt/symas/sbin/slapacl symas-openldap-servers-2.6.1-2.el7.x86_64 This is a box where I don't even have slapd running, but that's okay because my point is visible without it: [root@centos-s-1vcpu-1gb-ams3-01 ~]# /opt/symas/sbin/slapacl -F /etc/openldap/slapd.d -D 'someuser' -b 'somewhere' -o peername.ip=127.0.0.1 entry/read usage: slapacl [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-U authcID | -D authcDN] [-X authzID | -o authzDN=<DN>] -b DN [-u] [attr[/access][:value]] [...] When I ask for `-o peername.ip=127.0.0.1` the `slapacl` command bails out with usage, indicating a parse failure. If I then run `slapacl` with `-o peername=ip=127.0.0.1`, I get: [root@centos-s-1vcpu-1gb-ams3-01 ~]# /opt/symas/sbin/slapacl -F /etc/openldap/slapd.d -D 'someuser' -b 'somewhere' -o peername=ip=127.0.0.1 entry/read invalid config directory /etc/openldap/slapd.d, error 2 slapacl: bad configuration directory! (which I would expect here since I have no server running) Demo on 2.4.59 at work: $ /usr/sbin/slapacl -F /etc/openldap/slapd.d -D uid=replicator,ou=logins,dc=example -b 'mail=me(a)example.com,o=com,dc=mozilla' -o peername=ip=127.0.0.1 entry/read authcDN: "uid=replicator,ou=logins,dc=example" read access to entry: ALLOWED $ /usr/sbin/slapacl -F /etc/openldap/slapd.d -D uid=replicator,ou=logins,dc=example -b 'mail=me(a)example.com,o=com,dc=mozilla' -o peername=ip=127.0.0.2 entry/read authcDN: "uid=replicator,ou=logins,dc=example" read access to entry: DENIED slapacl(8) mentions peername, but also aims us at slapd.access(5), which lists peername[.<peernamesytle>]. It's possible I'm dense and this isn't a bug, but minimally the equalsign repetition is really awkward to my eye. I'd suggest at least an example in slapacl(8) so it's easier to figure out. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9807] New: Cannot enable {ARGON2} passwd scheme support
by openldap-its＠openldap.org 13 Mar '22

13 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9807 Issue ID: 9807 Summary: Cannot enable {ARGON2} passwd scheme support Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: gregory.widmer(a)gwidmer.fr Target Milestone: --- Created attachment 881 --> https://bugs.openldap.org/attachment.cgi?id=881&action=edit Trace of every executed command. I want to build OpenLDAP with argon2 support. Unfortunately, it doesn't work and I don't understand why. It seems to be a build issue. Here is how to reproduce the issue : I'm using a fresh install of Debian 11. The following packages were installed for this : - libargon2-dev - libltdl-dev - git - build-essential I am using the master branch of the git repository : https://git.openldap.org/openldap/openldap/-/commit/e8813b12b6188d5ba5f174f… I'm using root, and the repo is under /root/openldap. My objective is to : - Run slapd with {ARGON2} support - Set {ARGON2} as password-hash - Use slappasswd to create a password for LDAP admin in slapd.conf I ran the following commands : - apt install libltdl-dev libargon2-dev git build-essential -y - ./configure --with-argon2=libargon2 --enable-modules --enable-argon2=yes - make depend - make - make check - make install I then created a systemd service for slapd, reloaded daemons with systemctl then started the service. I got the following error : @(#) $OpenLDAP: slapd 2.X (Mar 12 2022 15:31:06) $ root@ldap:/root/openldap/servers/slapd /usr/local/etc/openldap/slapd.conf: line 65: <password-hash> scheme not available ({ARGON2}) /usr/local/etc/openldap/slapd.conf: line 65: <password-hash> no valid hashes found slapd stopped. connections_destroy: nothing to destroy. I don't understand how to build openldap with argon2. I did not find anything. You will find a global trace file for every command used with the program. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9805] New: member attributes managed by autogroup are lost when user attributes are adjusted
by openldap-its＠openldap.org 10 Mar '22

10 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9805 Issue ID: 9805 Summary: member attributes managed by autogroup are lost when user attributes are adjusted Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: michael.bobzin(a)baloise.ch Target Milestone: --- Hello OpenLDAP Team, we use nested groups in our OpenLDAP directory. User X is a member of group A. Group A is a member of group B. User X is therefore also a member of group B. To be able to find out all groups of user X with only one LDAP query we use the dynlist overlay together with the autogroup overlay. Group B is a dynamic group whose member attributes are set with autogroup, to allow a search for members. ldapsearch .. -s sub -b "ou=groups,dc=basler,dc=ch" "(member=cn=userx,ou=users,dc=basler,dc=ch)" dn Result: cn=groupA,ou=groups,dc=basler,dc=ch cn=groupB,ou=groups,dc=basler,dc=ch ----- Gruppe A ---------------------------------------------------------- dn: cn=groupA,ou=groups,dc=basler,dc=ch cn: groupA objectClass: top objectClass: groupOfNames member:cn=userX,ou=users,dc=basler,dc=ch ----- Gruppe B ---------------------------------------------------------- dn: cn=groupB,ou=groups,dc=basler,dc=ch cn: groupB objectClass: top objectClass: groupOfURLs memberURL: ldap:///ou=groups,dc=basler,dc=ch?member?one?(cn=groupA) # managed by autogroup member:cn=userX,ou=users,dc=basler,dc=ch ----------------------------------------------------------------------- This works until any attribute in the userX object is changed. The member attribute for userX created dynamically by autogroup is then deleted from groupB although userX is still a member of groupA and is therefore matched with the search in the memberURL attribute of groupB matched. The expected behaviour would be that the member attribute in groupB remains unchanged. ----------- configuration -------------------------- OpenLDAP 2.4.59 from https://www.ltb-project.org/download.html --------------- slapd.conf ------------------------- ... moduleload dynlist moduleload autogroup.so ... include /usr/local/openldap/etc/openldap/local-schema/dyngroup.schema ... overlay dynlist dynlist-attrset groupOfURLs memberURL overlay autogroup autogroup-attrset groupOfURLs memberURL member -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9497] New: back-ldif: test022-ppolicy failure
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9497 Issue ID: 9497 Summary: back-ldif: test022-ppolicy failure Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The test022-ppolicy with back-ldif fail for two issue. 1. too short pwdMaxAge ~~~ $ ./run -b ldif test022-ppolicy (snip) Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. Password expiration test failed ~~~ The script tries test for lockout and then a test for password expiration. It will fail if the password has expired(pwdMaxAge: 30) by the time it starts the password expiration test. This is a timing issue and not directly caused by back-ldif. However, the issue is reproduced only with back-ldif in my environment. This test passed in my environment by extending pwdMaxAge by 5 seconds, but there may be a better way. 2. duplicate ldap control response ~~~ Reconfiguring policy to remove grace logins... Clearing forced reset... expr: syntax error: unexpected argument '15' Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. ~~~ This is back-ldif issue. back-ldif responds duplicate ldap control response. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 5840] mdb online indexing and shutdown
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=5840 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5840] mdb online indexing and shutdown
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=5840 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Howard Chu <hyc(a)openldap.org> --- (In reply to Ondřej Kuzník from comment #11) > Is this resolved with ITS#8958? Yes *** This issue has been marked as a duplicate of issue 8958 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=8958 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ralf(a)openldap.org --- Comment #42 from Howard Chu <hyc(a)openldap.org> --- *** Issue 5840 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5840] mdb online indexing and shutdown
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=5840 --- Comment #11 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Is this resolved with ITS#8958? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9798] New: Clearing pending ops on Bind
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9798 Issue ID: 9798 Summary: Clearing pending ops on Bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Some context first. The only universal way of reset an arbitrary (SASL) bind in progress, at least in my reading of RFC4511 is to send an anonymous bind op, so that's what the load balancer does when needed (the client goes away, etc.). Incidentally, this is also what the balancer chooses to do when the pending bind needs to be "abandoned" when the backend doesn't respond within a configured timeout. That's skating the edge of what RFC4511 allows, probably just past it. The issue: When slapd receives a bind and another operation X (lloadd sends the above mentioned "reset" bind) before that first bind starts processing, X gets added into conn->c_ops_pending and does c_n_pending_ops++. Bind then eventually invokes connection_abandon which forgets to zero out c_n_pending_ops and the connection remains unusable forever. On the surface that's trivial to fix and a fix is coming. On the other hand, operation X in the pending list is actually discarded too, so that kind of defeats the idea of trying to "abandon" the original bind and completely reset the connection state. Question is, do we want to retain the last bind in the pending list or does the balancer have to destroy the connection unconditionally when a bind times out? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs