openldap-bugs

openldap-bugs@openldap.org

1 participants
20977 discussions

[Bug 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |OL_2_5_REQ Summary|slapd-meta backend SSL |slapd-meta backend SSL |negociation timeout |negotiation timeout -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Howard Chu from comment #3) > Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is > implicit in the URI, so there's no point in supporting it here and it should > be an error to allow it here. In particular it makes no sense to allow it > here if it differs from the URI. Ok, although that doesn't entirely answer the rest of my question (i.e., about tls_reqcert etc missing from back-meta). Ironically I would note you're literally the person who added the "ldaps" option to back-ldap. a6a8fb514b (Howard Chu 2007-01-08 23:36:24 +0000 511) { BER_BVC( "ldaps" ), LDAP_BACK_F_TLS_LDAPS }, -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #0) > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that > they support the "ldaps" option to the "tls" keyword. This section should be > updated along the lines of back-ldap which also has this option as a keyword. Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is implicit in the URI, so there's no point in supporting it here and it should be an error to allow it here. In particular it makes no sense to allow it here if it differs from the URI. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |nivanova(a)symas.com Status|UNCONFIRMED |CONFIRMED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Hi Nadya, In looking over the back-meta man page and code and comparing it to what's in back-ldap, I think the man page for back-meta needs significant updating for the TLS option. Can you confirm the following? In back-ldap, we have: tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] Specify TLS settings for regular connections. The first parameter only applies to ldap:// connections and so at the moment, none and ldaps are equivalent. With propagate, the proxy issues StartTLS operation only if the original connection has a TLS layer set up. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended. The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand" and starttls which is overshadowed by the first keyword and thus ignored. I believe all of the above options also apply to back-meta. Are the caveats about tls_reqcert the same? For back-meta, all we have currently is: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #1 from Quanah Gibson-Mount <quanah(a)openldap.org> --- "none" is also missing -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9156] latest ppolicy draft support
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #9 from David Coutadeur <david.coutadeur(a)gmail.com> --- Hello, Thanks Ondřej for your answer to my test results. Here are some updates! > - pwdLastSuccess, pwdMaxIdle: KO: the user is able to authenticate after the > pwdMaxIdle delay. Also, the pwdLastSuccess is never written (see > https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-5.…). > For information, I have enabled lastbind. The slapo-ppolicy man page does not > mention pwdLastSuccess by the way. I finally succeeded in making it work. Thanks for pointing test022-ppolicy, it was helpfull. The problem was that I was using old lastbind overlay, which in some way was in conflict with current lastbind. If I understand correctly, the current lastbind is now completely included into OpenLDAP 2.5? It is very important to me, because as a maintainer of OpenLDAP-LTB, we would have to warn people that the configuration parameters have changed (overlay lastbind -> lastbind on) and that the overlay won't be provided any more. > - pwdStartTime, pwdEndTime: OK, but there is no special ppolicy code returned, > and if I read correctly the draft > (https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-7.1), > an "accountLocked" extended error code should be triggered. I was simply missing the ppolicy_use_lockout parameter. One remark though: the reason of locking is not very explicit. I understand that many companies/organizations will consider it is a good thing to hide this information for security reasons. For the others, maybe could we have some sort of level? Configuration example: lockout_message_description [none|minimal|verbose] In the specification the extended error code could simply stay as it is: "(1)Account locked", but we could add a more precise description in case the verbose mode is enabled: "(1)Account locked (account unused for a too long time)" Regards, David -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8893] New LDAP option to support binding to specific IPv4/IPv6 address at client side
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8893 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |DUPLICATE --- Comment #7 from Ryan Tandy <ryan(a)openldap.org> --- *** This bug has been marked as a duplicate of bug 8847 *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8847] New LDAP URL syntax to support binding to specific IP address at client side
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8847 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sudhir.singam(a)gmail.com --- Comment #30 from Ryan Tandy <ryan(a)openldap.org> --- *** Bug 8893 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #11 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- My original report mentions it: candidates[ i ].sr_msgid is -1 (META_MSGID_IGNORE) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Ok, it is halting on this check: assert( candidates[ i ].sr_msgid >= 0 || candidates[ i ].sr_msgid == META_MSGID_CONNECTING ); So what we need is in thread 1, frame 2, to know what the value of candidates[i].sr_msgid is. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs