- openldap-bugs - openldap.org

[Issue 9002] Add option to slapcat to honor rtxnsize setting
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9002 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |documentation --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Document best practices for consistent backups, namely: Stop slapd, slapcat, start slapd, perhaps a dedicated server for this purpose. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8757] RFE: let slapd MMR instances vote primary master
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

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

1 0

[Issue 8673] Need duration logging for sync ops
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

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

1 0

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

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

1 0

[Issue 10261] New: draft-behera-ldap-password-policy - evolution pwdAccountDisabled
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10261 Issue ID: 10261 Summary: draft-behera-ldap-password-policy - evolution pwdAccountDisabled Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Hello, For information, I tried to send a mail at: draft-behera-ldap-password-policy(a)ietf.org first, but I get a: Recipient address rejected: User unknown I'd like to propose an evolution for the current version of draft-behera-ldap-password-policy. Indeed, in the specification, there is the notion of locked or blocked account, with the presence of pwdAccountLockedTime, preventing users from authenticating. However: * any account with sufficient privileges can modify the userPassword * when he does so, the pwdAccountLockedTime is removed This behaviour is advisable most of the time. But sometimes we need a more restrictive policy. The goal of this evolution is to propose an alternate behaviour where the "disabling attribute" is never removed unless asked explicitely, and where userPassword cannot be modified until the "disabling attribute" is present. This attribute could be named pwdAccountDisabled. Here is the proposed evolution: 4.1.1. Password Validity Policy ... A password cannot be used to authenticate while the corresponding account has been disabled. 4.2.8. Disabled account A password cannot be changed while the password owner has been disabled. While doing so, the LDAP directory should send a Constraint violation (19) error code with additional info: Account is disabled. 5.3.12. pwdAccountDisabled This attribute holds the time that the user's account was disabled. A disabled account means that the password may no longer be used to authenticate and none can change the userPassword until it is disabled. ( 1.3.6.1.4.1.42.2.27.8.1.33 NAME 'pwdAccountDisabled' DESC 'The time an user account was disabled' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation ) Thanks in advance for your consideration. Of course, it is opened to discussion, and maybe can I help a little for the implementation. Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8611] Option to disable SSL renegotiation entirely
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8611 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Summary|Option to block SSL |Option to disable SSL |renegotation after X |renegotiation entirely |attempts | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Likely not needed for OpenLDAP, option would be to disable renegotiation entirely. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8491 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 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- Resolution|--- |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- already covered by slapmodify test007 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 21 Sep '24

21 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #18 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, tg(a)debian.org wrote: >AIUI, this should likely be something like: … make that… +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, +- LDAP_PVT_INTTYPE_CHARS(long), ++ LDAP_PVT_INTTYPE_CHARS(long long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); … of course. (It’s 03:04 in the night, and re-reading those comments from above was not effortless.) bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 21 Sep '24

21 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #17 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, openldap-its(a)openldap.org wrote: >https://bugs.openldap.org/show_bug.cgi?id=8890 >I didn't understand Howard's comment ('the unconditional use of "long long" […] Looking at it *again*, with some years of distance, I *think* I now see what Howard’s barely comprehensible and rather rude comments were meant to point out. I did not see it at that time because ⓐ I was trying, and, as a nōn-English-native speaker, failing to puzzle out what he was saying, and ⓑ the OpenLDAP code’s use of abstractions here has massively reduced its legibility. + keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); I think the first line of that is the point of critique. On repeat reading, it looks like it tries to figure out how many bytes are needed to represent a long, then allocates a buffer sized by this. As I correctly pointed out, this is a separate issue. However, Howard rejected both the immediate fix of printing wrong data RIGHT NOW (and likely truncating that at some point in the future) and this follow-up bug to address that truncation. AIUI, this should likely be something like: +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); Of course, someone who actually knows wth LDAP_PVT_INTTYPE_CHARS is needs to ensure that it DTRT for an argument of “long long” first. bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 21 Sep '24

21 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #16 from Ryan Tandy <ryan(a)openldap.org> --- Debian and Ubuntu have both switched their remaining 32-bit architectures, except for i686, to 64-bit time_t. The change is in Ubuntu 24.04 (already released) and Debian 13/trixie (not yet released). Steve Langasek committed this distro patch: https://salsa.debian.org/openldap-team/openldap/-/blob/2a8f9240b9b6fd577d91… It's mostly the same as what was previously proposed in this ITS (changing %ld format specifiers to %lld), and unfortunately contains the same smbk5pwd bug that was already commented on. I didn't understand Howard's comment ('the unconditional use of "long long" instead of "long" will break on machines where "long long" is not 64 bits'). My understanding is C specifies "long long" to be at least 64 bits, and I'm not aware of any existing systems (yet) where "long long" is 128 bits - is it more of a futureproofing concern? Casting to long long and formatting with %lld seems to be the generally accepted solution in the broader community. If that's not acceptable, maybe scripting configure to generate a PRI_TIME_T format specifier? Steve's patch comment mentions an assertion failure in test046-dds on 32-bit ARM: servers/slapd/overlays/dds.c:422: dds_op_add: Assertion `bv.bv_len < sizeof( ttlbuf )' failed. I have not reproduced it myself (I don't have ARM hardware, and it isn't happening for me on x86). I note that the assertion ttl <= DDS_RF2589_MAX_TTL just above did not fail; but that does not rule out corruption of either the 64-bit value (could be negative) or the 32-bit quantity read by snprintf. I haven't figured out what actually happened here, but it's irritating me. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=7981 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- We can't simply add this to the pwdPolicy objectclass since that is a standardized class. Also the values of crypt schemes are server specific, not standardized at all. A solution for us would be to define an OpenLDAP-specific subclass of the pwdPolicy class, and add whatever we need to in there and use it going forward. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6938 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs(a)openldap.org |mhardin(a)symas.com Ever confirmed|0 |1 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Matt to confirm slapd can listen to IPv6 on Windows, and that the ldap client tools can talk to slapd over IPv6 on windows. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6765] SASL support of "Verify Credentials" extop
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6765 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Server-side support of |SASL support of "Verify |"Verify Credentials" extop |Credentials" extop -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

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

1 0

[Issue 6531] Modify updateref to generate referrals on the backend
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

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

1 0

[Issue 10217] New: autoca should support more key types
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=10217 Issue ID: 10217 Summary: autoca should support more key types Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently autoca only creates certificates using RSA keypairs. It should at least have an option to use Elliptic Curve keypairs. It probably also needs options to specify other signature algorithms other than the default of SHA256. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 8476] slapo-constraint: info per constraint_attribute
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8476 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Seems like a good idea. For constraints where no custom message was provided, we could return the constraint number to provide a pointer to which constraint was triggered. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9652] New: Add "tee" capability to load balancer
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9652 Issue ID: 9652 Summary: Add "tee" capability to load balancer Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- This is a request for an enhancement that would add a "tee" or "fan-out" capability to load balancer, where received operations are sent to two or more destinations simultaneously. The primary goal or the enhancement is to make it possible to keep multiple independent and likely dissimilar directory systems in lock-step with each other over hours, days, or possibly even weeks. The enhancement would not necessarily need to include a mechanism for converging the target systems should they become out of sync. This is not intended to be a replication solution, rather it is viewed more as a "copy" solution intended to be used for specific short-term tasks that need multiple directory systems to be exactly synchronized but where replication is not desirable or even possible. At least two uses come to mind: 1. Test harnesses, evaluating side-by-side operation of separate directory systems over time 2. Directory system transition validation harnesses 3. (maybe) Part of a test harness to record or replay LDAP workloads * Other uses? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9667] New: 2.6 to 2.7 upgrade documentation
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9667 Issue ID: 9667 Summary: 2.6 to 2.7 upgrade documentation Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to document any upgrade information for going from 2.6 to 2.7 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 12 Sep '24

12 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6198 --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- A few open questions I can't resolve yet: - Do we rely on OID macros from schema or let slap_control/load_extop2 register it? The suggestions above tend to prefer OID macros but they have to be defined in the schema (there's only one) and they're currently case-sensitive For controls: - Do we want to be able to use ACLs to turn non-critical controls to ignored? - Do we want to be able to use ACLs to refuse control combinations? - Apart from the 'to' clause, do we want it allowed in the 'by' clause as well (when would it be useful? There's control combinations, anything else?) I'll start with "no" to all 3 of the above for now. As for combination with other specifiers (especially for exops), ACL checks are issued with the operation and an entry right now, they do make sense in that scope so password modify/DDS refresh should be in the clear. Other extops are more of a problem: - whoami: technically there is a DN but it doesn't have to correspond to an entry - verify credentials: tricky, since it's processed as a bind - cancel: abandon can't be restricted, so probably the same - turn: no idea - ChainedRequest: even less of one Probably happy for those to be impossible to restrict in this way, at least for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8905] Client side debug log should include timestamps
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8905 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |gnoe(a)symas.com -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs