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, PKCS12, or BCFKS key store.

• We added StaticUtils convenience methods for generating random bytes, integers, and strings, optionally using cryptographically secure random number generators.

• We updated the documentation to add draft-melnikov-scram-bis and to update draft-melnikov-scram-sha-512 and draft-melnikov-scram-sha3-512 in the set of LDAP-related specifications.

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.

• We updated the documentation to include the latest revision of draft-ietf-kitten-password-storage in the set of LDAP-related specifications.

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

UnboundID LDAP SDK for Java 5.1.4

We have just released version 5.1.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.

The release notes contain a more complete overview of the changes included since the 5.1.3 release, but here’s a quick overview:

• We fixed an issue with the fewest connections and round-robin server sets that could cause them to leave a background thread running if one of the servers it had been using goes away permanently.

• We updated the TLS cipher suite selector to improve compatibility with JVMs (like the one provided by IBM) that use an “SSL_” prefix for all cipher suite names, rather than using “TLS_” for suites associated with the TLS protocol and only using “SSL_” for suites associated with legacy SSL protocols.

• We have updated the TLS cipher suite selector to improve the order in which it returns the names of the recommended suites.

• We have added new key and trust manager implementations that can use X.509 certificates and PKCS #8 private keys read from PEM files. We have also added new utility classes for reading certificates and private keys from PEM files.

• We updated the LDAP SDK to support running in a FIPS 140-2-compliant mode using the Bouncy Castle FIPS provider (and the associated JSSE provider). The Bouncy Castle libraries are not provided as part of the LDAP SDK, but if they are separately obtained and included in the classpath, then the LDAP SDK can be configured to operate in a FIPS-compliant manner.

• We have updated the manage-certificates tool to support managing certificates in BCFKS (the Bouncy Castle FIPS-compliant key store format) files.

• We have updated the TLS cipher suite selector to exclude suites that rely on the SHA-1 digest algorithm from the recommended set of suites when running in FIPS-compliant mode.

• We improved an error message that could be used in an exception if a connection becomes invalid in the course of trying to send a request to the server.

• We updated the ldifmodify command-line tool to allow ignoring duplicate attempts to delete the same entry, and attempts to delete or modify entries that do not exist in the LDIF file.

• We have updated support for the proprietary get user resource limits request control to allow clients to request that the server not return information about the user’s group membership in the response control. This can help improve performance when using the control, especially in servers with large numbers of dynamic groups.

• We have updated the LDAP SDK documentation to include the latest versions of draft-coretta-x660-ldap and draft-ietf-kitten-password-storage in the set of LDAP-related specifications.

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.

• We updated the documentation to include the latest versions of the draft-melnikov-scram-sha-512, draft-melnikov-scram-sha3-512, and draft-ietf-kitten-password-storage drafts in the set of LDAP-related specifications.

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

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

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

UnboundID LDAP SDK for Java 5.1.0

UnboundID LDAP SDK for Java version 5.1.0 has been released and 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 the changes since the previous 5.0.1 release, but here’s a summary:

• We fixed an issue in which the JVM-default trust manager did not always correctly handle cross-signed issuer certificates when the presented chain included an expired issuer certificate. It will now check to see if it can build a valid path with an alternate trust anchor.

• We added a new SchemaValidator class that can identify all kinds of problems with LDAP schema definitions. We also provide a new validate-ldap-schema command-line tool that will examine definitions contained in one or more LDIF files and report any problems that it finds.

• We updated the in-memory-directory-server command-line tool to validate any schema definitions provided through the --useSchemaFile argument. Even if there are problems, the server will still try to use that schema to the best of its ability (as was previously the case). The --doNotValidateSchemaDefnitions argument can be used to disable the new validation if it is not desired.

• We added a new ldappasswordmodify command-line tool that can be used to perform a self password change or an administrative password reset. It supports the password modify extended operation (as described in RFC 3062), and it can also change passwords using a regular LDAP modify operation or using an Active Directory-specific modification.

• We added three new command-line tools for performing operations on data contained in LDIF files:

  • The ldifsearch tool can be used to identify entries that match a given set of search criteria.
  • The ldifmodify tool can be used to apply a set of add, delete, modify, and modify DN changes to LDIF data.
  • The ldif-diff tool can be used to identify differences between data in two provided LDIF files and report the differences in the form of LDIF change records.

• We added a new version of the ldapcompare tool that can be used to perform LDAP compare operations in a directory server. The new version offers a lot of additional functionality like support for performing multiple compare assertions and using a variety of request controls, and it can generate parseable output in tab-delimited text, CSV, or JSON formats.

• We updated the in-memory directory server to make it possible to add custom attributes to the root DSE. While it was already possible to replace the entire root DSE entry with a static entry, this new approach makes it possible to retain some dynamic content (for example, changelog-related attributes) while still customizing other attributes.

• We made several changes in our support for entries with the ldapSubEntry object class:

  • We added a new RFC3672SubentriesRequestControl class with support for the LDAP subentries request control as described in RFC 3672.
  • The LDAP SDK already had support for an alternate version of the control described in draft-ietf-ldup-subentry through the SubentriesRequestControl class, but that class has been deprecated in favor of a new DraftLDUPSubentriesRequestControl class, which helps avoid confusion with the class that implements the RFC 3672 version of the control. The deprecated class is still fully functional and will be kept to preserve backward compatibility, but we recommend updating code that uses the old class for the sake of clarity.
  • The in-memory directory server has been updated with support for the RFC 3672 version of the control. It already had support for the draft-ietf-ldup-subentry version.
  • The in-memory directory server has been updated so that it will return entries with the ldapSubEntry object class if the filter includes an “(objectClass=ldapSubEntry)” component.
  • The ldapsearch command-line tool has been updated with support for the RFC 3672 version of the LDAP subentries control, using the new --rfc3672Subentries argument. It already had support for the draft-ietf-ldup-subentry version of the control through the --includeSubentries argument, and that argument is still available, but we now recommend using --draftLDUPSubentries instead for the sake of clarity.

• We updated the ldapsearch tool to add a new “values-only” output format (as an alternative to the existing LDIF, tab-delimited text, CSV, and JSON output formats). If this output format is selected, then it will only output the values of the requested attributes without any entry DNs or attribute names. This can help extract raw attribute values from a directory server from a script without the need for any additional text processing.

• We updated the ldapsearch tool to add a new --requireMatch argument. If this argument is provided and the search completes successfully but does not return any entries, then the tool will have an exit code of 94 (corresponding to the noResultsReturned result code) rather than zero. This argument does not have any visible effect on the output.

• We updated the round-robin and fewest connections servers sets to expose the blacklist manager that they use to avoid trying to establish connections to servers that are believed to be unavailable.

• We updated the manage-certificates tool to make it easier to list and export certificates from the JVM’s default trust store without needing to know the path to the appropriate file.

• We improved the logic that the LDAP SDK uses when selecting ordering and substring matching rules for ordering operations involving attributes that are defined in the schema but whose definition does not specify an ordering matching rule. It will now try to infer an appropriate ordering matching rule from the equality matching rule before trying other alternatives like inferring a rule from the associated syntax or using a default rule.

• We updated the LDAP command-line tool framework to make it easier and more convenient to communicate securely with the Ping Identity Directory Server (and other related server products). This includes:

  • We added a new TopologyRegistryTrustManager class that can use information in the server’s topology registry to determine whether to trust the certificates for instances in the topology.
  • If no trust-related arguments are specified when running the tool, it will now check the server’s default trust store and the topology registry to determine whether the presented certificate should be trusted. It will still also check the JVM’s default trust store, and it will still fall back to interactively prompting the user if the certificate cannot be trusted through other means.

• We streamlined the process that LDAP command-line tools use to establish and authenticate connections when run in interactive mode. It will now recommend TLS encryption over unencrypted communication with a simplified set of arguments, and it will recommend simple authentication over unauthenticated connections. Further, when the tool is part of a Ping Identity Directory Server (or related server product) installation, it will read the configuration to determine the appropriate port to suggest when connecting to the server.

• We made several improvements to the summarize-access-log tool that can be used to examine Ping Identity Directory Server access logs. These include:

  • You can now customize the maximum number of values to display for each item. It was previously hard-coded to use a limit of 20 values. If any values were omitted, then it will now tell you how many were left out.
  • You can now choose to de-anonymize the output to obtain the specific attribute values used in search filters and entry DNs (instead of displaying question marks as placeholders).
  • The output will now include information about the most common TLS protocols and cipher suites used for secure communication.
  • The output will now include the most common successful and failed bind DNs and the most common authentication mechanisms.
  • The output will now include the most common DNs used as alternate authorization identities (e.g., via the proxied authorization request control).
  • The output will now include the most common filters used for unindexed searches, the most common base DNs for searches with non-baseObject scopes, the filters for searches taking the longest to complete, and the most common filters for searches returning zero, one, or multiple entries.
  • When summarizing the most commonly invoked types of extended operations, the tool will now try to provide a human-readable name for the extended operation in addition to its OID.

• We added client-side support for obtaining password policy state information from the Ping Identity Directory Server’s ds-pwp-state-json virtual attribute.

• We added client-side support for the new populate composed attribute values and generate server profile administrative tasks in the Ping Identity Directory Server.

• We added a new OID.parseNumericOID method that can be used to parse a provided string as a valid numeric object identifier, optionally performing strict validation. If the provided string does not represent a valid numeric OID, then the method will throw an exception with a message that explains the problem.

• We improved the error messages generated for problems that may arise when parsing schema definitions.

• We updated the schema parsing code so ...