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.
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.
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.
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.
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.
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.
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.
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.
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.
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.