UnboundID LDAP SDK for Java 6.0.6

We have just released version 6.0.6 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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.

UnboundID LDAP SDK for Java 6.0.5

We have just released version 6.0.5 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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 occasionally cause the LDAP SDK to hide the actual cause of a StartTLS failure by using information from a second, less useful exception.
  • We fixed an issue that could cause the ldifsearch tool to display a malformed message when the first unnamed trailing argument was expected to be a search filter but could not be parsed as a valid filter.
  • We improved support for validating and comparing values using the telephone number syntax. Previously, we used a loose interpretation of the specification, which would consider any printable string (including strings without any digits) to be valid, and would only ignore spaces and hyphens when comparing values. You can now configure varying levels of strictness (either programmatically or using system properties), including requiring at least one digit or strict conformance to the X.520 specification. You can also configure it to ignore all non-digit characters when comparing values, and this is now the default behavior.
  • We fixed a bug in which the ldapcompare tool did not properly close its output file if one was configured. The output file does get automatically closed when the tool exits so it’s not an issue when running ldapcompare from the command line, but this can cause problems if the tool is invoked programmatically from another application.
  • We fixed an issue with the tool properties file created using the --generatePropertiesFile argument in command-line tools that support it. The generated properties file did not properly escape backslash, carriage return, line feed, or form feed characters.

Updates Specific to Use With the Ping Identity Directory Server:

  • We added support for encoding controls to JSON objects, and for decoding JSON objects as controls. There is a generic JSON representation that will work for any type of control (in which the value is provided as the base64-encoded representation of the raw value used in the LDAP representation of the control), but most controls provided as part of the LDAP SDK also support a more user-friendly representation in which the components of the value are represented in a nested JSON object.
  • We added client-side support for a new JSON-formatted request control that can be used to send request controls to a Ping Identity Directory Server with the controls encoded as JSON objects rather than a raw LDAP representation. We also added support for a JSON-formatted response control that can be used to receive JSON-encoded response controls from the server.
  • We updated the ldapsearch and ldapmodify command-line tools to add a --useJSONFormattedRequestControls argument that will cause any request controls to be sent using a JSON-formatted request control, and it will cause any response controls returned by the server to be embedded in a JSON-formatted response control.
  • We fixed an issue with the way that the parallel-update tool created assured replication request controls when an explicit local or remote assurance level was specified. Previously, it would only specify a minimum assurance level without specifying a maximum level, which could cause the server to use a higher assurance level than requested by the client.
  • We updated the topology registry trust manager to allow trusting a certificate chain if either the peer certificate or any of its issuers is found in the server’s topology registry. Previously, it would only trust a certificate chain if the peer certificate itself was found in the topology registry, and having an issuer certificate was not sufficient. The former behavior is still available with a configuration option.
  • We updated the topology registry trust manager to make it possible to ignore the certificate validity window for peer and issuer certificates. The validity window is still respected by default, but if the trust manager is configured to ignore it, then a certificate chain may be trusted even if the peer or an issuer certificate is expired or not yet valid.

UnboundID LDAP SDK for Java 6.0.4

We have just released version 6.0.4 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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 with the Filter.matchesEntry method that could cause it to throw an exception rather than returning an appropriate Boolean result when evaluating an AND or an OR filter in which one of the nested elements used inappropriate matching (for example, if the assertion value did not conform to the syntax for the associated attribute type).
  • We fixed an issue with the way that decodeable controls are registered with the LDAP SDK. Under some circumstances, a thread could become blocked while attempting to create a new control.
  • We updated the JVM-default trust manager to properly check for the existence of a “jssecacerts” trust store file in accordance with the JSSE specification. It had previously only looked for a file named “cacerts”.
  • We updated the logic used to select the default set of supported cipher suites so that it will no longer exclude suites with names starting with “SSL_” by default on JVMs with a vendor string that includes “IBM”. IBM JVMs appear to use the “SSL_” prefix for some or all cipher suites, including those that are not associated with TLS protocols rather than a legacy SSL protocol. We also added a TLSCipherSuiteSelector.setAllowSSLPrefixedSuites method that can be used to override the default behavior.
  • We updated the LDIF reader to support reading modifications with attribute values read from a file referenced by URL. This was previously supported when reading LDIF entries or add change records, but it had been overlooked for LDIF modify change records.
  • We updated the LDIF reader so that it no longer generates comments attempting to clarify the contents of base64-encoded values if the value is longer than 1,000 bytes.
  • We updated the documentation to include the latest versions of the draft-behera-ldap-password-policy, draft-coretta-x660-ldap, and draft-ietf-kitten-scram-2fa specifications.

Updates Specific to Use With the Ping Identity Directory Server:

  • We added a new API for parsing access log messages generated by the server. The new API supports both text-formatted and JSON-formatted log messages, whereas the previous version only supported messages in the default text (“name=value”) format.
  • We updated the summarize-access-log tool (which can be used to perform basic analysis of server access log files) to add support for JSON-formatted log files.
  • We added support for retrieving and parsing X.509 certificate monitor entries.
  • We added client-side support for an administrative task that can cause the server to immediately refresh any cached certificate monitor data. The server will automatically refresh the cache every minute, but the task can be used to cause an immediate refresh.

UnboundID LDAP SDK for Java 6.0.3

We have just released version 6.0.3 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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 with the round-robin server set that could cause it to select some servers with a higher frequency than others in the event that one or more of the servers become unavailable.
  • We fixed a potential race condition that could leave a background Timer thread running if a connection was closed while waiting for a response to a request issued via the asynchronous API.
  • We fixed an issue in which the in-memory directory server could incorrectly include a matched DN in certain bind response messages.
  • We improved support for SSL/TLS debugging for SSLUtil operations when used in conjunction with the javax.net.debug system property.
  • We added methods to the JSONLDAPResultWriter class that can be used to encode entries, search result references, and LDAP results to JSON objects.
  • We added a CryptoHelper.inferKeyStoreType method that attempts to determine the key store type for a specified file that is expected to represent a JKS, PKCS #12, or BCFKS key store.
  • We added StaticUtils convenience methods for generating random bytes, integers, and strings, optionally using cryptographically secure random number generators.

Updates Specific to Use With the Ping Identity Directory Server:

  • We fixed an issue that could cause the manage-account tool to fail if it receives a response with an unrecognized password policy state operation type. This is most likely to occur when the tool is communicating with a version of the Ping Identity Directory Server that does not correspond to the version of the manage-account tool.
  • We added client-side support for new extended operations that can allow for remote management of certificates in Ping Identity Directory Server instances.
  • We updated the AuthenticationFailureReason class to add additional failure reason values related to pass-through authentication.
  • We updated the TaskManager class to add methods for using LDAPInterface objects (including connection pools or Server SDK internal connections) as an alternative to LDAPConnection objects when interacting with administrative tasks.

UnboundID LDAP SDK for Java 6.0.2

We have just released version 6.0.2 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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 an issue in the JVM-default trust manager that could prevent it from properly trusting a certificate chain that should be considered valid through a cross-signed relationship, which may include certificates signed by the Let’s Encrypt service in some cases. Although the trust manager provided support for cross-signed certificates, that support would previously only be used if one or more of the certificates in the presented chain were outside of their current validity window.
  • We added the ability to use the tls-server-end-point channel binding type when authenticating with the GSSAPI SASL mechanism. This feature depends on the underlying JVM providing support for this channel binding type and will likely require Java 13 or later.
  • We fixed an issue in the in-memory directory server that could prevent it from returning search result references for smart referral entries within the scope of the search. It would previously only return references for smart referral entries that matched the search filter, but will now return references for any smart referral entry within the scope.
  • We updated the LDAP command-line tool framework to add a --defaultTrust argument that can be used to indicate that the tool should use a default set of non-interactive logic for determining whether to trust a presented certificate chain. This includes at least the JVM’s default trust store, but in tools that are part of a Ping Identity server installation, it may also include the server’s default trust store and the topology registry. This is the same logic that tools would previously use when invoked without any trust-related arguments, with the exception that it will not interactively prompt about whether to trust the presented chain if it cannot be trusted through any of the default mechanisms. As such, it is more suitable for use in scripts that are intended to run in non-interactive settings.

UnboundID LDAP SDK for Java 6.0.1

We have just released version 6.0.1 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. 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 added a new ldap-diff command-line tool that can be used to compare the contents of two LDAPv3 servers. Any differences identified will be written to a specified file as LDIF change records that may be used to update the source server to match the target server. The tool attempts to minimize the memory required to perform the comparison, and it can use multiple passes to avoid potential false positives that result from delays in replication or changes made while the tool is running.
  • We updated the ldifsearch tool to provide support for presenting the results in alternative output formats. It now supports the same formats as ldapsearch, including LDIF, JSON, CSV (single-valued and multi-valued), tab-delimited text (single-valued and multi-valued), DNs only, and values only.
  • We updated the LDIF reader to make it possible to customize the size limit that it imposes for values read from a file referenced by URL. This limit is a safety feature that prevents consuming too much memory when encountering a reference to a very large file, but the size limit was previously hard-coded to be 10 megabytes. That is still the default, but it’s now possible to use the com.unboundid.ldif.LDIFReader.maxURLFileSizeBytes system property to set an alternative limit.
  • We augmented the LDAP SDK’s debugging support to make it possible to automatically have debug messages written to a file specified by the com.unboundid.ldap.sdk.debug.file system property. This is intended to be used in conjunction with other debugging-related system properties to enable support for debugging in existing applications without the need for a code change.
  • We lowered the debug level for exception messages that may be logged as a result of a SocketTimeoutException that is caught internally in the course of trying to determine whether a connection in a connection pool is still valid. This is a completely normal condition that was previously inadvertently logged at a WARNING level. This could potentially mislead people into thinking that it’s a problem, or at the very least make it harder to find debug messages that are actually important. It is now logged at the FINEST level, so it will only be visible at the highest level of verbosity.
  • We updated support for the Ping Identity Directory Server’s matching entry count control to make it possible to request extended response data, including whether the search is fully indexed, whether identified candidate entries are known to be included in the scope of the search, and any remaining portion of the filter that was not used in the course of building the set of candidate entries.
  • We updated support for the Ping Identity Directory Server’s generate profile administrative task to clarify that all included paths must be relative rather than absolute. Those paths will be treated as relative to the server root, and relative paths that reference portions of the filesystem outside the server root will not be allowed.
  • We updated the documentation to include the latest revision of draft-coretta-x660-ldap in the set of LDAP-related specifications.

UnboundID LDAP SDK for Java 6.0.0

We have just released version 6.0.0 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository.

One of the biggest changes that we’ve made in this release is that we’ve deprecated support for the TLSv1 and TLSv1.1 protocol versions in accordance with RFC 8996. By default, the LDAP SDK will prefer using TLSv1.3, but it can fall back to using TLSv1.2 if the newer protocol is not supported by the client JVM or by the directory server. The older TLSv1 and TLSv1.1 protocol versions can still be enabled if necessary (either programmatically or by setting system properties), but given that they are no longer considered secure, and given that TLSv1.2 became an official standard over twelve years ago, the far better option would be to use a directory server release from sometime in the last decade.

We have also updated the set of TLS cipher suites that the LDAP SDK will use by default. The default set of enabled cipher suites no longer includes those that rely on the SHA-1 message digest algorithm (which is no longer considered secure) or those that rely on RSA key exchange (which doesn’t support forward secrecy and could allow an observer to decrypt the communication if the server certificate’s private key becomes compromised; note that deprecating RSA key exchange doesn’t affect the ability to interact with servers that use certificates with RSA key pairs). If necessary, you can override the set of cipher suites that the LDAP SDK uses by default, either programmatically or with system properties.

You can find the complete release notes at https://docs.ldap.com/ldap-sdk/docs/release-notes.html. Other notable changes in this release include:

  • We fixed an issue that could cause the LDAP SDK to use the set of TLS cipher suites enabled in the JVM by default rather than a recommended set identified by the LDAP SDK itself. This could potentially result in using weaker encryption for secure connections.
  • We updated the logic that the LDAP SDK uses when deciding which characters to escape when generating the string representation of a DN or RDN. Previously, it would always escape all non-ASCII characters. Now, the LDAP SDK will no longer escape non-ASCII characters that it believes are displayable (including the Unicode letter, number, punctuation, and symbol character types). If desired, you can override this behavior either programmatically or with a system property.
  • We updated the logic that the LDAP SDK uses when deciding which data should be base64-encoded when generating the LDIF representation of an entry. Previously, it would not always base64-encode data with ASCII control characters (other than NUL, LF, and CR, which must always be base64-encoded). Now, it will always base64-encode values with ASCII control characters by default. It can also be configured to optionally not base64-encode values with non-ASCII characters (which technically violates the LDIF specification but may be useful when displaying to an end user). You can override the LDAP SDK’s base64-encoding strategy either programmatically or with a system property.
  • We updated the LDIF reader to make it possible to disable support for parsing LDAP controls. By default, the LDAP SDK supports LDIF change records that include LDAP controls as described in RFC 2849. However, this can cause a problem in a rare corner case if a record represents an entry rather than a change record and the first attribute in the LDIF representation of that entry is named “control”. If you attempt to read that record as a generic LDIF record or as a change record with defaultAdd set to true (rather than reading it specifically as an entry), then the LDIF reader will attempt to parse that attribute as an LDIF control. If you have LDIF records that represent entries in which the first attribute may be named “control”, if you are reading them as generic LDIF records or as LDIF change records with defaultAdd set to true, and if you don’t have any LDIF change records that legitimately do include LDAP controls, then you can update the LDIF reader to disable support for controls so that it will interpret a leading “control” element as an attribute rather than a change record with a control.
  • We updated PKCS11KeyManager to make it easier to use certificate chains stored in PKCS #11 tokens without needing to alter the JVM configuration. Previously, if you wanted to use PKCS #11, you either had to modify a configuration file within the JVM installation (which may not always be feasible), or you had to write your own code to load the provider before trying to use the key manager. You can now supply a provider configuration file when creating a PKCS #11 key manager, and it will ensure that the necessary provider is loaded and registered with the JVM.
  • We updated the manage-certificates tool to support interacting with PKCS #11 tokens. Previously, the tool only supported certificates in JKS, PKCS #12, and BCFKS key stores. When using a PKCS #11 token, you must use the --keyStore argument with a value that is the path to the provider configuration file and the --keyStoreFormat argument with a value of PKCS11.
  • We updated the manage-certificates tool to add a new copy-keystore subcommand with support for copying some or all of the information in one key store to another key store of the same or a different type. This can allow you to merge key stores or convert a key store from one type to another (for example, JKS to PKCS #12).
  • We updated the manage-certificates tool to add optional --output-file and --output-format arguments to the generate-self-signed-certificate subcommand. This allows you to generate and export a self-signed certificate in one step rather than requiring a separate command to export a certificate after generating it.
  • We updated the manage-certificates tool to allow interacting with BCFKS key stores even when the LDAP SDK is not operating in FIPS 140-2-compliant mode. Note that the necessary FIPS-compliant Bouncy Castle libraries must already be in the classpath.
  • We updated the manage-certificates tool to display the key store type when using the list-certificates subcommand.
  • We updated the in-memory-directory-server command-line tool to add a new --doNotGenerateOperationalAttributes argument that will prevent the server from maintaining operational attributes like entryDN, entryUUID, subschemaSubentry, creatorsName, createTimestamp, modifiersName, and modifyTimestamp.
  • We updated the FileArgument class to provide better support for interacting with files that are potentially encrypted or compressed. The getFileLines, getNonBlankFileLines, and getFileBytesMethods have been updated so that they can transparently handle reading from gzip-compressed files. Further, for tools that are running as part of a Ping Identity Directory Server installation, they can transparently handle reading from files that are encrypted with a key from the server’s encryption settings database. Also, a new getFileInputStream method has been provided that can retrieve an input stream to use when reading from the target file, including cases in which the file is compressed or encrypted.
  • We added a new ThreadLocalSecureRandom class that can be used to maintain a set of per-thread SecureRandom instances that can be used without concerns around synchronization or contention.
  • We updated the documentation to include the latest revisions of the draft-coretta-x660-ldap, draft-ietf-kitten-password-storage, and draft-melnikov-scram-2fa drafts in the set of LDAP-related specifications.

Changes specific to running in FIPS 140-2-compliant mode include:

  • We have updated the LDAP SDK so that it will use the Bouncy Castle FIPS-compliant SecureRandom instance in hybrid mode, which helps reduce the chance that it will encounter severe performance issues as a result of depleted entropy on the underlying system. However, in some cases, it may still be necessary to either use a hardware random number generator or a software entropy supplementing daemon (like rngd) to prevent blocking due to a lack of entropy.
  • We have updated the LDAP SDK to make it possible to customize the set of providers that will be allowed when running in FIPS 140-2-compliant mode. You can perform this customization programmatically or with a system property.
  • We have updated the command-line tool framework to check whether the LDAP SDK is running in FIPS 140-2-compliant mode upon invoking the tool constructor. This can help prevent cases in which the tool may inadvertently perform operations with a non-FIPS-compliant provider.

Changes specific to using the LDAP SDK in conjunction with the Ping Identity Directory Server include:

  • We updated the collect-support-data tool to allow using the --keyStoreFormat and --trustStoreFormat arguments when invoking the server-side version of the tool. Previously, you could only use these arguments in conjunction with the --useRemoteServer argument. This change only applies when using the 8.3.0.0 or later release of the Ping Identity Directory Server.
  • We added client-side support for a new administrative task that can be used to safely remove an object class definition from the server schema. The task will ensure that the object class is not in use before attempting to remove it, and it will clean up any references to the object class that may no longer be necessary (for example, in a backend’s entry compaction dictionary).

UnboundID LDAP SDK for Java 5.1.3

We have just released version 5.1.3 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository.

The biggest change in this release addresses an issue in the LDAP listener framework (including the in-memory directory server). The listener did not adequately protect against the case in which a malicious or errant client could send an LDAP request encoded as an ASN.1 BER sequence with a very large value length, which could result in the listener attempting to allocate up to two gigabytes of memory. The LDAP listener framework will now impose a maximum request size of 20 megabytes by default, which is the same as the default maximum size that the LDAP SDK will impose for responses read from a directory server. The maximum request size can be configured using the InMemoryDirectoryServerConfig.setMaxMessageSizeBytes method when using the in-memory directory server, or using the LDAPListenerConfig.setMaxMessageSizeBytes method when using the more general LDAP listener framework. If you’re using the LDAP listener framework (or the in-memory directory server) to accept requests from potentially untrusted clients, then we recommend upgrading to the 5.1.3 release.

Other changes since the 5.1.2 release include:

  • We have updated OID support to add methods for interacting with object identifiers in a hierarchical manner. It is now possible to create a new OID that is a child of a provided OID with a given subordinate component value. You can also get the parent for a provided OID and determine whether one OID is an ancestor or descendant of another.
  • We have updated the oid-lookup tool to add a new --exact-match argument that will cause it to only return items in which the OID, name, type, origin, or URL exactly matches the provided search string. The tool continues to use substring matching by default.
  • We have updated the ldap-result-code tool to add a new --output-format argument that allows you to customize whether the output should be formatted as a human-readable table, comma-separated values, tab-delimited text, or JSON objects. It will continue to format result codes in a table by default.

UnboundID LDAP SDK for Java 5.1.2

We have just released version 5.1.2 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. The release notes provide a pretty comprehensive overview of what’s changed since the 5.1.1 release, but here’s a summary:

Server-Agnostic Updates

  • We added a new parallel-update command-line tool that can be used to apply changes read from an LDIF file against an LDAP server using multiple concurrent threads.
  • We updated the ldapmodify and ldapdelete tools so that they will now default to retrying failed operations on a newly established connection if the failure suggests that the connection made for the initial attempt is no longer valid. This was previously available through the --retryFailedOperations argument, but it is now the default behavior, and a --neverRetry argument can be used if retry support is not wanted.
  • We added a new OIDRegistry class that provides a registry of object identifiers used in LDAP, including things like schema elements, controls, extended operations, and other sources. Each item in the registry has a name, an OID, and a type, and it may also have an origin string and a URL that may be used to retrieve additional information about the item.
  • We added a new oid-lookup command-line tool that can be used to search the OID registry to find items with a given OID, name, type, or other content.
  • We added a new ldap-result-code command-line tool that can be used to list all defined result codes and search for result codes with a given name or integer value.
  • We updated the LDAP listener framework and the in-memory directory server to support mutual TLS authentication, in which the server requests a certificate chain from the client and validates any chain that the client provides.
  • We updated the logic used to generate temporary self-signed certificates for use by the in-memory-directory-server and ldap-debugger command-line tools so that the certificates will be more acceptable to a wider range of clients. The certificate will now only be valid for one year, as some TLS clients balk at peer certificates with very long lifetimes. The subject alternative name extension will also default to only using canonical host names and IP addresses that are associated with non-loopback interfaces.
  • We added a new argument value validator that can be used to restrict command-line argument values to those that represent valid DNS host names. It can optionally accept or reject values that are numeric IP addresses, can accept or reject unqualified host names, and can accept or reject unresolvable host names.
  • We added a new SASLClientBindHandler class that can be used to invoke SASL bind operations that use a javax.security.sasl.SaslClient object to perform the actual SASL processing. We also added an LDAPConnection.applySASLSecurityLayer method that can be used to add a security layer that has been negotiated with a SaslClient to an established, clear-text connection.
  • We updated the HostNameSSLSocketVerifier to automatically trust any certificate when the client used a loopback IP address (not a host name, even if that name is associated with a loopback interface) as the address for the server. This is in accordance with the W3C Secure Contexts Candidate Recommendation, section 3.2.
  • We updated the HostNameSSLSocketVerifier and TrustAllSSLSocketVerifier classes to implement the javax.net.ssl.HostnameVerifier interface.
  • We updated the LDIF writer to improve human readability for the comments that it can automatically add for base64-encoded values.
  • We updated the manage-certificates command-line tool to add support for a new retrieve-server-certificate subcommand, which will retrieve the certificate chain from a specified server and optionally write a PEM-encoded or DER-encoded representation of the certificate(s) to a specified file.
  • We fixed an issue with the manage-certificates trust-server-certificate command that only caused it to wait for 60 milliseconds rather than the intended 60 seconds when trying to establish a connection to the target server.
  • We updated ldapsearch to add a new “dns-only” output format. If this format is selected, then the output will contain only the DNs of matching entries.
  • We updated support for the OAUTHBEARER SASL mechanism to make it possible to include arbitrary key-value pairs in the SASL credentials.
  • We fixed an issue in the command-line tool framework that affected tools that provide support for automatically writing the output to a file. The output file was never explicitly closed, which could cause problems in cases where the tool was invoked programmatically, and then an attempt was made to subsequently use the output from code in the same JVM.
  • We added a new StaticUtils.isIANAReservedIPAddress method that can be used to determine whether a provided IPv4 or IPv6 address is contained in an IANA-reserved range.
  • We updated the ChangeLogEntry class so that it will fall back to using the includedAttributes attribute if the deletedEntryAttrs attribute does not exist in changelog entries that represent a delete operation.
  • We updated the LDAP SDK’s support for passphrase-based encryption to make it possible to explicitly specify the type of cipher that should be used. Previously, you could only request either a baseline level of protection (which should be available in all supported Java versions) or the strongest supported level of protection (which might not be available in some JVMs)
  • We added a new X.509 trust manager that will never trust any certificate chain. This is primarily intended for testing purposes.

Updates Specific to the Ping Identity Directory Server

  • We added client-side support for a new ds-pwp-modifiable-state-json operational attribute that can be used to retrieve and manipulate a select set of password policy state information in a user’s entry.
  • We added support for a new “remove attribute type” administrative task that can be used to safely remove an attribute type definition from the server schema.
  • We added client-side support for interacting with passwords encoded with the new AES256 password storage scheme.
  • We updated the Filter.matchesEntry method to add limited support for extensible matching filters that contain both an attribute type and a matching rule ID, when the dnAttributes flag is not set, and when the matching rule ID targets the jsonObjectFilterExtensibleMatch matching rule.
  • We updated the uniqueness request control to make it possible to indicate whether the server should raise an administrative alert if it detects a conflict during the post-commit validation phase.
  • We updated the uniqueness request control to make it possible to indicate that the server should create a temporary conflict prevention details entry before beginning pre-commit processing as a means of better preventing conflicts that arise from concurrent changes in different servers.
  • We deprecated support for interactive transactions, whose use has been discouraged for many releases, and for which server-side support is being removed.

UnboundID LDAP SDK for Java 5.1.1

We have just released version 5.1.1 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. The release notes provide a pretty comprehensive overview of what’s changed since the 5.1.0 release, but here’s a summary:

Server-Agnostic Updates

  • We had added new @NotNull and @Nullable annotation types and updated the entire LDAP SDK codebase to mark all non-primitive fields, parameters, and method return values to indicate whether they may be null. These annotations will appear in the generated Javadoc documentation, and they will also be available at runtime for introspection by IDEs and other tools.
  • We have improved the logic used to validate certificate hostnames. The LDAP SDK now does a better job of handling hostnames with wildcards, and it does a better job of handling cases in which the connection was established with an IP address rather than a hostname. There is also an option to indicate whether to treat a certificate’s subject alternative name extension (if present) as the only authoritative source of allowed hostnames or to also allow looking at the CN attribute in the certificate subject DN even if the certificate contains a subject alternative name extension.
  • We fixed an issue that could prevent command-line tools that support subcommands from performing all appropriate validation when running in interactive mode. The command-line tool’s interactive mode framework neglected to perform required, dependent, and exclusive argument set validation for the selected subcommand, which could cause the tool to run with an inappropriate set of arguments.
  • We fixed issues in the code used to format strings in the comma-separated values (CSV) format. Previously, all ASCII control characters and all non-ASCII characters were silently dropped from the output. They are now included, but the value will be in quotes (and may span multiple lines if the value to format includes line breaks). Further, it had previously used the backslash character to escape any double quotes in the data (\"), but RFC 4180 indicates that each double-quote character should be escaped by preceding it with another double quote character (""). The LDAP SDK now uses the RFC-specified behavior as the default, but it is possible to fall back to the former backslash-based encoding if desired or needed for backward compatibility.
  • We updated ldapsearch to add multi-valued-csv and multi-valued-tab-delimited output formats. The existing csv and tab-delimited output formats only include the first value for multi-valued attributes, while the multi-valued variants use the vertical bar character (|) as a delimiter between values.
  • We updated the ldappasswordmodify command-line tool to default to using the password modify extended operation if it is unable to retrieve the server’s root DSE while attempting to determine which method to use to change the password. The tool would previously exit with an error if the --passwordChangeMethod argument was not provided and it couldn’t retrieve the root DSE to determine an appropriate method.
  • We updated the authrate command-line tool so that the --filter argument is not required if the --bindOnly argument is provided.
  • Updated the ldapcompare tool so that it always uses an exit code of zero (corresponding to the LDAP success result code) by default if all compare operations are processed successfully, regardless of whether the assertions matched or did not match the target entries. Previously, the tool would use an exit code of 5 or 6 (corresponding to the LDAP compareFalse and compareTrue result codes, respectively) if only a single compare assertion was processed and completed with the corresponding result code. However, returning a nonzero exit code by default can cause problems with scripts that invoke the tool and expect that a nonzero result code indicates that an error occurred. The new --useCompareResultCodeAsExitCode argument can be used to request the previous behavior.
  • We updated the ldapcompare tool to allow reading the raw assertion value from a file. If this option is used, then the attribute name or OID should be followed by a colon, a less-than sign, and the path to the file from which the value should be read (for example, “cn:</path/to/asserted-cn-value.txt”). If this option is used, then the exact bytes of the file (including line breaks) will be used as the assertion value for the compare operation.
  • We updated the ldifsearch. tool so that all non-LDIF output is written as LDIF comments (preceded by the octothorpe character, #) so that it will not interfere with the ability to parse the remaining output as LDIF.
  • We added support for the OAUTHBEARER SASL mechanism, as described in RFC 7628.
  • We updated the LDAP command-line tool framework to add support for authenticating with additional SASL mechanisms, including OAUTHBEARER, SCRAM-SHA-1, SCRAM-SHA-256, and SCRAM-SHA-512.
  • We fixed issues with the ldifsearch, ldifmodify., and ldif-diff tools that could arise if they were run in a manner that would cause the output to be both compressed and encrypted. The tool incorrectly attempted to compress the output after it was encrypted rather than before, making the compression ineffective and the output incompatible with tools that expect compression to be applied before encryption.
  • We fixed an issue with the ldifsearch tool that could prevent it from properly finalizing the output when using compression or encryption, potentially leaving buffered data unwritten.
  • We fixed an issue with the ldifmodify tool that caused it to use a nonzero exit code if it was only used to add new entries to a previously empty source LDIF file.
  • We updated the ldifmodify tool to use lenient mode by default when applying modifications. It would previously reject attempts to add attribute values that already existed or remove attribute values that do not exist, but this could cause problems with applications that did not expect this behavior, as a legacy version of the tool used lenient mode by default. A new --strictModifications argument has been added that can request the strict validation mode if desired.
  • We updated the LDAP SDK’s command-line tool framework so that when displaying an example command that is split across multiple lines, it will use an appropriate continuation character for the underlying platform. It previously always used the backslash character (\), which is correct for UNIX-based systems, but it will now use the caret character (^) when running on Windows systems.
  • We fixed an issue with the ldifsearch tool that caused its usage output to include example arguments and descriptions intended for use with the ldif-diff tool.
  • We fixed an issue in the manage-certificates tool usage output that caused the generate-certificate-signing-request subcommand’s --key-size-bits argument to use the wrong description.

Updates Specific to the Ping Identity Directory Server

  • We added support for a new “get recent login history” control that can be included in a bind request to indicate that the bind response (if authentication was successful) should include information about other recent successful and failed authentication attempts for that user. The ldapsearch and ldapmodify commands have been updated to provide support for this control. We also updated support for the password modify extended operation, the manage-account command-line tool, and the ds-pwp-state-json virtual attribute to provide support for retrieving a user’s recent login history.
  • We updated support for the password modify extended operation, the manage-account tool, and the ds-pwp-state-json virtual attribute to provide support for retrieving state information about password validation performed during bind operations, including the time that validation was last performed and whether the account is locked because the bind password failed validation.
  • We updated support for the ds-pwp-state-json virtual attribute to provide support for retrieving information about the quality requirements that the user’s password must satisfy.
  • We updated the set of potential authentication failure reasons to include an additional failure type for cases in which a password used in a bind request failed to satisfy one or more of the configured password validators.
  • We added a new password policy state account usability error that may be used if an account is locked because the user attempted to authenticate with a password that failed to satisfy one or more of the configured password validators.
  • We added a new password policy state account usability warning that may be used if an account contains a password that is encoded with a deprecated password storage scheme.
  • We updated the collect-support-data tool to add the ability to specify the amount of data to capture from each log file to be included in the support data archive. We have also updated client-side support for the administrative task and extended operation that may be used to invoke collect-support-data processing against a remote server to include support for the new arguments.