Randall Mason authored 6 years ago and Quanah Gibson-Mount committed 3 years ago

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.

Fix a number of different typos across the code base

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

Lukas Juhrich authored 7 years ago and Quanah Gibson-Mount committed 4 years ago

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

Fabrice Fontaine authored 4 years ago and Quanah Gibson-Mount committed 4 years ago

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>

Kurt Zeilenga authored 7 years ago and Quanah Gibson-Mount committed 4 years ago

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.

Fixes windows build with new MS AD sync Add CLIENT_LIBS for libraries required to build the clients.

Thorsten Glaser authored 6 years ago and Howard Chu committed 6 years ago

No functional impact

Josh Soref authored 8 years ago and Quanah Gibson-Mount committed 7 years ago

* javascript
* kernel
* ldap
* length
* macros
* maintained
* manager
* matching
* maximum
* mechanism
* memory
* method
* mimic
* minimum
* modifiable
* modifiers
* modifying
* multiple
* necessary
* normalized
* objectclass
* occurrence
* occurring
* offered
* operation
* original
* overridden
* parameter
* permanent
* preemptively
* printable
* protocol
* provider
* really
* redistribution
* referenced
* refresh
* regardless
* registered
* request
* reserved
* resource
* response
* sanity
* separated
* setconcurrency
* should
* specially
* specifies
* structure
* structures
* subordinates
* substitution
* succeed
* successful
* successfully
* sudoers
* sufficient
* superiors
* supported
* synchronization
* terminated
* they're
* through
* traffic
* transparent
* unsigned
* unsupported
* version
* absence
* achieves
* adamson
* additional
* address
* against
* appropriate
* architecture
* associated
* async
* attribute
* authentication
* authorized
* auxiliary
* available
* begin
* beginning
* buffered
* canonical
* certificate
* charray
* check
* class
* compatibility
* compilation
* component
* configurable
* configuration
* configure
* conjunction
* constraints
* constructor
* contained
* containing
* continued
* control
* convenience
* correspond
* credentials
* cyrillic
* database
* definitions
* deloldrdn
* dereferencing
* destroy
* distinguish
* documentation
* emmanuel
* enabled
* entry
* enumerated
* everything
* exhaustive
* existence
* existing
* explicitly
* extract
* fallthru
* fashion
* february
* finally
* function
* generically
* groupname
* happened
* implementation
* including
* initialization
* initializes
* insensitive
* instantiated
* instantiation
* integral
* internal
* iterate

Thomas Cort authored 9 years ago and Howard Chu committed 9 years ago

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.