November 2023 - openldap-bugs

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

10 hours, 11 minutes

1
3
0 / 0

[Issue 10137] New: Ease redefining the MDB_IDL_LOGN value

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10137 Issue ID: 10137 Summary: Ease redefining the MDB_IDL_LOGN value Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 992 --> https://bugs.openldap.org/attachment.cgi?id=992&action=edit The patch do apply to midl.h Hello, I would like to slightly change the midl.h c file to make it possible to change the MDB_IDL_LOGN define without having to fork on my side. I know it can be redefined to reduce the amount of memory allocated by LMDB. I am using the latest `mdb.master` branch version of LMDB. https://github.com/mozilla/lmdb/pull/2 -- You are receiving this mail because: You are on the CC list for the issue.

12 hours, 59 minutes

1
6
0 / 0

[Issue 10135] New: dynlist (and maybe others) doesn't use the right overinst context in callbacks

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10135 Issue ID: 10135 Summary: dynlist (and maybe others) doesn't use the right overinst context in callbacks Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Running the test suite with `-fsanitize=address` picks up a bug in https://git.openldap.org/openldap/openldap/-/blob/860b61f41dfeeb19cc0eb01... Here, op->o_bd->bd_info isn't actually dynlist but mdb's own static bi, so overlay_entry_get_ov then reaches into the void when reading on->on_info. It's very likely that other places/overlays share the same bug as it is subtle and doesn't get picked up immediately (slap_overinst embeds a BackendInfo and oi_orig is not often set). -- You are receiving this mail because: You are on the CC list for the issue.

13 hours

1
2
0 / 0

[Issue 10132] New: manage syncrepl as a cn=config entry

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry 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: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

13 hours, 1 minute

1
1
0 / 0

[Issue 8826] Contrib dsaschema module needs updating for cn=config

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8826 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #1 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/661 -- You are receiving this mail because: You are on the CC list for the issue.

17 hours, 50 minutes

1
0
0 / 0

[Issue 10109] New: [slapd] Segmentation fault

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10109 Issue ID: 10109 Summary: [slapd] Segmentation fault Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: sfhacker(a)hotmail.com Target Milestone: --- Created attachment 984 --> https://bugs.openldap.org/attachment.cgi?id=984&action=edit Backtrace Hi. OpenLDAP 2.6.6 built from source on Windows 10 x64. When starting the server using a basic slapd.conf file, I get a segmentation fault (see screenshot attached). Thanks in advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 day, 11 hours

1
4
0 / 0

[Issue 10136] New: Sync replication causing glue entries.

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10136 Issue ID: 10136 Summary: Sync replication causing glue entries. Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mbalakri(a)opentext.com Target Milestone: --- Created attachment 991 --> https://bugs.openldap.org/attachment.cgi?id=991&action=edit Node1 and Nod2 sync replication logs We have configured mirror mode replication with two nodes. Node1 syncrepl {0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk" Node2 syncrepl {0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="120 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk" olcMultiProvider is ON. Now when records are inserted into node1, it is replicating to node2 but after sometime glue entries are created in node2 and from then onwards replication is not working. Attached the sync logs from both the nodes. The below two entries are in glue state and not recovering from this state. cn=Method Set CAPackage,cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net cn=Cordys CAPConnector,cn=cordys,cn=defaultInst,o=otxlab.net Any clue on what is going wrong here? Is this due to the 'retry' configuration? -- You are receiving this mail because: You are on the CC list for the issue.

1 day, 11 hours

1
4
0 / 0

[Issue 6166] Overlay/backend restructuring

by openldap-its＠openldap.org

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

5 days, 16 hours

1
0
0 / 0

[Issue 10134] New: OpenLDAP Docker Installation and Migration

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10134 Issue ID: 10134 Summary: OpenLDAP Docker Installation and Migration Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: chilimili1(a)outlook.de Target Milestone: --- Created attachment 990 --> https://bugs.openldap.org/attachment.cgi?id=990&action=edit Dockerfile.txt logs_importfile.txt logs_slaptest.txt Hi, I am currently experiencing issues while building a Docker container for OpenLDAP. I hope that an expert from the community can help me solve my problem. Issue 1: Docker Setup I'm in the process of setting up OpenLDAP within a Docker container on a RHEL 9 base OS. I've attached the Dockerfile I'm using for reference. My primary concern is that when I run the command RUN slaptest -f /tmp/slapd.conf -F /etc/openldap/slapd.d -d 1, it fails with mdb_db_open: database "dc=my-domain,dc=com": dbenv_open(/usr/var/openldap-data). mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: No such file or directory (2). Restore from backup!. Interestingly, slaptest -u seems to work fine. I would greatly appreciate it if you could review my Dockerfile or provide insights into what might be causing this issue. Issue 2: LDAP Migration Additionally, I'm trying to migrate configuration data from a system using OpenLDAP 2.4.50 to OpenLDAP 2.5.13. During this process, I encountered the following error: csharp Copy code olcAuthzRegexp: value #0: keyword <olcAuthzRegexp> missing <regexp> <DN> argument slapadd: could not add entry dn="cn=config" (line=1) Dockerfile.txt logs_importfile.txt logs_slaptest.txt I'm not sure if these issues are related, but I thought it would be best to ask for your expertise on both matters. Thank you in advance for your assistance. Your guidance would be greatly appreciated. -- You are receiving this mail because: You are on the CC list for the issue.

6 days, 9 hours

1
3
0 / 0

[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=10080 Issue ID: 10080 Summary: refreshAndPersist synchronization problem with glue + rwm Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: homma(a)allworks.co.jp Target Milestone: --- Created attachment 972 --> https://bugs.openldap.org/attachment.cgi?id=972&action=edit Stack trace of segfault I have an openldap 2.6.2 server "ldap1" with the following DIT: dc=example,dc=com (back-mdb) ou=users ou=local cn=admin cn=sync ... ou=remote (back-ldap -> ldaps://dc1.example.com) ... Local user entries are created under subtree "ou=local,ou=users,dc=example,dc=com", and the subtree "ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server "dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com"). The concrete configuration is as follows: ---------------- dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: ou=remote,ou=users,dc=example,dc=com olcSubordinate: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbURI: ldaps://dc1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com" credentials=secret tls_reqcert=demand mode=none olcDbIDAssertAuthzFrom: {0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbIDAssertAuthzFrom: {1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com" olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson olcRwmMap: {1}objectclass posixAccount user olcRwmMap: {2}attribute uid sAMAccountName olcRwmMap: {3}attribute homeDirectory unixHomeDirectory olcRwmMap: {4}attribute ou * olcRwmMap: {5}attribute cn * olcRwmMap: {6}attribute sn * olcRwmMap: {7}attribute givenName * olcRwmMap: {8}attribute mail * olcRwmMap: {9}attribute uidNumber * olcRwmMap: {10}attribute gidNumber * olcRwmMap: {11}attribute * dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcAccess: {0}to * by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write by * break olcAccess: {1}to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2}to * by * read olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub ---------------- So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both local and remote users. But when I create the second server "ldap2" with similar configuration and configure refreshAndPersist replication, I run into a problem. (1) When I configure on "ldap1" server, ---------------- dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ---------------- and on "ldap2" server, ---------------- dn: olcDatabase={3}mdb,cn=config changeType: modify replace: olcSyncrepl olcSyncrepl: {0}rid=301 provider="ldap://ldap1/" bindmethod=simple binddn="cn=sync,ou=local,ou=users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 12 60 +" timeout=1 ---------------- the initial refresh stage fails. (a) Whith the above configuration, the refresh failes with "(48) Inappropriate authentication", because the bind DN "cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the subordinate database. (b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with "(12) Critical extension is unavailable", because Active Directory does not support Sync Request Control. (c) Even if the remote server supports Sync Request Control, the refresh fails with the message "server sent multiple refreshDone messages? Ending session". The refreshDone messages are sent twice, one for the sperior databese and the other for the subordinate database. (d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify delete: olcSubordinate ---------------- then the refresh stage completes successfully. Once the persistent session is established, I can add olcSubordinate attribute again. ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcSubordinate olcSubordinate: TRUE ---------------- When I modify entries in the subordinate database on "ldap1" server, no change notification is sent to "ldap2" server. This is the desired behavior, but if I restart slapd on "ldap1" server, the refresh starts failing again. (2) When I configure the glue overlay explicitly before the syncprov overlay, as described in "man slapd-config", ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. This is fine because I do not need to synchronize the subordinate database between "ldap1" and "ldap2" servers. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault. See the attached file for stack trace. After some research, I found that the cause of the crash is as follows: In syncprov_matchops(), it attempts to get the modified entry with DN = op->o_req_ndn. But since op->o_req_ndn has been rewritten in the rmw overlay, glue_back_select() incorrectly selects the mdb backend, which should be the ldap backend. At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but mdb_entry_get() tries to interpret it as type struct mdb_info, causing a segfault. In summary, the problem is: When I configure refreshAndPersist synchronization for a database with a subordinate ldap backend using DN rewriting, (1) The subordinate database cannot be excluded from both refresh and persistent stage of the synchronization: When the glue overlay is not explicitly configured: - In the refresh stage, the subordinate database is included in the search. - In the persist stage, the subordinate database is excluded from the synchronization. When the glue overlay is explicitly configured before the syncprov overlay: - In the refresh stage, the subordinate database is excluded from the search. - In the persist stage, the subordinate database is included in the synchronization. This seems to be inconsistent. (2) If the subordinate database is included in the refresh stage, the refresh fails for one of the following reasons: - the syncrepl user is not allowed to access the subordinate database - the remote server does not support Sync Request Control - multiple refreshDone messages are returned The refresh stage completes successfully if olcSubordinate attribute is deleted from the subordinate database. olcSubordinate attribute can be added again once the persistent session is established, but the refresh stage starts failing again if slapd is restarted. (3) If the subordinate database is included in the persist stage, modifying entries in the subordinate database causes slapd to crash. -- You are receiving this mail because: You are on the CC list for the issue.

6 days, 12 hours

1
14
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2023