ldap-sdk-discuss — Discussions related to the LDAP SDK for Java

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 7.0.3

[Neil W. <nei...@pi...>]

We have just released version 7.0.3 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/7.0.3>.
You can find the release notes for this release (and all previous versions)
at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes:


   -

   We fixed an issue in which the LDAP SDK did not properly handle
   certificates with a notBefore or notAfter timestamp that fell in the year
   2049 if that timestamp was encoded with the antiquated UTCTime syntax
   (which only uses two digits to encode the year). It incorrectly used a year
   of 1949 instead of 2049.



   -

   We updated the ldifmodify tool so that it will report an error if any of
   the sourceLDIF, changesLDIF, or targetLDIF arguments refer to the same
   file. Previously, the tool would run, but could yield incomplete results if
   an input file was also used as an output file.



   -

   We updated the IP address argument value validator to improve
   performance and to catch additional types of malformed IPv4 addresses that
   were previously accepted due to leniency in Java’s InetAddress.getByName
   implementation.



   -

   We simplified and improved the toLowerCase, toUpperCase, and getBytes
   methods in the StaticUtils class. The former implementations were more
   efficient than the versions provided in the Java String class in older Java
   versions when primarily dealing with ASCII strings, but this is no longer
   the case in newer versions of Java where strings are backed by byte arrays
   rather than character arrays.



   -

   We updated client-side support for the Ping-proprietary transaction
   settings request control to make it possible to request that the server
   acquire a lock using a client-specified scope under a specified set of
   conditions. This allows more control in the event of lock conflicts in
   cases where the client is able to determine which operations are most
   likely to conflict with each other. For example, in a multi-tenant server,
   it may be useful to specify a scope that includes a tenant-specific
   identifier so that only operations associated with that tenant will be
   affected by the scoped lock.



   -

   We also updated the transaction settings request control to make it
   possible to override the conditions under which the server may attempt to
   acquire a single-writer lock. This was previously only controlled through
   the server configuration.



   -

   We improved error reporting in the dump-dns tool for use with the Ping
   Identity Directory Server.



   -

   We updated client-side support for the Ping Identity Directory Server’s
   version monitor entry to handle attributes used to indicate whether the
   server is running in FIPS 140-2-compliant or FIPS 140-3-compliant mode.



   -

   We updated the documentation to include the newest versions of the
   draft-bucksch-sasl-passkey, draft-bucksch-sasl-rememberme,
   draft-codere-ldapsyntax, draft-ietf-kitten-sasl-ht,
   draft-ietf-kitten-sasl-rememberme, and draft-schmaus-kitten-sasl-ht
   specifications.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] Asking help: not escape '=' in ldapsdk 6.0.11

[Neil W. <nei...@pi...>]

RFC 4514 <https://docs.ldap.com/specs/rfc4514.txt> defines the format for
the string representation of LDAP DNs and RDNs, and the equal sign is not
required to be escaped in attribute values. It’s perfectly acceptable to
escape it, but it’s not required. That was also true in the previous
version of the LDAPv3 DN specification in RFC 2253
<https://docs.ldap.com/specs/rfc2253.txt>.

The change in behavior was likely introduced in the 6.0.0 release in an
attempt to limit the amount of escaping that is performed in DNs and RDNs
to make the result more easily readable. The release note message that
corresponds to that change is:

Improved the logic used to decide which types of optional escaping should
be used when generating the string representation of a DN or RDN. If a DN
or RDN was created from a string representation, then that string
representation will generally be preserved. However, if a DN or RDN is
created from its component parts, then the string representation will be
generated, and the LDAP SDK may choose to escape more characters than are
required by RFC 4514. Previously, the LDAP SDK always escaped all ASCII
control characters and all non-ASCII characters. It will now still escape
all ASCII control characters, but it will only escape non-ASCII characters
if it does not believe that they are displayable. If it believes that a
non-ASCII character is displayable (including Latin characters with
diacritics and letters, digits, spacing, punctuation, and symbols from
languages that use non-Latin characters), that character now be left
unescaped. The default behavior can be overridden either programmatically
or through a system property. The logic used to generate normalized
representations of DNs and RDNs has not changed.

The LDAP SDK should continue to be able to properly interpret DNs that have
equal signs escaped, but it won’t generate them. And any
standards-compliant LDAP server should also be able to DNs in either form.

Neil Wilson



On Mon, Jun 16, 2025 at 1:30 PM Huiqing Zeng via ldap-sdk-discuss <
lda...@li...> wrote:

> Hi,
>
> We have recently tried to upgrade LdapSDK from 5.1.4 to 6.0.11, but we
> found that the 6.0.11 version does not escape '=' anymore in '(new
> RDN()).toString()', this is a big block to us, wondering any suggestions?
> Thanks a lot in advance.
>
> For example, we have: *CN=+John #<>\"= Doe;*
> In 5.1.4, return:   *CN=\+John #\<\>\\\"\= Doe\;*
> In 6.0.11, return: *CN=\+John #\<\>\\\"= Doe\;*
>
> Thanks,
> Huiqing
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] Asking help: not escape '=' in ldapsdk 6.0.11

[Huiqing Z. <hui...@ok...>]

Hi,

We have recently tried to upgrade LdapSDK from 5.1.4 to 6.0.11, but we
found that the 6.0.11 version does not escape '=' anymore in '(new
RDN()).toString()', this is a big block to us, wondering any suggestions?
Thanks a lot in advance.

For example, we have: *CN=+John #<>\"= Doe;*
In 5.1.4, return:   *CN=\+John #\<\>\\\"\= Doe\;*
In 6.0.11, return: *CN=\+John #\<\>\\\"= Doe\;*

Thanks,
Huiqing

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 7.0.2

[Neil W. <nei...@pi...>]

We have just released version 7.0.2 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/7.0.1>.
You can find the release notes for this release (and all previous versions)
at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes:


   -

   We added support for using the 2.x version of the Bouncy Castle
   FIPS-compliant security provider, which provides support for FIPS 140-3
   compliance. The 1.x version of the library, offering FIPS 140-2 compliance,
   is still supported. To use the LDAP SDK in this mode, you should ensure
   that the necessary jar files are in the classpath, and then you should call
   CryptoHelper.setUseFIPSMode("BCFIPS2") as early as possible in the life
   of the application.



   -

   We added a new PropertyManager class that can be used to retrieve the
   value of specified properties using either system properties or environment
   variables. Values can be optionally parsed as Booleans, numbers, or
   comma-delimited lists. Most uses of system properties within the LDAP SDK
   have been updated to support the new PropertyManager mechanism so that
   it’s possible to set values as environment variables as an alternative to
   system properties.



   -

   We fixed a bug in the SSLUtil.certificateToString method that prevented
   it from including the notBefore and notAfter timestamps in the string
   representation.



   -

   We added client-side support for the Ping Identity Directory Server’s
   new to-be-deleted accessibility state for use with the get subtree
   accessibility and set subtree accessibility extended operations.



   -

   We updated the MoveSubtree utility class to provide the ability to use
   the new to-be-deleted accessibility state (as an alternative to the hidden
   state) for the target subtree before starting to remove entries from the
   source server.



   -

   We added a new SubtreeAccessibilityState.isMoreRestrictiveThan method
   that can be used to determine whether one accessibility state is considered
   more restrictive than another.



   -

   Updated the documentation to include the latest versions of the
   following LDAP-related specifications:
   -

      draft-coretta-ldap-subnf-01
      -

      draft-coretta-oiddir-radit
      -

      draft-coretta-oiddir-radsa
      -

      draft-coretta-oiddir-radua
      -

      draft-coretta-oiddir-roadmap
      -

      draft-coretta-oiddir-schema
      -

      draft-ietf-kitten-scram-2fa
      -

      draft-melnikov-sasl2
      -

      draft-melnikov-scram-bis
      -

      draft-melnikov-scram-sha-512
      -

      draft-melnikov-scram-sha3-512

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 7.0.1

[Neil W. <nei...@pi...>]

We have just released version 7.0.1 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/7.0.1>.
You can find the release notes for this release (and all previous versions)
at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes:


   -

   We added a new MaximumIdleDurationLDAPConnectionPoolHealthCheck class
   that can be used to replace connections that have remained idle for longer
   than a specified length of time. We generally recommend setting a maximum
   connection age for the pool so that connections are automatically replaced
   after a given amount of time regardless of their activity, but the new
   health check can be used as an alternative if you want to keep active
   connections around as long as possible while also ensuring that idle
   connections are closed by the LDAP SDK before they might be closed by the
   LDAP server or by intermediate network equipment.



   -

   We updated the in-memory directory server to improve its concurrency
   when processing operations that don’t need to make changes to the data,
   including binds, searches, and compares.



   -

   We added new Filter.createSubstringAssertion methods that can be used to
   create properly encoded string representations of substring assertions.
   This can be particularly helpful when you want to create an extensible
   matching filter using a substring matching rule.



   -

   We updated the KeyStoreKeyManager and TrustStoreTrustManager classes to
   make it possible to use an alternative security provider when accessing the
   associated key or trust store. We’ve also made it possible to indicate
   whether the LDAP SDK should be allowed to access non-FIPS-compliant key
   stores when operating in FIPS 140-2-compliant mode.



   -

   We fixed an issue in which the parallel-update tool would use an
   in-memory buffer to hold information about information to write to the
   reject file, but it would not automatically flush that buffer when changes
   are rejected. In some cases, this could introduce a significant delay
   between the time that a change is rejected and the time that a record of it
   was written to the specified log file.



   -

   We fixed an issue with the manage-certificates tool that could prevent
   it from accessing the JVM’s default trust store in cases where the LDAP SDK
   is operating in FIPS 140-2-compliant mode and the tool is invoked
   programmatically (as opposed to running it from the command line).



   -

   We updated the command-line tool framework to make it possible for tools
   to expose arguments for generating a debug log file. All of the tools
   included with the LDAP SDK have been updated to provide this option, and
   you can use the --help-debug argument to see the applicable arguments.



   -

   We updated the debug logging framework to make it possible to write
   debug messages, which are formatted as JSON objects, using a multi-line
   representation rather than the default single-line representation. People
   looking at the log messages may find the multi-line format easier to read.



   -

   We added a new StaticUtils.setSystemPropertyIfNotAlreadyDefined method
   that can be used to set the value of a specified system property in the
   JVM, but only if it’s not already set (in which case its current value will
   be preserved).



   -

   We added client-side support for a new “verify password” extended
   request in the Ping Identity Directory Server that properly authorized
   clients (under a restricted set of circumstances) can use to determine
   whether a given password is valid for a specified user without performing
   any other password policy processing.



   -

   We updated the OID registry to include records for a number of collation
   matching rules supported in the Ping Identity Directory Server, ForgeRock
   OpenDJ, Oracle OUD, and other servers.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 7.0.0

[Neil W. <nei...@pi...>]

We have just released version 7.0.0 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/7.0.0>.
You can find the release notes for this release (and all previous versions)
at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes:


   -

   The LDAP SDK now requires Java 8 or later. Java 7 is no longer supported.



   -

   We improved the behavior of LDAP connection pools when they are
   configured to invoke a health check when checking out a connection from the
   pool. Previously, if a connection was found to be invalid during checkout,
   the LDAP SDK would create a new connection to replace it, but would
   continue iterating through other connections in the pool trying to find an
   existing valid connection. It will now return the newly created connection
   immediately without checking other existing connections, which can
   substantially reduce the time to check out a connection in a scenario where
   many connections have been invalidated (e.g., by a server shutdown).



   -

   We added a new compare-ldap-schemas command-line tool that can be used
   to identify differences between the schemas of two LDAP servers.



   -

   We improved the behavior that the LDAP SDK uses when authenticating with
   the GSSAPI SASL mechanism. Previously, if you didn’t explicitly provide a
   JAAS configuration file to use for the attempt, the LDAP SDK would create a
   new one for each bind attempt. This would create a lot of temporary files
   that would need to be cleaned up when the JVM exited, and they might not
   get cleaned up properly if they JVM exits abnormally (e.g., it’s killed or
   if the JVM crashes). It would also require a small amount of additional
   memory for each bind attempt, since it has to remember another file to be
   deleted. Now, the LDAP SDK will be able to reuse the same generated
   configuration file for all GSSAPI bind requests that use the same JAAS
   settings, which will slightly improve performance, reduce memory usage, and
   reduce disk space consumption.



   -

   We added experimental client-side support for the relax rules support as
   defined in draft-zeilenga-ldap-relax-03
   <https://docs.ldap.com/specs/draft-zeilenga-ldap-relax-03.txt>. This
   draft doesn’t specify an OID for the control, but at least a couple of
   servers (OpenLDAP and ForgeRock OpenDJ) have implemented support for the
   control with an OID of 1.3.6.1.4.1.4203.666.5.12, so the LDAP SDK uses that
   OID for the control.



   -

   We added client-side support for a number of proprietary controls used
   by the ForgeRock OpenDJ directory server. These include:
   -

      A transaction ID request control, which can be included in an
      operation request to provide a transaction ID that will appear in the
      access log message for that operation.
      -

      A replication repair request control, which can be included in a
      write request to indicate that the associated change should not be
      replicated.
      -

      Change sequence number request and response controls, which can be
      used with a write operation to obtain the replication CSN that the server
      assigned to that operation.
      -

      Affinity request control, which can be included in related requests
      sent through an LDAP proxy server to consistently route them to the same
      LDAP server instance.



   -

   We added connection pool health checks for use in conjunction with the
   Ping Identity Directory Server, including:
   -

      One that will attempt to determine whether there are any active
      alerts in the server that cause it to consider itself to be
either degraded
      or unavailable.
      -

      One that will assess the replication backlog and can consider a
      server unavailable if it has too many outstanding changes, or if
the oldest
      outstanding change was originally processed too long ago.
      -

      One that will attempt to determine whether the server is in lockdown
      mode.



   -

   We updated the CryptoHelper class to add convenience methods for
   generating SHA-256, SHA-384, and SHA-512 digests from byte arrays, strings,
   and files. There are also generic versions of these methods that can be
   used with user-specified digest algorithms.



   -

   We added methods for normalizing JSON values and JSON object filters.
   This can help make it possible to compare two JSON object filters to
   determine whether two JSON object filters are equivalent.



   -

   We updated the BouncyCastleFIPSHelper class to add a constant with the
   name of a system property that can be used to enable support for the MD5
   digest algorithm, which may be needed if you’re using the 1.0.2.4 or later
   version of the bc-fips jar file and need to use the MD5 message digest for
   some reason.



   -

   We updated the documentation to include new and updated versions of a
   number of LDAP-related Internet Drafts, including:
   -

      draft-ietf-kitten-scram-2fa-04
      <https://docs.ldap.com/specs/draft-ietf-kitten-scram-2fa-04.txt>
      -

      draft-melnikov-scram-bis-04
      <https://docs.ldap.com/specs/draft-melnikov-scram-bis-04.txt>
      -

      draft-melnikov-scram-sha-512-04
      <https://docs.ldap.com/specs/draft-melnikov-scram-sha-512-04.txt>
      -

      draft-melnikov-scram-sha3-512-04
      <https://docs.ldap.com/specs/draft-melnikov-scram-sha3-512-04.txt>
      -

      draft-coretta-oiddir-radit-00
      <https://docs.ldap.com/specs/draft-coretta-oiddir-radit-00.txt>
      -

      draft-coretta-oiddir-radsa-00
      <https://docs.ldap.com/specs/draft-coretta-oiddir-radsa-00.txt>
      -

      draft-coretta-oiddir-radua-00
      <https://docs.ldap.com/specs/draft-coretta-oiddir-radua-00.txt>
      -

      draft-coretta-oiddir-roadmap-00
      <https://docs.ldap.com/specs/draft-coretta-oiddir-roadmap-00.txt>
      -

      draft-coretta-oiddir-schema-01
      <https://docs.ldap.com/specs/draft-coretta-oiddir-schema-01.txt>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.11

[Neil W. <nei...@pi...>]

We have just released version 6.0.11 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/6.0.11>
.

Note that this is the last release of the LDAP SDK that will offer support
for Java 7. As of the next release (which is expected to have a version of
7.0.0), the LDAP SDK will only support Java 8 and later.

You can find the release notes for the 6.0.11 release (and all previous
versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but
here’s a summary of the changes:


   -

   We updated the ldapsearch and ldapmodify command-line tools to provide
   better validation for the --proxyAs argument, which includes the proxied
   authorization v2 request control in the requests that they issue.
   Previously, they would accept any string as the authorization ID value, but
   they will verify that it is a valid authorization ID using the form “dn:”
   followed by a valid DN or “u:” followed by a username.



   -

   We updated the Filter class so that the methods used to create substring
   filters are more user-friendly when the filter doesn’t contain all types of
   components. Previously, it expected a substring component to be null if
   that component wasn’t to be included in the request, and it would create an
   invalid filter if the component was provided as an empty string. It will
   now treat components provided as empty strings as if they had been null.



   -

   We updated the logic that the LDAP SDK uses to pare entries down to a
   specified set of attributes (including in the in-memory directory server
   and the ldifsearch command-line tool) to improve its behavior if it
   encounters an entry with a malformed attribute description (for example,
   one that contains characters that aren’t allowed). Previously, this would
   result in an internal error, but it will now make a best-attempt effort to
   handle the invalid name.



   -

   We updated the TimestampArgument class to allow it to accept timestamps
   in the ISO 8601 format described in RFC 3339 (e.g.,
   2023-11-30T01:02:03.456Z). Previously, it only accepted timestamps in the
   generalized time format (or a generalized time representation that didn’t
   include any time zone information, which was treated as the system’s local
   time zone).



   -

   We updated the JSONBuffer class to add an appendField method that can be
   used to append a generic field without knowing the value type. Previously,
   it only allowed you to append fields if you knew the type of the value.



   -

   We added new BinarySizeUnit and DecimalSizeUnit enums that can be used
   when dealing with a quantity of data, like the size of a file or the amount
   of information transferred over a network. Each of the enums supports a
   variety of units (bytes, kilobytes, megabytes, gigabytes, terabytes,
   petabytes, exabytes, zettabytes, and yottabytes), but the BinarySizeUnit
   variant assumes that each subsequent unit is 1024 times greater than the
   previous (e.g., one kilobyte is treated as 1024 bytes), while
   DecimalSizeUnit assumes that each subsequent unit is 1000 times greater
   than the previous (e.g., one kilobyte is treated as 1000 bytes).



   -

   We updated the client-side support for invoking the LDIF export
   administrative task in the Ping Identity Directory Server to include
   support for activating one or more post-LDIF-export task processors, which
   can be used to perform additional processing after the data is successfully
   exported.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] Dropping support for Java 7 after the upcoming 6.0.11 release

[Neil W. <nei...@pi...>]

Unless there is substantial pushback with really good reasoning behind it,
I intend to update the LDAP SDK to drop support for Java 7 after the next
release, which should be version 6.0.11 and will likely be released
sometime in December. The next release after that should be version 7.0.0
(which I suppose is an unfortunate coincidence), and it will support Java
versions 8 and higher.

Java 7 reached its end of support life (EOSL) last year, and it’s getting
harder to support newer Java versions while retaining support for Java 7.
Java 8 is currently slated to have its EOSL at the end of 2030, and there
are no plans to drop support for it in the LDAP SDK at any time in the near
future.


Neil Wilson

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.10

[Neil W. <nei...@pi...>]

We have just released version 6.0.10 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/6.0.9>.
You can find the release notes for the 6.0.10 release (and all previous
versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but
here’s a summary of the changes:


   -

   We added a new ReusableReferralConnector interface that makes it
   possible to create referral connectors that can be reused for following
   multiple referrals. We’ve added a new PooledReferralConnector
   implementation that uses connection pools for improved performance when
   following multiple referrals.



   -

   We fixed an issue in which the parallel-update tool could write
   malformed data to the reject log file when multiple write operations were
   rejected concurrently.



   -

   We added a PLAINBindRequest.encodeCredentials method that can be used to
   retrieve the encoded credentials for a SASL PLAIN bind request.



   -

   We added JSONNumber.getValueAsInteger and getValueAsLong methods that
   will return the value of a JSON number as an Integer or Long, but only
   if the conversion can be made losslessly. The methods will return null
   if the value is a floating-point number, or if the value is outside the
   supported range for the data type.



   -

   We added a StaticUtils.getBacktrace method that can be used to retrieve
   a compact, single-line string representation of a stack trace representing
   the code location from which the method was called.



   -

   We added support for a new Ping-proprietary “access log field” request
   control, which can be used to indicate that the server should include a
   specified set of name-value pairs in the access log message for the
   associated operation. We also updated the ldapsearch and ldapmodify
   tools to add a new --accessLogField argument to include this control in
   requests.



   -

   We added support for a new Ping-proprietary “generate access token”
   request control that can be included in a bind request to indicate that the
   server should include an access token in a corresponding response control
   included in the response to a successful bind operation. That access token
   can be used to authenticate to the Ping Identity Directory Server with the
   OAUTHBEARER SASL mechanism. This may be especially useful when initially
   authenticating to the Directory Server with a mechanism that relies on
   single-use credentials (e.g., UNBOUNDID-TOTP, UNBOUNDID-DELIVERED-OTP, or
   UNBOUNDID-YUBIKEY-OTP) because it allows you to establish multiple
   connections (e.g., using a connection pool or to replace connections that
   are no longer valid). We also updated the ldapsearch and ldapmodify
   tools to add a new --generateAccessToken argument to request that the
   server return an access token in the bind response.



   -

   We updated support for the ds-pwp-state-json virtual attribute to
   include the has-password-encoded-with-non-current-settings field, which
   may indicate whether the user has a password that is encoded with settings
   that are different from the current configuration for the associated
   password storage scheme, and the
   non-current-password-storage-scheme-settings-explanations field, which
   may explain the ways in which the password encoding differs from the
   current configuration.



   -

   We updated the documentation to include the latest versions of
   draft-ietf-kitten-scram-2fa, draft-melnikov-scram-bis, and
   draft-melnikov-scram-sha3-512 in the set of LDAP-related specifications.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] Minimum number of connections in the pool

[Neil W. <nei...@pi...>]

The LDAP SDK’s ability to re-establish connections that are no longer valid
depends on the ability to determine that a connection is no longer valid.
Depending on the way in which that connection has been closed, then it may
be that the LDAP SDK won’t be able to detect that a connection was closed
until the next attempt to use it.

As I mentioned, the best ways of dealing with that are to either enable
health checking so that it can detect those kinds of problems in a more
timely manner or to enable a maximum connection age in the pool so that
connections are periodically closed and re-established so that they don’t
encounter the time limit. Also, enabling automatic retry in the connection
pool can help mask these problems so that even if a connection has been
closed in a way that the LDAP SDK wasn’t able to detect, it can
transparently retry the operation in a manner that doesn’t require the
application to do anything.

There have been a lot of changes
<https://docs.ldap.com/ldap-sdk/docs/release-notes.html> since the 6.0.3
release (and it is guaranteed to be backward compatible so updating the the
LDAP SDK should only require dropping in a new jar without any changes to
your code), but I can’t think of anything off the top of my head that would
relate to its ability to detect invalid connections.

Neil


On Thu, Jul 6, 2023 at 9:42 AM mehturt <me...@pr...> wrote:

> Thank you for your response.
> So it seems there's some kind of problem somewhere, I can see that number
> of connections connected to the LDAP server seem to drop below configured
> value.  This is over time, when the connections are mostly idle; I can see
> that sometimes for example 2 connections are detected as disconnected but
> only 1 is re-connected.  And over time number of connections keep
> decreasing.  I am in fact using LDAPConnectionPool.search (not
> get/release), as you recommend.  I'm using SDK 6.0.3, were any
> fixes/improvements done in this area in more recent SDK versions?
> Thanks, m.
>
> --
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, July 6th, 2023 at 4:26 PM, Neil Wilson <
> nei...@pi...> wrote:
>
> If the LDAP SDK detects that a connection has been closed or is otherwise
> no longer valid, then it will attempt to re-establish it. This works better
> if you have configured health checking in a manner that actually attempts
> to interact with the server, but depending on how the connection closure
> occurs, it may be able to detect the closure even without special health
> checking.
>
> Also, depending on how you are using the connection pool, you can have it
> automatically retry operations on a new connection if the attempt failed in
> a manner that suggests that the initial connection may no longer be valid.
> For that to work, you need to process operations directly against the pool
> rather than manually checking out connections, processing operations, and
> releasing them back to the pool (for example, by calling
> LDAPConnectionPool.search instead of LDAPConnectionPool.getConnection,
> LDAPConnection.search, and LDAPConnectionPool.releaseConnection). You
> should also enable automatic retry using the
> LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method.
>
> Finally, if the LDAP server is configured to automatically close
> connections after they’ve been idle for a period of time, then I recommend
> that you do at least one of the following:
>
>
>    -
>
>    Enable health checking in a manner that interacts with the server (for
>    example, the GetEntryLDAPConnectionPoolHealthCheck), as this will
>    prevent the connection from being seen as idle, and will allow the LDAP SDK
>    to most quickly determine if a connection has become invalid. To minimize
>    the overhead that it imposes, you can just have it set to be used for
>    background checks. If your pool is set up to interact with multiple LDAP
>    servers, then it’s probably also helpful to have it invoked when a new
>    connection is established.
>
>
>
>    -
>
>    Configure a maximum connection age for connections in the pool using
>    the LDAPConnectionPool.setMaxConnectionAgeMillis method. This will
>    cause the pool to close and re-establish connections after they’ve been
>    established for the specified length of time so that they never reach the
>    idle time limit.
>
>
> Neil
>
>
> On Thu, Jul 6, 2023 at 1:46 AM mehturt <me...@pr...> wrote:
>
>> Thank you Neil.
>> I think this is understood. However, what about the situation where the
>> connections are closed by the remote LDAP server, e.g. for the reason of
>> being idle. Would the pool automatically re-establish those connections so
>> that the number of "active" (connected) connections never drops below
>> configured initial value? Thank you.
>> m.
>>
>> --
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Tuesday, July 4th, 2023 at 6:20 PM, Neil Wilson <
>> nei...@pi...> wrote:
>>
>> Your observation is correct. A connection pool does not ever
>> automatically remove connections from the pool.
>>
>> Whenever you create a connection pool, it will create the requested
>> initial number of connections, which may or may not be less than the
>> maximum number of connections. As long as that number of connections is
>> sufficient to handle the number of concurrent requests that it’s asked to
>> process, then it won’t ever create any more. But if it needs a connection
>> for a new request and there aren’t any already-established connections
>> immediately available, then it will do one of the following:
>>
>>
>>    -
>>
>>    If the initial number of connections was less than the maximum number
>>    of connections, and if the pool hasn’t yet created enough connections to
>>    reach the maximum, then it will create a new connection.
>>
>>
>>
>>    -
>>
>>    If the pool is configured with a nonzero maxWaitTimeMillis (it is
>>    zero by default), then it can wait for up to that length of time for an
>>    already established connection to become available.
>>
>>
>>
>>    -
>>
>>    If the pool is configured with createIfNecessary set to true (it is
>>    true by default), then it will create a new connection.
>>
>>
>> By this logic, it’s actually possible for the pool to have more than the
>> maximum number of connections established at a time. This would happen
>> under periods of heavy load when the rate of concurrent requests exceeds
>> the maximum configured number of connections. Note that if you really don’t
>> want that to happen and you’d rather have failures if a connection doesn’t
>> become available within the maxWaitTimeMillis, then you can set
>> createIfNecessary to false, and requests to acquire a connection when
>> none are available will fail.
>>
>> Where the maximum number of connections comes into play is when
>> connections are released back to the pool. If the pool’s set of connections
>> that are immediately available to be checked out is larger than the
>> maximum, then the connection being released will be discarded rather than
>> returned to the pool. So the pool will never have more than the configured
>> maximum number of connections immediately available for use, but it might
>> have more than the configured maximum established at any point in time.
>>
>> Once a connection has been established for use in the pool, the pool will
>> keep that connection around. It doesn’t do anything to automatically shrink
>> the pool because it’s very cheap to maintain connections, even if they
>> aren’t used, and because it’s much cheaper to use an already established
>> connection than to have to create a new one if none are available.
>>
>> If you do want to get rid of connections in the pool, then there are a
>> couple of options for doing that manually:
>>
>>
>>    -
>>
>>    If you want to get rid of a connection instead of releasing it back
>>    to the pool, you can use the discardConnection method. If you want to
>>    get rid of a specified number of connections, then you could operate in a
>>    loop, checking out and discarding connections until you’ve gone through
>>    that many.
>>
>>
>>
>>    -
>>
>>    If you want to shrink the pool so that it contains no more than a
>>    specified number of connections, then you can use the shrinkPool
>>    method and specify how many connections you want to retain.
>>
>>
>> But in general, there’s not a compelling reason to have the pool
>> automatically get rid of connections once they’ve been created and the
>> number of available connections is no more than the maximum allowed number
>> of connections.
>>
>> Neil Wilson
>>
>>
>> On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss <
>> lda...@li...> wrote:
>>
>>> Hello,
>>> the LDAPConnectionPool constructor has parameters initialConnections and
>>> maxConnections.
>>> I can't find any information about minimal number of connections - is
>>> initialConnections the minimal number of connections as well - meaning the
>>> pool will try to maintain at least initialConnections always? Or can the
>>> number of connections drop below initial?
>>> (This is what I'm seeing in my project, however it's not clear to me
>>> whether that's expected behavior or not).
>>> Thanks, m.
>>>
>>> --
>>>
>>>
>>> Sent with Proton Mail <https://proton.me/> secure email.
>>> _______________________________________________
>>> ldap-sdk-discuss mailing list
>>> lda...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] Minimum number of connections in the pool

[Neil W. <nei...@pi...>]

If the LDAP SDK detects that a connection has been closed or is otherwise
no longer valid, then it will attempt to re-establish it. This works better
if you have configured health checking in a manner that actually attempts
to interact with the server, but depending on how the connection closure
occurs, it may be able to detect the closure even without special health
checking.

Also, depending on how you are using the connection pool, you can have it
automatically retry operations on a new connection if the attempt failed in
a manner that suggests that the initial connection may no longer be valid.
For that to work, you need to process operations directly against the pool
rather than manually checking out connections, processing operations, and
releasing them back to the pool (for example, by calling
LDAPConnectionPool.search instead of LDAPConnectionPool.getConnection,
LDAPConnection.search, and LDAPConnectionPool.releaseConnection). You
should also enable automatic retry using the
LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method.

Finally, if the LDAP server is configured to automatically close
connections after they’ve been idle for a period of time, then I recommend
that you do at least one of the following:


   -

   Enable health checking in a manner that interacts with the server (for
   example, the GetEntryLDAPConnectionPoolHealthCheck), as this will
   prevent the connection from being seen as idle, and will allow the LDAP SDK
   to most quickly determine if a connection has become invalid. To minimize
   the overhead that it imposes, you can just have it set to be used for
   background checks. If your pool is set up to interact with multiple LDAP
   servers, then it’s probably also helpful to have it invoked when a new
   connection is established.



   -

   Configure a maximum connection age for connections in the pool using the
   LDAPConnectionPool.setMaxConnectionAgeMillis method. This will cause the
   pool to close and re-establish connections after they’ve been established
   for the specified length of time so that they never reach the idle time
   limit.


Neil


On Thu, Jul 6, 2023 at 1:46 AM mehturt <me...@pr...> wrote:

> Thank you Neil.
> I think this is understood. However, what about the situation where the
> connections are closed by the remote LDAP server, e.g. for the reason of
> being idle.  Would the pool automatically re-establish those connections so
> that the number of "active" (connected) connections never drops below
> configured initial value? Thank you.
> m.
>
> --
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Tuesday, July 4th, 2023 at 6:20 PM, Neil Wilson <
> nei...@pi...> wrote:
>
> Your observation is correct. A connection pool does not ever automatically
> remove connections from the pool.
>
> Whenever you create a connection pool, it will create the requested
> initial number of connections, which may or may not be less than the
> maximum number of connections. As long as that number of connections is
> sufficient to handle the number of concurrent requests that it’s asked to
> process, then it won’t ever create any more. But if it needs a connection
> for a new request and there aren’t any already-established connections
> immediately available, then it will do one of the following:
>
>
>    -
>
>    If the initial number of connections was less than the maximum number
>    of connections, and if the pool hasn’t yet created enough connections to
>    reach the maximum, then it will create a new connection.
>
>
>
>    -
>
>    If the pool is configured with a nonzero maxWaitTimeMillis (it is zero
>    by default), then it can wait for up to that length of time for an already
>    established connection to become available.
>
>
>
>    -
>
>    If the pool is configured with createIfNecessary set to true (it is
>    true by default), then it will create a new connection.
>
>
> By this logic, it’s actually possible for the pool to have more than the
> maximum number of connections established at a time. This would happen
> under periods of heavy load when the rate of concurrent requests exceeds
> the maximum configured number of connections. Note that if you really don’t
> want that to happen and you’d rather have failures if a connection doesn’t
> become available within the maxWaitTimeMillis, then you can set
> createIfNecessary to false, and requests to acquire a connection when
> none are available will fail.
>
> Where the maximum number of connections comes into play is when
> connections are released back to the pool. If the pool’s set of connections
> that are immediately available to be checked out is larger than the
> maximum, then the connection being released will be discarded rather than
> returned to the pool. So the pool will never have more than the configured
> maximum number of connections immediately available for use, but it might
> have more than the configured maximum established at any point in time.
>
> Once a connection has been established for use in the pool, the pool will
> keep that connection around. It doesn’t do anything to automatically shrink
> the pool because it’s very cheap to maintain connections, even if they
> aren’t used, and because it’s much cheaper to use an already established
> connection than to have to create a new one if none are available.
>
> If you do want to get rid of connections in the pool, then there are a
> couple of options for doing that manually:
>
>
>    -
>
>    If you want to get rid of a connection instead of releasing it back to
>    the pool, you can use the discardConnection method. If you want to get
>    rid of a specified number of connections, then you could operate in a loop,
>    checking out and discarding connections until you’ve gone through that many.
>
>
>
>    -
>
>    If you want to shrink the pool so that it contains no more than a
>    specified number of connections, then you can use the shrinkPool
>    method and specify how many connections you want to retain.
>
>
> But in general, there’s not a compelling reason to have the pool
> automatically get rid of connections once they’ve been created and the
> number of available connections is no more than the maximum allowed number
> of connections.
>
> Neil Wilson
>
>
> On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss <
> lda...@li...> wrote:
>
>> Hello,
>> the LDAPConnectionPool constructor has parameters initialConnections and
>> maxConnections.
>> I can't find any information about minimal number of connections - is
>> initialConnections the minimal number of connections as well - meaning the
>> pool will try to maintain at least initialConnections always? Or can the
>> number of connections drop below initial?
>> (This is what I'm seeing in my project, however it's not clear to me
>> whether that's expected behavior or not).
>> Thanks, m.
>>
>> --
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>> _______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] Minimum number of connections in the pool

[mehturt <me...@pr...>]

Thank you for your response.
So it seems there's some kind of problem somewhere, I can see that number of connections connected to the LDAP server seem to drop below configured value. This is over time, when the connections are mostly idle; I can see that sometimes for example 2 connections are detected as disconnected but only 1 is re-connected. And over time number of connections keep decreasing. I am in fact using LDAPConnectionPool.search (not get/release), as you recommend. I'm using SDK 6.0.3, were any fixes/improvements done in this area in more recent SDK versions?
Thanks, m.

--

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Thursday, July 6th, 2023 at 4:26 PM, Neil Wilson <nei...@pi...> wrote:

> If the LDAP SDK detects that a connection has been closed or is otherwise no longer valid, then it will attempt to re-establish it. This works better if you have configured health checking in a manner that actually attempts to interact with the server, but depending on how the connection closure occurs, it may be able to detect the closure even without special health checking.
>
> Also, depending on how you are using the connection pool, you can have it automatically retry operations on a new connection if the attempt failed in a manner that suggests that the initial connection may no longer be valid. For that to work, you need to process operations directly against the pool rather than manually checking out connections, processing operations, and releasing them back to the pool (for example, by calling LDAPConnectionPool.search instead of LDAPConnectionPool.getConnection, LDAPConnection.search, and LDAPConnectionPool.releaseConnection). You should also enable automatic retry using the LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method.
>
> Finally, if the LDAP server is configured to automatically close connections after they’ve been idle for a period of time, then I recommend that you do at least one of the following:
>
> -
>
> Enable health checking in a manner that interacts with the server (for example, the GetEntryLDAPConnectionPoolHealthCheck), as this will prevent the connection from being seen as idle, and will allow the LDAP SDK to most quickly determine if a connection has become invalid. To minimize the overhead that it imposes, you can just have it set to be used for background checks. If your pool is set up to interact with multiple LDAP servers, then it’s probably also helpful to have it invoked when a new connection is established.
>
> -
>
> Configure a maximum connection age for connections in the pool using the LDAPConnectionPool.setMaxConnectionAgeMillis method. This will cause the pool to close and re-establish connections after they’ve been established for the specified length of time so that they never reach the idle time limit.
>
> Neil
>
> On Thu, Jul 6, 2023 at 1:46 AM mehturt <me...@pr...> wrote:
>
>> Thank you Neil.
>> I think this is understood. However, what about the situation where the connections are closed by the remote LDAP server, e.g. for the reason of being idle. Would the pool automatically re-establish those connections so that the number of "active" (connected) connections never drops below configured initial value? Thank you.
>> m.
>>
>> --
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ------- Original Message -------
>> On Tuesday, July 4th, 2023 at 6:20 PM, Neil Wilson <nei...@pi...> wrote:
>>
>>> Your observation is correct. A connection pool does not ever automatically remove connections from the pool.
>>>
>>> Whenever you create a connection pool, it will create the requested initial number of connections, which may or may not be less than the maximum number of connections. As long as that number of connections is sufficient to handle the number of concurrent requests that it’s asked to process, then it won’t ever create any more. But if it needs a connection for a new request and there aren’t any already-established connections immediately available, then it will do one of the following:
>>>
>>> -
>>>
>>> If the initial number of connections was less than the maximum number of connections, and if the pool hasn’t yet created enough connections to reach the maximum, then it will create a new connection.
>>>
>>> -
>>>
>>> If the pool is configured with a nonzero maxWaitTimeMillis (it is zero by default), then it can wait for up to that length of time for an already established connection to become available.
>>>
>>> -
>>>
>>> If the pool is configured with createIfNecessary set to true (it is true by default), then it will create a new connection.
>>>
>>> By this logic, it’s actually possible for the pool to have more than the maximum number of connections established at a time. This would happen under periods of heavy load when the rate of concurrent requests exceeds the maximum configured number of connections. Note that if you really don’t want that to happen and you’d rather have failures if a connection doesn’t become available within the maxWaitTimeMillis, then you can set createIfNecessary to false, and requests to acquire a connection when none are available will fail.
>>>
>>> Where the maximum number of connections comes into play is when connections are released back to the pool. If the pool’s set of connections that are immediately available to be checked out is larger than the maximum, then the connection being released will be discarded rather than returned to the pool. So the pool will never have more than the configured maximum number of connections immediately available for use, but it might have more than the configured maximum established at any point in time.
>>>
>>> Once a connection has been established for use in the pool, the pool will keep that connection around. It doesn’t do anything to automatically shrink the pool because it’s very cheap to maintain connections, even if they aren’t used, and because it’s much cheaper to use an already established connection than to have to create a new one if none are available.
>>>
>>> If you do want to get rid of connections in the pool, then there are a couple of options for doing that manually:
>>>
>>> -
>>>
>>> If you want to get rid of a connection instead of releasing it back to the pool, you can use the discardConnection method. If you want to get rid of a specified number of connections, then you could operate in a loop, checking out and discarding connections until you’ve gone through that many.
>>>
>>> -
>>>
>>> If you want to shrink the pool so that it contains no more than a specified number of connections, then you can use the shrinkPool method and specify how many connections you want to retain.
>>>
>>> But in general, there’s not a compelling reason to have the pool automatically get rid of connections once they’ve been created and the number of available connections is no more than the maximum allowed number of connections.
>>>
>>> Neil Wilson
>>>
>>> On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss <lda...@li...> wrote:
>>>
>>>> Hello,
>>>> the LDAPConnectionPool constructor has parameters initialConnections and maxConnections.
>>>> I can't find any information about minimal number of connections - is initialConnections the minimal number of connections as well - meaning the pool will try to maintain at least initialConnections always? Or can the number of connections drop below initial?
>>>> (This is what I'm seeing in my project, however it's not clear to me whether that's expected behavior or not).
>>>> Thanks, m.
>>>>
>>>> --
>>>>
>>>> Sent with [Proton Mail](https://proton.me/) secure email.
>>>> _______________________________________________
>>>> ldap-sdk-discuss mailing list
>>>> lda...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Re: [ldap-sdk-discuss] Minimum number of connections in the pool

[mehturt <me...@pr...>]

Thank you Neil.
I think this is understood. However, what about the situation where the connections are closed by the remote LDAP server, e.g. for the reason of being idle. Would the pool automatically re-establish those connections so that the number of "active" (connected) connections never drops below configured initial value? Thank you.
m.

--

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Tuesday, July 4th, 2023 at 6:20 PM, Neil Wilson <nei...@pi...> wrote:

> Your observation is correct. A connection pool does not ever automatically remove connections from the pool.
>
> Whenever you create a connection pool, it will create the requested initial number of connections, which may or may not be less than the maximum number of connections. As long as that number of connections is sufficient to handle the number of concurrent requests that it’s asked to process, then it won’t ever create any more. But if it needs a connection for a new request and there aren’t any already-established connections immediately available, then it will do one of the following:
>
> -
>
> If the initial number of connections was less than the maximum number of connections, and if the pool hasn’t yet created enough connections to reach the maximum, then it will create a new connection.
>
> -
>
> If the pool is configured with a nonzero maxWaitTimeMillis (it is zero by default), then it can wait for up to that length of time for an already established connection to become available.
>
> -
>
> If the pool is configured with createIfNecessary set to true (it is true by default), then it will create a new connection.
>
> By this logic, it’s actually possible for the pool to have more than the maximum number of connections established at a time. This would happen under periods of heavy load when the rate of concurrent requests exceeds the maximum configured number of connections. Note that if you really don’t want that to happen and you’d rather have failures if a connection doesn’t become available within the maxWaitTimeMillis, then you can set createIfNecessary to false, and requests to acquire a connection when none are available will fail.
>
> Where the maximum number of connections comes into play is when connections are released back to the pool. If the pool’s set of connections that are immediately available to be checked out is larger than the maximum, then the connection being released will be discarded rather than returned to the pool. So the pool will never have more than the configured maximum number of connections immediately available for use, but it might have more than the configured maximum established at any point in time.
>
> Once a connection has been established for use in the pool, the pool will keep that connection around. It doesn’t do anything to automatically shrink the pool because it’s very cheap to maintain connections, even if they aren’t used, and because it’s much cheaper to use an already established connection than to have to create a new one if none are available.
>
> If you do want to get rid of connections in the pool, then there are a couple of options for doing that manually:
>
> -
>
> If you want to get rid of a connection instead of releasing it back to the pool, you can use the discardConnection method. If you want to get rid of a specified number of connections, then you could operate in a loop, checking out and discarding connections until you’ve gone through that many.
>
> -
>
> If you want to shrink the pool so that it contains no more than a specified number of connections, then you can use the shrinkPool method and specify how many connections you want to retain.
>
> But in general, there’s not a compelling reason to have the pool automatically get rid of connections once they’ve been created and the number of available connections is no more than the maximum allowed number of connections.
>
> Neil Wilson
>
> On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss <lda...@li...> wrote:
>
>> Hello,
>> the LDAPConnectionPool constructor has parameters initialConnections and maxConnections.
>> I can't find any information about minimal number of connections - is initialConnections the minimal number of connections as well - meaning the pool will try to maintain at least initialConnections always? Or can the number of connections drop below initial?
>> (This is what I'm seeing in my project, however it's not clear to me whether that's expected behavior or not).
>> Thanks, m.
>>
>> --
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>> _______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Re: [ldap-sdk-discuss] Minimum number of connections in the pool

[Neil W. <nei...@pi...>]

Your observation is correct. A connection pool does not ever automatically
remove connections from the pool.

Whenever you create a connection pool, it will create the requested initial
number of connections, which may or may not be less than the maximum number
of connections. As long as that number of connections is sufficient to
handle the number of concurrent requests that it’s asked to process, then
it won’t ever create any more. But if it needs a connection for a new
request and there aren’t any already-established connections immediately
available, then it will do one of the following:


   -

   If the initial number of connections was less than the maximum number of
   connections, and if the pool hasn’t yet created enough connections to reach
   the maximum, then it will create a new connection.



   -

   If the pool is configured with a nonzero maxWaitTimeMillis (it is zero
   by default), then it can wait for up to that length of time for an already
   established connection to become available.



   -

   If the pool is configured with createIfNecessary set to true (it is true
   by default), then it will create a new connection.


By this logic, it’s actually possible for the pool to have more than the
maximum number of connections established at a time. This would happen
under periods of heavy load when the rate of concurrent requests exceeds
the maximum configured number of connections. Note that if you really don’t
want that to happen and you’d rather have failures if a connection doesn’t
become available within the maxWaitTimeMillis, then you can set
createIfNecessary to false, and requests to acquire a connection when none
are available will fail.

Where the maximum number of connections comes into play is when connections
are released back to the pool. If the pool’s set of connections that are
immediately available to be checked out is larger than the maximum, then
the connection being released will be discarded rather than returned to the
pool. So the pool will never have more than the configured maximum number
of connections immediately available for use, but it might have more than
the configured maximum established at any point in time.

Once a connection has been established for use in the pool, the pool will
keep that connection around. It doesn’t do anything to automatically shrink
the pool because it’s very cheap to maintain connections, even if they
aren’t used, and because it’s much cheaper to use an already established
connection than to have to create a new one if none are available.

If you do want to get rid of connections in the pool, then there are a
couple of options for doing that manually:


   -

   If you want to get rid of a connection instead of releasing it back to
   the pool, you can use the discardConnection method. If you want to get
   rid of a specified number of connections, then you could operate in a loop,
   checking out and discarding connections until you’ve gone through that many.



   -

   If you want to shrink the pool so that it contains no more than a
   specified number of connections, then you can use the shrinkPool method
   and specify how many connections you want to retain.


But in general, there’s not a compelling reason to have the pool
automatically get rid of connections once they’ve been created and the
number of available connections is no more than the maximum allowed number
of connections.

Neil Wilson


On Tue, Jul 4, 2023 at 10:54 AM mehturt via ldap-sdk-discuss <
lda...@li...> wrote:

> Hello,
> the LDAPConnectionPool constructor has parameters initialConnections and
> maxConnections.
> I can't find any information about minimal number of connections - is
> initialConnections the minimal number of connections as well - meaning the
> pool will try to maintain at least initialConnections always? Or can the
> number of connections drop below initial?
> (This is what I'm seeing in my project, however it's not clear to me
> whether that's expected behavior or not).
> Thanks, m.
>
> --
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] Minimum number of connections in the pool

[mehturt <me...@pr...>]

Hello,
the LDAPConnectionPool constructor has parameters initialConnections and maxConnections.
I can't find any information about minimal number of connections - is initialConnections the minimal number of connections as well - meaning the pool will try to maintain at least initialConnections always? Or can the number of connections drop below initial?
(This is what I'm seeing in my project, however it's not clear to me whether that's expected behavior or not).
Thanks, m.

--

Sent with [Proton Mail](https://proton.me/) secure email.

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.9

[Neil W. <nei...@pi...>]

We have just released version 6.0.9 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/6.0.9>
.

As announced in the previous release, the LDAP SDK source code is now
maintained only at GitHub. The SourceForge repository is still available
for its discussion forum
<https://sourceforge.net/p/ldap-sdk/discussion/1001257/>, mailing lists
<https://sourceforge.net/p/ldap-sdk/mailman/>, and release downloads
<https://sourceforge.net/projects/ldap-sdk/files/>, but the source code is
no longer available there.

You can find the release notes for the 6.0.9 release (and all previous
versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but
here’s a summary of the changes:


   -

   We made it possible to customize the set of result codes that the LDAP
   SDK uses to determine whether a connection may no longer be usable.
   Previously, we used a hard-coded set of result codes, and that is still the
   default, but you can now override that using the
   ResultCode.setConnectionNotUsableResultCodes method.



   -

   We added a new HTTPProxySocketFactory class that can be used to
   establish LDAP and LDAPS connections through an HTTP proxy server.



   -

   We added a new SOCKSProxySocketFactory class that can be used to
   establish LDAP and LDAPS connections through a SOCKSv4 or SOCKSv5 proxy
   server.



   -

   We updated the ldap-diff tool to add a --byteForByte argument that can
   be used to indicate that it should use a byte-for-byte comparison when
   determining whether two attribute values are equivalent rather than using a
   schema-aware comparison (which may ignore insignificant differences in some
   cases, like differences in capitalization or extra spaces). Previously, the
   tool always used byte-for-byte matching, but we decided to make it a
   configurable option, and we determined that it is better to use
   schema-aware comparison by default.



   -

   We fixed an issue in which a non-default channel binding type was not
   preserved when duplicating a GSSAPI bind request. We also added a
   GSSAPIBindRequest.getChannelBindingType method to retrieve the selected
   channel binding type for a GSSAPI bind request.



   -

   We added a ResultCode.getStandardName method that can be used to
   retrieve the name for the result code in a form that is used to reference
   it in standards documents.  Note that this may not be available for result
   codes that are not defined in known specifications.



   -

   We added a mechanism for caching the derived secret keys used for
   passphrase-encrypted input and output streams so that it is no longer
   necessary to re-derive the same key each time it is used. This can
   dramatically improve performance when the same key is used multiple times.



   -

   We updated the StaticUtils.isLikelyDisplayableCharacter method to
   consider additional character types to be displayable, including modifier
   symbols, non-spacing marks, enclosing marks, and combining spacing marks.



   -

   We added a new StaticUtils.getCodePoints method that can be used to
   retrieve an array of the code points that comprise a given string.



   -

   We added a new StaticUtils.unicodeStringsAreEquivalent method that can
   be used to determine whether two strings represent an equivalent string of
   Unicode characters, even if they use different forms of Unicode
   normalization.



   -

   We added a new StaticUtils.utf8StringsAreEquivalent method that can be
   used to determine whether two byte arrays represent an equivalent UTF-8
   string of Unicode characters, even if they use different forms of Unicode
   normalization.



   -

   We added a new StaticUtils.isValidUTF8WithNonASCIICharacters method that
   can be used to determine whether a given byte array represents a valid
   UTF-8 string that contains at least one non-ASCII character.



   -

   We updated the client-side support for the collect-support-data
   administrative task to make it possible to specify the start and end times
   for the set of log messages to include in the support data archive.



   -

   We updated the documentation so that the latest versions of
   draft-melnikov-sasl2 and draft-melnikov-scram-sha-512 are included in the
   set of LDAP-related specifications.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] MD5 Authentication

[Neil W. <nei...@pi...>]

The only SASL mechanism handler provided as part of the LDAP SDK itself is
the PLAINBindHandler
<https://github.com/pingidentity/ldapsdk/blob/master/src/com/unboundid/ldap/listener/PLAINBindHandler.java>
class. However, there are a couple of additional implementations in the
unit test framework, and the TestSCRAMSHA1InMemorySASLBindHandler
<https://github.com/pingidentity/ldapsdk/blob/master/tests/unit/src/com/unboundid/ldap/sdk/TestSCRAMSHA1InMemorySASLBindHandler.java>
class would be the closest example we have to DIGEST-MD5 authentication
because it uses a multi-stage process with state preserved across both
phases of the bind processing.

Neil Wilson




On Wed, May 3, 2023 at 11:05 AM Andrei Petru Mura <map...@gm...>
wrote:

> Hi Neil,
>
> I tried to implement it, and I saw that it's not working, only returning
> success. Why this? Do you have any examples of
> custom InMemorySASLBindHandler?
>
> Thanks,
> Andrei Mura
>
> On Wed, May 3, 2023 at 5:24 PM Neil Wilson <nei...@pi...>
> wrote:
>
>> The in-memory directory server does not support the DIGEST-MD5 SASL
>> mechanism. As per RFC 6331 <https://docs.ldap.com/specs/rfc6331.txt>,
>> DIGEST-MD5 was officially declared obsolete and not suitable for continued
>> use nearly a dozen years ago, so we don’t intend to implement support for
>> it.
>>
>> If you really need it in the in-memory directory server, you’re free to
>> implement that support for yourself by creating a custom
>> InMemorySASLBindHandler, but the nature of the DIGEST-MD5 authentication
>> process means that it’s not really feasible to fake the authentication
>> (e.g., by just returning SUCCESS in response to any attempt), so you’d have
>> to actually implement the mechanism.
>>
>> Neil Wilson
>>
>>
>> On Wed, May 3, 2023 at 3:32 AM Andrei Petru Mura <map...@gm...>
>> wrote:
>>
>>> Hello Neil,
>>>
>>> Thanks for great and knowledgeable insight.
>>>
>>> 1. I want to test MD5-DIGEST SASL mechanism against an unbound InMemory
>>> LDAP server (this is performed during the JUnit tests). In order to do
>>> this, I want to configure the server to support MD5 - it seems to me it
>>> doesn't by default - am I wrong?
>>> 2. As a client, I want to use Java's provided API, other than the
>>> unboundID API. For this, according to the documentation, it says so:
>>>
>>> To use the Digest-MD5 authentication mechanism, you must set the
>>> authentication environment properties as follows.
>>> Context.SECURITY_AUTHENTICATION
>>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_AUTHENTICATION>
>>> .Set to the string "DIGEST-MD5".Context.SECURITY_PRINCIPAL
>>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_PRINCIPAL>
>>> .Set to the principal name. This is a server-specific format. Some
>>> servers support a login user id format, such as that defined for UNIX or
>>> Windows login screens. Others accept a distinguished name. Yet others use
>>> the authorization id formats defined in RFC 2829
>>> <http://www.ietf.org/rfc/rfc2829.txt>. In that RFC, the name should be
>>> either the string "dn:", followed by the fully qualified DN of the
>>> entity being authenticated, or the string "u:", followed by the user
>>> id. Some servers accept multiple formats. Examples of some of these formats
>>> are "cuser", "dn: cn=C. User, ou=NewHires, o=JNDITutorial", and "u:
>>> cuser" The data type of this property must be java.lang.String.
>>> Context.SECURITY_CREDENTIALS
>>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_CREDENTIALS>
>>> .Set to the password of the principal (for example, "mysecret"). It is
>>> of type java.lang.String, char array (char[]), or byte array (byte[]).
>>> If the password is a java.lang.String or char[], then it is encoded by
>>> using UTF-8 for transmission to the server. If the password is a byte[],
>>> then it is transmitted as is to the server.
>>>
>>> The following example
>>> <https://docs.oracle.com/javase/tutorial/jndi/ldap/examples/Digest.java> shows
>>> how a client performs authentication using Digest-MD5 to an LDAP server.
>>>
>>> // Set up the environment for creating the initial context
>>> Hashtable<String, Object> env = new Hashtable<String, Object>();
>>> env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
>>> env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");
>>>
>>> // Authenticate as C. User and password "mysecret"
>>> env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
>>> env.put(Context.SECURITY_PRINCIPAL,
>>>         "dn:cn=C. User, ou=NewHires, o=JNDITutorial");
>>> env.put(Context.SECURITY_CREDENTIALS, "mysecret");
>>>
>>> // Create the initial context
>>> DirContext ctx = new InitialDirContext(env);
>>>
>>>
>>> source: https://docs.oracle.com/javase/tutorial/jndi/ldap/digest.html
>>>
>>>
>>> N.B. The DIGESTMD5BindRequest <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html> seems to provide guidance for the client's API, not for the server's.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei Mura
>>>
>>>
>>> On Tue, May 2, 2023 at 5:42 PM Neil Wilson via ldap-sdk-discuss <
>>> lda...@li...> wrote:
>>>
>>>> Could you please clarify what you mean by MD5 authentication?
>>>>
>>>> Do you mean the DIGEST-MD5 or CRAM-MD5 SASL mechanisms? If so, then the
>>>> LDAP SDK does support them through the DIGESTMD5BindRequest
>>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
>>>> and CRAMMD5BindRequest
>>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/CRAMMD5BindRequest.html>
>>>> classes, respectively, and the Javadoc documentation for each class does
>>>> provide a short example that demonstrates how to use them. However, both of
>>>> these authentication mechanisms are considered insecure for a couple of key
>>>> reasons:
>>>>
>>>>
>>>>    -
>>>>
>>>>    They rely on the MD5 digest algorithm, which is now considered very
>>>>    weak and should no longer be used.
>>>>    -
>>>>
>>>>    They require the server to store the password in a reversible
>>>>    format, which makes it more vulnerable to compromise than other types of
>>>>    authentication that work with passwords stored in non-reversible form.
>>>>
>>>>
>>>> In this case, if the server supports it, then one of the SCRAM
>>>> authentication methods (e.g., using SCRAMSHA256BindRequest
>>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA256BindRequest.html>
>>>> or SCRAMSHA512BindRequest
>>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA512BindRequest.html>)
>>>> would be a better choice because that relies on a stronger digest algorithm
>>>> and makes it possible for the server to store passwords in a non-reversible
>>>> form (albeit one that is tied to that particular authentication mechanism).
>>>>
>>>> If you’re asking about some other type of authentication that relies on
>>>> the MD5 digest, then please provide more information. However, the LDAP SDK
>>>> probably doesn’t support it, and you really shouldn’t be using anything
>>>> that relies on the MD5 digest.
>>>>
>>>> Neil Wilson
>>>>
>>>>
>>>> On Tue, May 2, 2023 at 8:29 AM Andrei Petru Mura <map...@gm...>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> Is there an example on how to enable MD5 authentication for UnboundID
>>>>> on Java and how to perform it from the client side?
>>>>>
>>>>> Thanks,
>>>>> Andrei Mura
>>>>> _______________________________________________
>>>>> ldap-sdk-discuss mailing list
>>>>> lda...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>>>
>>>>
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>> If you have received this communication in error, please notify the sender
>>>> immediately by e-mail and delete the message and any file attachments from
>>>> your computer. Thank you.*
>>>> _______________________________________________
>>>> ldap-sdk-discuss mailing list
>>>> lda...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>>
>>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] MD5 Authentication

[Andrei P. M. <map...@gm...>]

Hi Neil,

I tried to implement it, and I saw that it's not working, only returning
success. Why this? Do you have any examples of
custom InMemorySASLBindHandler?

Thanks,
Andrei Mura

On Wed, May 3, 2023 at 5:24 PM Neil Wilson <nei...@pi...>
wrote:

> The in-memory directory server does not support the DIGEST-MD5 SASL
> mechanism. As per RFC 6331 <https://docs.ldap.com/specs/rfc6331.txt>,
> DIGEST-MD5 was officially declared obsolete and not suitable for continued
> use nearly a dozen years ago, so we don’t intend to implement support for
> it.
>
> If you really need it in the in-memory directory server, you’re free to
> implement that support for yourself by creating a custom
> InMemorySASLBindHandler, but the nature of the DIGEST-MD5 authentication
> process means that it’s not really feasible to fake the authentication
> (e.g., by just returning SUCCESS in response to any attempt), so you’d have
> to actually implement the mechanism.
>
> Neil Wilson
>
>
> On Wed, May 3, 2023 at 3:32 AM Andrei Petru Mura <map...@gm...>
> wrote:
>
>> Hello Neil,
>>
>> Thanks for great and knowledgeable insight.
>>
>> 1. I want to test MD5-DIGEST SASL mechanism against an unbound InMemory
>> LDAP server (this is performed during the JUnit tests). In order to do
>> this, I want to configure the server to support MD5 - it seems to me it
>> doesn't by default - am I wrong?
>> 2. As a client, I want to use Java's provided API, other than the
>> unboundID API. For this, according to the documentation, it says so:
>>
>> To use the Digest-MD5 authentication mechanism, you must set the
>> authentication environment properties as follows.
>> Context.SECURITY_AUTHENTICATION
>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_AUTHENTICATION>
>> .Set to the string "DIGEST-MD5".Context.SECURITY_PRINCIPAL
>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_PRINCIPAL>
>> .Set to the principal name. This is a server-specific format. Some
>> servers support a login user id format, such as that defined for UNIX or
>> Windows login screens. Others accept a distinguished name. Yet others use
>> the authorization id formats defined in RFC 2829
>> <http://www.ietf.org/rfc/rfc2829.txt>. In that RFC, the name should be
>> either the string "dn:", followed by the fully qualified DN of the
>> entity being authenticated, or the string "u:", followed by the user id.
>> Some servers accept multiple formats. Examples of some of these formats are
>> "cuser", "dn: cn=C. User, ou=NewHires, o=JNDITutorial", and "u: cuser" The
>> data type of this property must be java.lang.String.
>> Context.SECURITY_CREDENTIALS
>> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_CREDENTIALS>
>> .Set to the password of the principal (for example, "mysecret"). It is
>> of type java.lang.String, char array (char[]), or byte array (byte[]).
>> If the password is a java.lang.String or char[], then it is encoded by
>> using UTF-8 for transmission to the server. If the password is a byte[],
>> then it is transmitted as is to the server.
>>
>> The following example
>> <https://docs.oracle.com/javase/tutorial/jndi/ldap/examples/Digest.java> shows
>> how a client performs authentication using Digest-MD5 to an LDAP server.
>>
>> // Set up the environment for creating the initial context
>> Hashtable<String, Object> env = new Hashtable<String, Object>();
>> env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
>> env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");
>>
>> // Authenticate as C. User and password "mysecret"
>> env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
>> env.put(Context.SECURITY_PRINCIPAL,
>>         "dn:cn=C. User, ou=NewHires, o=JNDITutorial");
>> env.put(Context.SECURITY_CREDENTIALS, "mysecret");
>>
>> // Create the initial context
>> DirContext ctx = new InitialDirContext(env);
>>
>>
>> source: https://docs.oracle.com/javase/tutorial/jndi/ldap/digest.html
>>
>>
>> N.B. The DIGESTMD5BindRequest <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html> seems to provide guidance for the client's API, not for the server's.
>>
>>
>> Thanks,
>>
>> Andrei Mura
>>
>>
>> On Tue, May 2, 2023 at 5:42 PM Neil Wilson via ldap-sdk-discuss <
>> lda...@li...> wrote:
>>
>>> Could you please clarify what you mean by MD5 authentication?
>>>
>>> Do you mean the DIGEST-MD5 or CRAM-MD5 SASL mechanisms? If so, then the
>>> LDAP SDK does support them through the DIGESTMD5BindRequest
>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
>>> and CRAMMD5BindRequest
>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/CRAMMD5BindRequest.html>
>>> classes, respectively, and the Javadoc documentation for each class does
>>> provide a short example that demonstrates how to use them. However, both of
>>> these authentication mechanisms are considered insecure for a couple of key
>>> reasons:
>>>
>>>
>>>    -
>>>
>>>    They rely on the MD5 digest algorithm, which is now considered very
>>>    weak and should no longer be used.
>>>    -
>>>
>>>    They require the server to store the password in a reversible
>>>    format, which makes it more vulnerable to compromise than other types of
>>>    authentication that work with passwords stored in non-reversible form.
>>>
>>>
>>> In this case, if the server supports it, then one of the SCRAM
>>> authentication methods (e.g., using SCRAMSHA256BindRequest
>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA256BindRequest.html>
>>> or SCRAMSHA512BindRequest
>>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA512BindRequest.html>)
>>> would be a better choice because that relies on a stronger digest algorithm
>>> and makes it possible for the server to store passwords in a non-reversible
>>> form (albeit one that is tied to that particular authentication mechanism).
>>>
>>> If you’re asking about some other type of authentication that relies on
>>> the MD5 digest, then please provide more information. However, the LDAP SDK
>>> probably doesn’t support it, and you really shouldn’t be using anything
>>> that relies on the MD5 digest.
>>>
>>> Neil Wilson
>>>
>>>
>>> On Tue, May 2, 2023 at 8:29 AM Andrei Petru Mura <map...@gm...>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> Is there an example on how to enable MD5 authentication for UnboundID
>>>> on Java and how to perform it from the client side?
>>>>
>>>> Thanks,
>>>> Andrei Mura
>>>> _______________________________________________
>>>> ldap-sdk-discuss mailing list
>>>> lda...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>> _______________________________________________
>>> ldap-sdk-discuss mailing list
>>> lda...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

Re: [ldap-sdk-discuss] MD5 Authentication

[Neil W. <nei...@pi...>]

The in-memory directory server does not support the DIGEST-MD5 SASL
mechanism. As per RFC 6331 <https://docs.ldap.com/specs/rfc6331.txt>,
DIGEST-MD5 was officially declared obsolete and not suitable for continued
use nearly a dozen years ago, so we don’t intend to implement support for
it.

If you really need it in the in-memory directory server, you’re free to
implement that support for yourself by creating a custom
InMemorySASLBindHandler, but the nature of the DIGEST-MD5 authentication
process means that it’s not really feasible to fake the authentication
(e.g., by just returning SUCCESS in response to any attempt), so you’d have
to actually implement the mechanism.

Neil Wilson


On Wed, May 3, 2023 at 3:32 AM Andrei Petru Mura <map...@gm...>
wrote:

> Hello Neil,
>
> Thanks for great and knowledgeable insight.
>
> 1. I want to test MD5-DIGEST SASL mechanism against an unbound InMemory
> LDAP server (this is performed during the JUnit tests). In order to do
> this, I want to configure the server to support MD5 - it seems to me it
> doesn't by default - am I wrong?
> 2. As a client, I want to use Java's provided API, other than the
> unboundID API. For this, according to the documentation, it says so:
>
> To use the Digest-MD5 authentication mechanism, you must set the
> authentication environment properties as follows.
> Context.SECURITY_AUTHENTICATION
> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_AUTHENTICATION>
> .Set to the string "DIGEST-MD5".Context.SECURITY_PRINCIPAL
> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_PRINCIPAL>
> .Set to the principal name. This is a server-specific format. Some
> servers support a login user id format, such as that defined for UNIX or
> Windows login screens. Others accept a distinguished name. Yet others use
> the authorization id formats defined in RFC 2829
> <http://www.ietf.org/rfc/rfc2829.txt>. In that RFC, the name should be
> either the string "dn:", followed by the fully qualified DN of the entity
> being authenticated, or the string "u:", followed by the user id. Some
> servers accept multiple formats. Examples of some of these formats are
> "cuser", "dn: cn=C. User, ou=NewHires, o=JNDITutorial", and "u: cuser" The
> data type of this property must be java.lang.String.
> Context.SECURITY_CREDENTIALS
> <https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_CREDENTIALS>
> .Set to the password of the principal (for example, "mysecret"). It is of
> type java.lang.String, char array (char[]), or byte array (byte[]). If
> the password is a java.lang.String or char[], then it is encoded by using
> UTF-8 for transmission to the server. If the password is a byte[], then
> it is transmitted as is to the server.
>
> The following example
> <https://docs.oracle.com/javase/tutorial/jndi/ldap/examples/Digest.java> shows
> how a client performs authentication using Digest-MD5 to an LDAP server.
>
> // Set up the environment for creating the initial context
> Hashtable<String, Object> env = new Hashtable<String, Object>();
> env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");
>
> // Authenticate as C. User and password "mysecret"
> env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
> env.put(Context.SECURITY_PRINCIPAL,
>         "dn:cn=C. User, ou=NewHires, o=JNDITutorial");
> env.put(Context.SECURITY_CREDENTIALS, "mysecret");
>
> // Create the initial context
> DirContext ctx = new InitialDirContext(env);
>
>
> source: https://docs.oracle.com/javase/tutorial/jndi/ldap/digest.html
>
>
> N.B. The DIGESTMD5BindRequest <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html> seems to provide guidance for the client's API, not for the server's.
>
>
> Thanks,
>
> Andrei Mura
>
>
> On Tue, May 2, 2023 at 5:42 PM Neil Wilson via ldap-sdk-discuss <
> lda...@li...> wrote:
>
>> Could you please clarify what you mean by MD5 authentication?
>>
>> Do you mean the DIGEST-MD5 or CRAM-MD5 SASL mechanisms? If so, then the
>> LDAP SDK does support them through the DIGESTMD5BindRequest
>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
>> and CRAMMD5BindRequest
>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/CRAMMD5BindRequest.html>
>> classes, respectively, and the Javadoc documentation for each class does
>> provide a short example that demonstrates how to use them. However, both of
>> these authentication mechanisms are considered insecure for a couple of key
>> reasons:
>>
>>
>>    -
>>
>>    They rely on the MD5 digest algorithm, which is now considered very
>>    weak and should no longer be used.
>>    -
>>
>>    They require the server to store the password in a reversible format,
>>    which makes it more vulnerable to compromise than other types of
>>    authentication that work with passwords stored in non-reversible form.
>>
>>
>> In this case, if the server supports it, then one of the SCRAM
>> authentication methods (e.g., using SCRAMSHA256BindRequest
>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA256BindRequest.html>
>> or SCRAMSHA512BindRequest
>> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA512BindRequest.html>)
>> would be a better choice because that relies on a stronger digest algorithm
>> and makes it possible for the server to store passwords in a non-reversible
>> form (albeit one that is tied to that particular authentication mechanism).
>>
>> If you’re asking about some other type of authentication that relies on
>> the MD5 digest, then please provide more information. However, the LDAP SDK
>> probably doesn’t support it, and you really shouldn’t be using anything
>> that relies on the MD5 digest.
>>
>> Neil Wilson
>>
>>
>> On Tue, May 2, 2023 at 8:29 AM Andrei Petru Mura <map...@gm...>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Is there an example on how to enable MD5 authentication for UnboundID on
>>> Java and how to perform it from the client side?
>>>
>>> Thanks,
>>> Andrei Mura
>>> _______________________________________________
>>> ldap-sdk-discuss mailing list
>>> lda...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*_______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

Re: [ldap-sdk-discuss] MD5 Authentication

[Andrei P. M. <map...@gm...>]

Hello Neil,

Thanks for great and knowledgeable insight.

1. I want to test MD5-DIGEST SASL mechanism against an unbound InMemory
LDAP server (this is performed during the JUnit tests). In order to do
this, I want to configure the server to support MD5 - it seems to me it
doesn't by default - am I wrong?
2. As a client, I want to use Java's provided API, other than the unboundID
API. For this, according to the documentation, it says so:

To use the Digest-MD5 authentication mechanism, you must set the
authentication environment properties as follows.
Context.SECURITY_AUTHENTICATION
<https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_AUTHENTICATION>
.Set to the string "DIGEST-MD5".Context.SECURITY_PRINCIPAL
<https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_PRINCIPAL>
.Set to the principal name. This is a server-specific format. Some servers
support a login user id format, such as that defined for UNIX or Windows
login screens. Others accept a distinguished name. Yet others use the
authorization id formats defined in RFC 2829
<http://www.ietf.org/rfc/rfc2829.txt>. In that RFC, the name should be
either the string "dn:", followed by the fully qualified DN of the entity
being authenticated, or the string "u:", followed by the user id. Some
servers accept multiple formats. Examples of some of these formats are
"cuser", "dn: cn=C. User, ou=NewHires, o=JNDITutorial", and "u: cuser" The
data type of this property must be java.lang.String.
Context.SECURITY_CREDENTIALS
<https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html#SECURITY_CREDENTIALS>
.Set to the password of the principal (for example, "mysecret"). It is of
type java.lang.String, char array (char[]), or byte array (byte[]). If the
password is a java.lang.String or char[], then it is encoded by using UTF-8
for transmission to the server. If the password is a byte[], then it is
transmitted as is to the server.

The following example
<https://docs.oracle.com/javase/tutorial/jndi/ldap/examples/Digest.java> shows
how a client performs authentication using Digest-MD5 to an LDAP server.

// Set up the environment for creating the initial context
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");

// Authenticate as C. User and password "mysecret"
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL,
        "dn:cn=C. User, ou=NewHires, o=JNDITutorial");
env.put(Context.SECURITY_CREDENTIALS, "mysecret");

// Create the initial context
DirContext ctx = new InitialDirContext(env);


source: https://docs.oracle.com/javase/tutorial/jndi/ldap/digest.html


N.B. The DIGESTMD5BindRequest
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
seems to provide guidance for the client's API, not for the server's.


Thanks,

Andrei Mura


On Tue, May 2, 2023 at 5:42 PM Neil Wilson via ldap-sdk-discuss <
lda...@li...> wrote:

> Could you please clarify what you mean by MD5 authentication?
>
> Do you mean the DIGEST-MD5 or CRAM-MD5 SASL mechanisms? If so, then the
> LDAP SDK does support them through the DIGESTMD5BindRequest
> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
> and CRAMMD5BindRequest
> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/CRAMMD5BindRequest.html>
> classes, respectively, and the Javadoc documentation for each class does
> provide a short example that demonstrates how to use them. However, both of
> these authentication mechanisms are considered insecure for a couple of key
> reasons:
>
>
>    -
>
>    They rely on the MD5 digest algorithm, which is now considered very
>    weak and should no longer be used.
>    -
>
>    They require the server to store the password in a reversible format,
>    which makes it more vulnerable to compromise than other types of
>    authentication that work with passwords stored in non-reversible form.
>
>
> In this case, if the server supports it, then one of the SCRAM
> authentication methods (e.g., using SCRAMSHA256BindRequest
> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA256BindRequest.html>
> or SCRAMSHA512BindRequest
> <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA512BindRequest.html>)
> would be a better choice because that relies on a stronger digest algorithm
> and makes it possible for the server to store passwords in a non-reversible
> form (albeit one that is tied to that particular authentication mechanism).
>
> If you’re asking about some other type of authentication that relies on
> the MD5 digest, then please provide more information. However, the LDAP SDK
> probably doesn’t support it, and you really shouldn’t be using anything
> that relies on the MD5 digest.
>
> Neil Wilson
>
>
> On Tue, May 2, 2023 at 8:29 AM Andrei Petru Mura <map...@gm...>
> wrote:
>
>> Hello everyone,
>>
>> Is there an example on how to enable MD5 authentication for UnboundID on
>> Java and how to perform it from the client side?
>>
>> Thanks,
>> Andrei Mura
>> _______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>

Re: [ldap-sdk-discuss] MD5 Authentication

[Neil W. <nei...@pi...>]

Could you please clarify what you mean by MD5 authentication?

Do you mean the DIGEST-MD5 or CRAM-MD5 SASL mechanisms? If so, then the
LDAP SDK does support them through the DIGESTMD5BindRequest
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/DIGESTMD5BindRequest.html>
and CRAMMD5BindRequest
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/CRAMMD5BindRequest.html>
classes, respectively, and the Javadoc documentation for each class does
provide a short example that demonstrates how to use them. However, both of
these authentication mechanisms are considered insecure for a couple of key
reasons:


   -

   They rely on the MD5 digest algorithm, which is now considered very weak
   and should no longer be used.
   -

   They require the server to store the password in a reversible format,
   which makes it more vulnerable to compromise than other types of
   authentication that work with passwords stored in non-reversible form.


In this case, if the server supports it, then one of the SCRAM
authentication methods (e.g., using SCRAMSHA256BindRequest
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA256BindRequest.html>
or SCRAMSHA512BindRequest
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/SCRAMSHA512BindRequest.html>)
would be a better choice because that relies on a stronger digest algorithm
and makes it possible for the server to store passwords in a non-reversible
form (albeit one that is tied to that particular authentication mechanism).

If you’re asking about some other type of authentication that relies on the
MD5 digest, then please provide more information. However, the LDAP SDK
probably doesn’t support it, and you really shouldn’t be using anything
that relies on the MD5 digest.

Neil Wilson


On Tue, May 2, 2023 at 8:29 AM Andrei Petru Mura <map...@gm...>
wrote:

> Hello everyone,
>
> Is there an example on how to enable MD5 authentication for UnboundID on
> Java and how to perform it from the client side?
>
> Thanks,
> Andrei Mura
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] MD5 Authentication

[Andrei P. M. <map...@gm...>]

Hello everyone,

Is there an example on how to enable MD5 authentication for UnboundID on
Java and how to perform it from the client side?

Thanks,
Andrei Mura

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.8

[Neil W. <nei...@pi...>]

We have just released version 6.0.8 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://central.sonatype.com/artifact/com.unboundid/unboundid-ldapsdk/6.0.8>
.

Note that this is the last release for which the LDAP SDK source code will
be maintained in both the GitHub and SourceForge repositories. The LDAP SDK
was originally hosted in a subversion repository at SourceForge, but we
switched to GitHub as the primary repository a few years ago. We have been
relying on GitHub’s support for accessing git repositories via subversion
to synchronize changes to the legacy SourceForge repository, but that
support is being discontinued. The SourceForge project will continue to
remain available for the discussion forum
<https://sourceforge.net/p/ldap-sdk/discussion/1001257/>, mailing lists
<https://sourceforge.net/p/ldap-sdk/mailman/>, and release downloads
<https://sourceforge.net/projects/ldap-sdk/files/>, but up-to-date source
code will only be available on GitHub.

You can find the release notes for the 6.0.8 release (and all previous
versions) at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but
here’s a summary of the changes:


   -

   We added a DN.getDNRelativeToBaseDN method that can be used to retrieve
   the portion of DN that is relative to a given base DN (that is, the portion
   of a DN with the base DN stripped off). For example, if you provide it with
   a DN of “uid=test.user,ou=People,dc=example,dc=com” and a base DN of “
   dc=example,dc=com”, then the method will return “uid=test.user,ou=People
   ”.



   -

   We added LDAPConnectionPool.getServerSet and
   LDAPThreadLocalConnectionPool.getServerSet methods that can be used to
   retrieve the server set that the connection pool uses to establish new
   connections for the pool.



   -

   We updated the Filter class to alternative methods with shorter names
   for constructing search filters from their individual components. For
   example, as an alternative to calling the Filter.createANDFilter method
   for constructing an AND search filter, you can now use Filter.and, and
   as an alternative to calling Filter.createEqualityFilter, you can now
   use Filter.equals. The older versions with longer method names will
   remain available for backward compatibility.



   -

   We added support for encrypted PKCS #8 private keys, which require a
   password to access the private key. The PKCS8PrivateKey class now
   provides methods for creating the encrypted PEM representation of the key,
   and the PKCS8PEMFileReader class now has the ability to read encrypted
   PEM files. We also updated the manage-certificates tool so that the
   export-private-key and import-certificate subcommands now support
   encrypted private keys.



   -

   We updated PassphraseEncryptedOutputStream to use a higher key factory
   iteration count by default. When using the strongest available 256-bit AES
   encryption, it now follows the latest OWASP recommendation of 600,000
   PBKDF2 iterations. You can still programmatically explicitly specify the
   iteration count when creating a new output stream if desired, and we have
   also added system properties that can override the default iteration count
   without any code change.



   -

   We added a PassphraseEncryptedOutputStream constructor that allows you
   to provide a PassphraseEncryptedStreamHeader when creating a new
   instance of the output stream. This will reuse the secret key that was
   already derived for the provided stream header (although with newly
   generated initialization vector), which can be significantly faster than
   deriving a new secret key from the same passphrase.



   -

   We added a new ObjectTrio utility class that can be useful in cases
   where you need to reference three typed objects as a single object (for
   example, if you want a method to be able to return three objects without
   needing to define a new class that encapsulates those objects). This
   complements the existing ObjectPair class that supports two typed
   objects.



   -

   We updated the documentation to include RFC 9371
   <https://docs.ldap.com/specs/rfc9371.txt> in the set of LDAP-related
   specifications. This RFC formalizes the process for requesting a private
   enterprise number (PEN) to use as the base object identifier (OID) for your
   own definitions (e.g., for use in defining custom attribute types or object
   classes). The OID-related documentation has also been updated to provide a
   link to the IANA site
   <https://www.iana.org/assignments/enterprise-numbers/> that you can use
   to request an official base OID for yourself or your organization.



   -

   We updated the documentation to include the latest revisions of
   draft-howard-gssapi-aead
   <https://docs.ldap.com/specs/draft-howard-gssapi-aead-01.txt>,
   draft-ietf-kitten-scram-2fa
   <https://docs.ldap.com/specs/draft-ietf-kitten-scram-2fa-02.txt>,
   draft-melnikov-scram-bis
   <https://docs.ldap.com/specs/draft-melnikov-scram-bis-02.txt>, and
   draft-reitzenstein-kitten-opaque
   <https://docs.ldap.com/specs/draft-reitzenstein-kitten-opaque-02.txt> in
   the set of LDAP-related specifications.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.7

[Neil W. <nei...@pi...>]

We have just released version 6.0.7 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://search.maven.org/search?q=g:com.unboundid%20AND%20a:unboundid-ldapsdk&core=gav>.
You can find the release notes at
https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes included in this version:


   -

   We fixed a bug in the SearchResultEntry.equals method that could prevent
   a SearchResultEntry from matching other types of Entry objects.



   -

   We fixed a bug in the Entry.applyModifications method that could cause
   it to fail with a NOT_ALLOWED_ON_RDN result if the provided entry was
   missing one or more of the attribute values used in its RDN.



   -

   We fixed a bug in the argument parser’s support for mutually dependent
   arguments with a set containing more than two arguments. Previously, the
   constraint would have been satisfied if at least two of the arguments were
   provided, rather than requiring all of them to be provided.



   -

   We added JSONObject methods for retrieving fields by name using
   case-insensitive matching (by default, JSON field names are treated in a
   case-sensitive manner). Because it is possible that a JSON object will have
   multiple fields with the same name when using case-insensitive matching,
   there are a few options for indicating how such conflicts should be
   handled, including only returning the first match, returning a map with all
   matching fields, or throwing an exception if there are multiple matches.



   -

   We updated the set of LDAP-related specifications to include the latest
   version of the draft-schmaus-kitten-sasl-ht proposal.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 6.0.6

[Neil W. <nei...@pi...>]

We have just released version 6.0.6 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://search.maven.org/search?q=g:com.unboundid%20AND%20a:unboundid-ldapsdk&core=gav>.
You can find the release notes at
https://docs.ldap.com/ldap-sdk/docs/release-notes.html, but here’s a
summary of the changes included in this version:

General Updates:


   -

   We fixed an issue that could cause request failures when closing a
   connection operating in asynchronous mode with outstanding operations.



   -

   We fixed an issue that could interfere with the ability to get a default
   SSLContext on Java 17 when running in FIPS 140-2-compliant mode.



   -

   We updated LDAPConnectionOptions to add support for a new system
   property that can enable certificate hostname verification by default
   without any code changes.



   -

   We updated the LDAP command-line tool framework to add a new
   --verifyCertificateHostnames argument to enable hostname verification
   when performing TLS negotiation.



   -

   We improved the class-level Javadoc documentation for the SSLUtil class
   to provide a better overview of TLS protocol versions, TLS cipher suites,
   key managers, trust managers, and certificate hostname verification, and to
   provide better examples that illustrate best practices for establishing
   secure connections.



   -

   We fixed an issue in the JNDI compatibility support for controls, as
   well as extended requests and responses. Even though the implementation was
   based on the JNDI documentation, it appears that at least OpenJDK
   implementations do not abide by that documentation. The LDAP SDK is now
   compatible with the observed behavior rather than the documentation,
   although a system property can be used to revert to the former behavior.



   -

   We updated the SearchRequest class to add constructors that allow you to
   provide the search base DN with a DN object (as an alternative to
   existing constructors that allow you to specify it as a String).



   -

   We fixed an issue in the command-line tool framework in which an Error
   (for example, OutOfMemoryError) could cause the tool to report a
   NullPointerException rather than information about the underlying error.



   -

   We fixed an issue in the IA5 argument value validator that could allow
   it to accept argument values with non-ASCII characters.



   -

   We fixed an issue in the DNS hostname argument value validator that
   could prevent it from properly validating the last component of a fully
   qualified domain name, or the only component of an unqualified name.



   -

   We updated the identify-references-to-missing-entries tool to provide an
   option to generate an LDIF file with changes that can be used to remove
   identified references.



   -

   We updated the SelfSignedCertificateGenerator class to perform better
   validation for the subject alternative DNS names that it includes in a
   certificate.



   -

   We updated the manage-certificates generate-self-signed-certificate
   command to rename the --replace-existing-certificate argument to be
   --use-existing-key-pair. The former argument name still works, but it is
   hidden from the usage.



   -

   We included a native-image/resource-config.json file in the LDAP SDK jar
   file manifest, which can be used by the GraalVM native-image tool to
   ensure that appropriate resource files are included in the resulting image.


Updates Specific to Use With the Ping Identity Directory Server:


   -

   We updated the summarize-access-log tool to report on many more things,
   including the most common IP addresses for failed bind attempts, the most
   consecutive failed binds, information about work queue wait times,
   information about request and response controls, the number of components
   in search filters, and search filters that may indicate injection attempts.



   -

   We updated support for the audit data security administrative task to
   make it possible to specify the number and/or age of previous reports to
   retain.



   -

   We fixed issues that prevented specifying the criticality of the
   administrative operation and join request controls.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._