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.
The LDIF output wasn't being explicitly flushed. In certain scenarios,
such as piping the output of a persistent ldapsearch to node.js v0.12
on Mac OS X 10.10.3, the output is unavailable to the process
consuming the search results until the stdio buffer fills (8192 bytes
for example). This can leave the tail end of persistent search results
in the buffer for a long time (until enough output has accumulated).
Explicitly call flush so that the output is immediately available.
