The options -h and -p got removed from client tools in commit
66af4cfd5d. However, they were still
present in the options[] array in several client tools source files. So,
if one of those tools got executed with -h or -p followed by a value,
this lead to the error "unrecognized option -", without mentioning
which option was problematic. Removing 'h' and 'p' from options[] fixes
this.
ldappasswd is slightly different from a standard passwd workflow in that it
requests an old password, then a new password, then the old password
again. This confuses people who are used to the unix passwd tool as
well as people who use password manager. I've seen quite a few people
who have generated a new password, overwriting the old one, and then
need a password reset because they still need to bind to modify their
password.
This patch adds an option to bind at the beginning of the process so
that you can pass '-E' to ldappasswd and it will bind early in the
process so that the process is the same as the standard passwd. All it
does is run the bind towards the beginning of the process instead of the
end.
The attached patch file is derived from OpenLDAP Software. All of
the modifications to OpenLDAP Software represented in the following
patch(es) were developed by Randall Mason randall@mason.ch. I have not
assigned rights and/or interest in this work to any party.
I, Randall Mason, hereby place the following modifications to
OpenLDAP Software (and only these modifications) into the public domain.
Hence, these modifications may be freely used and/or redistributed for
any purpose with or without attribution and/or other notice.
`rc` collects exit status all the way down but is not used at all? If `code`
comparison at exit is intended then there exists some path that leaves it in
garbage value, say when `ldap_whoami` or `ldap_cancel` fails.
The option string, e.g. '<oid>=:dn:' is parsed like a LDIF entry starting from
the '=' and replacing the '=' with a dummy variable 'x'. In this case, said
string is 'x:dn:', so the resulting effective value is 'dn:'. This also implies
that base64 values have to be passed in the form '<oid>=::<b64value>'.
Probably-Signed-off-by: Dave Bender <bender@benegon.com>
[yann.morin.1998@free.fr: patch was made by Dave, but he
forgot his SoB line, so I added it]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/openldap/0001-fix_cross_strip.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The spec says that upon StartTLS 'success', both TLS communications is
established on the octet following the Start TLS response (and the
request)... and that once one starts TLS communications, one can never
go back to LDAP without TLS. So if there's a TLS failure (whether as
part of TLS nego or later), LDAP communications cannot be continued
(without TLS).
Only ignoring LDAP errors (rc > 0) ensures that if TLS negotiation
fails, we don't attempt to send LDAP operations without TLS.
