https://bugs.openldap.org/show_bug.cgi?id=6937
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |quanah(a)openldap.org
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/27
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7335
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Error in slapo-refint man |Create process for updating
|page |man pages to handle both
| |cn=config and slapd.conf
| |configurations
--
You are receiving this mail because:
You are on the CC list for the bug.
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.
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.
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.
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.
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.
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.
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.
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.