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.

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 that it can now handle schema elements with a description value that is an empty string. Although empty descriptions (or other types of quoted strings) are not permitted in schema element definitions, some servers allow them. Empty descriptions are still not allowed by default, but that behavior can be overridden with a code change or a system property.
  • We added a new IA5 string argument value validator that can be used to require that the values of associated arguments are only permitted to contain ASCII characters. The manage-certificates tool has also been updated to provide better validation for certificate components that are required to be IA5 strings, including DNS names and email addresses in the subject alternative name extension.
  • We added support for encoding and decoding timestamps in the ISO 8601 format described in RFC 3339.
  • We updated the LDAP command-line tool framework so that if the --help-sasl argument is used in conjunction with a --saslOption argument that specifies the name of the SASL mechanism, the output will only include help information for that mechanism.
  • We fixed a bug in the StaticUtils.isASCIIString method that caused it to only look at the lowest byte for each character in the provided string.
  • We added new ByteStringBuffer utility methods, including getting individual bytes or sets of bytes at a specified position, for determining whether the buffer starts with or ends with a given set of bytes, and for reading the contents of a file or input stream into the buffer.
  • We added new StaticUtils convenience methods for reading and writing files as bytes, strings, or lists of lines.
  • We added support for new password policy state account usability warning and notice types for the Ping Identity Directory Server. The new types can be used to indicate that the account has too many outstanding authentication failures, but that the server will take some other action (for example, delaying the bind response) instead of completely preventing authentication.
  • We fixed an issue in the LDAP SDK’s JSON-formatted debug logging support for debug messages containing exceptions with another exception as the underlying cause.
  • We fixed an issue with the command-line tool framework that could prevent it from setting an argument value from a properties file even though that same value would have been permitted if it had been provided directly on the command line.
  • We updated the default standard schema provided with the LDAP SDK to include additional attribute syntaxes, matching rule, attribute type, and object class definitions.

UnboundID LDAP SDK for Java 5.0.1

The UnboundID LDAP SDK for Java is a fast, powerful, user-friendly, and completely free Java library for communicating with LDAP directory servers and performing other LDAP-related processing. We have just released version 5.0.1 of the LDAP SDK, and it is available for download from GitHub and SourceForge, as well as from the Maven Central Repository. The release notes are available online at https://docs.ldap.com/ldap-sdk/docs/release-notes.html.

This is a minor release that was primarily created in service of an upcoming release of the Ping Identity Directory Server, as it fixes an issue in a tool that only impacts that new release. Nevertheless, there are a couple of additional updates, so we’re making it publicly available.

The changes over the previous 5.0.0 release include:

  • We added a new LDAP connection logger API that can be used to keep a record of processing performed by the LDAP SDK, including successful and failed connection attempts, operation requests and responses (including non-final responses like search result entries, search result references, and intermediate responses), and disconnects. The LDAP SDK includes a connection logger instance that formats messages as JSON objects, but it’s an extensible API, so you’re free to create your own implementation using whatever format you want.
  • We have updated the LDAP command-line tool framework to make it possible to specify the address of the target directory server(s) using either –host or –address as an alternative to the existing –hostname argument.
  • We fixed an issue that prevented the collect-support-data tool from running properly in local mode when using a secure connection (either SSL or StartTLS). This functionality only applies to an upcoming release of the Ping Identity Directory Server, so existing installations should not have been affected, and new installations will have the fix.
  • We made minor updates to the usage output for several command-line tools to improve wording and fix typos. We also fixed typos in other messages used throughout the LDAP SDK.

UnboundID LDAP SDK for Java 5.0.0, now available under the Apache License

The UnboundID LDAP SDK for Java is a fast, powerful, user-friendly, and completely free Java library for communicating with LDAP directory servers and performing other LDAP-related processing. We have just released version 5.0.0 of the LDAP SDK, and it is available for download from GitHub and SourceForge, as well as from the Maven Central Repository. The release notes are available online at https://docs.ldap.com/ldap-sdk/docs/release-notes.html.

The most significant change in this new release is that the LDAP SDK is now available under the terms of the Apache License, Version 2.0, which is a very permissive OSI-approved open source license. Although it was already open source under the terms of the GNU GPLv2 and LGPLv2.1, the Apache License imposes fewer restrictions on how you can use the LDAP SDK. You are no longer required to offer to redistribute the source code (even if you want to use a modified version), and there’s no longer any concern about whether you need to keep the LDAP SDK jar file as a separate component. The Apache License is well respected and is often seen as more compatible and easier to use in non-open-source software than the GNU license, so we hope that this will make it easier to use in your applications, whether open source or proprietary. The LDAP SDK is still available for use under the terms of the GPLv2 and LGPLv2.1 (as well as the non-open-source UnboundID LDAP SDK Free Use License), but we recommend that new users consider using it under the Apache License.

Aside from adding the new license, we made several code changes in this release as well. They include:

  • The LDAP SDK offers an LDAPConnectionDetailsJSONSpecification class that allows you to define a JSON file with all of the settings needed to create and authenticate individual LDAP connections or connection pools. We’ve updated this class so that it’s now possible to indicate that when establishing a connection that is secured with SSL or StartTLS, the LDAP SDK should automatically trust any certificates signed by an authority in the JVM’s default set of trusted issuers. This was already the default behavior if you didn’t provide your own trust store (or choose to blindly trust all certificates, which isn’t recommended for production use), but it’s now possible to use this option in conjunction with a provided trust store so that it’s possible to trust a certificate either through that trust store or through the JVM’s default set of trusted issuers.
  • The KeyStoreKeyManager can be used to obtain a certificate from a key store file if one is needed during TLS negotiation. We have updated this class to provide an option to better validate that the key store can actually be used by this purpose with the settings that you provide. If you use this option and supply the alias of the certificate you wish to use, then the key manager will now verify that the alias exists in the key store, that it’s associated with a private key entry (as opposed to a trusted certificate entry, which only contains the public portion of a certificate and isn’t suitable for use if you need to present that certificate to the peer), and that all of the certificates in the chain are currently within their validity window. If you don’t specify a certificate alias, then the validation will make sure that the key store contains at least one private key entry in which all of the certificates in the chain are within their validity window.
  • The TrustStoreTrustManager can be used in the course of determining whether to trust a certificate presented by a peer during TLS negotiation. We have improved performance and concurrency for this trust manager by eliminating unnecessary synchronization that forced interaction with the trust store to be single-threaded.
  • We fixed an issue that could interfere with GSSAPI authentication if a JAAS login module configuration was loaded and cached by the JVM before the login attempt. In such cases, the cached configuration could be used instead of the one that was intended.
  • The LDAPDebuggerRequestHandler can be used to log detailed information about LDAP requests and responses that pass through an application using the LDAP SDK’s LDAPListener framework (including the in-memory directory server and the ldap-debugger command-line tool). We fixed an issue that could cause messages to be held up in an internal buffer rather than immediately written out as soon as they’re logged. In some cases, this could significantly delay the appearance of these messages or could prevent them from being written out at all if the amount of data to be logged was never enough to fill that internal buffer.
  • We added a new JSONAccessLogRequestHandler to the LDAPListener framework. This can log information about requests and responses as JSON objects, which are both human-readable and machine-parseable. While the existing AccessLogRequestHandler produces output that can be parsed programmatically to some extent, it is more optimized for human readability.
  • The LDAP SDK offers debugging logging support that can be helpful in diagnosing problems whose cause may not otherwise be readily apparent. Previously, the debug messages were logged in a form that was primarily intended to be human-readable rather than machine-parseable. They are now written in a JSON format that is both human-readable and machine-parseable.
  • The manage-certificates command-line tool provides a utility for interacting with certificate key and trust stores in the Java JKS format or the standard PKCS#12 format. When displaying detailed information about certificates in a key or trust store, the tool may not have been able to properly decode public key information for certificates with 384-bit elliptic curve public keys, and it also may not have been able to properly decode a subject alternative names extension that included one or more directoryName values. While it was still possible to display most of the information about the affected certificates, the updated version can now provide the full details about those elements.
  • The Ping Identity Directory Server includes a collect-support-data utility that can be used to gather a variety of information from a server installation that can be very useful for troubleshooting problems, tuning performance and scalability, and better understanding the environment in which the server is running. Previously, this utility could only be invoked by logging into the system on which the server instance is running and running the command-line tool. We have now added a couple of additional mechanisms for running the utility. It can now be invoked via an administrative task (either as an individual event that is requested by a remote client or as a recurring task that runs on a regular basis) that will create the resulting support data archive in a specified location on the system (which may be a shared filesystem for easier exfiltration). It can also be invoked via an extended operation that will run the tool and stream its output and the resulting support data archive back to the client in the form of intermediate response messages. Further, although the logic for actually collecting all of this support information remains in the server, we have added the collect-support-data command-line tool to the LDAP SDK so that it is easier to invoke the tool against a remote server without needing to install the server software on the client system.
  • The Ping Identity Directory Server provides a monitor backend that authorized clients can use to obtain a wealth of useful information about the state of the server, and the LDAP SDK includes support for retrieving and parsing the information in these monitor entries. We have updated the LDAP SDK’s support for the general monitor (that is, the top-level “cn=monitor” entry) to make it easier to obtain information about the cluster with which the server is associated, the location of the server instance, and a unique identifier that was generated for the server when the instance was initially configured.
  • The LDAP SDK offers a Version class that provides version information for the LDAP SDK, including the version number and information about the repository (e.g., the repository URL and revision ID) from which the LDAP SDK source code was obtained. This information was previously only offered as public static final constants, but referencing these constants from third-party applications could lead to unexpected behavior thanks to a “feature” of the Java compiler that will directly imbed the values of those constants (even if they come from a separate library) in the Java bytecode that it generates. This means that if your application references these LDAP SDK version constants and you compile it against one version of the LDAP SDK, then those version constants will be placed directly into the compiled bytecode. If you upgrade the LDAP SDK version that you use without recompiling your application (e.g., by just replacing the LDAP SDK jar file with a newer version), the code referencing the LDAP SDK version would still have the old values. To address this, we have updated the Version class to provide methods for obtaining the values of all the version constants. If you use these methods to obtain the values rather than referencing the constants directly, then you will always get the correct LDAP SDK version information even if you update the LDAP SDK without recompiling your application.

Ping Identity Directory Server 8.0.0.0

We have just released version 8.0.0.0 of the Ping Identity Directory Server, along with new releases of the related Directory Proxy Server, Data Synchronization Server, Metrics Engine, and Delegated User Admin products. The release notes include a comprehensive list of features, enhancements, and fixes, but here are some of the most notable changes included in the release:

  • We have expanded support for the manage-profile tool to include the Directory Proxy Server, Data Synchronization Server, and Data Governance Server products. This allows you to set up, update, or reconfigure a server using the information in a provided profile. The profile defines the configuration, schema, extensions, certificates, encryption settings, and all the other components needed to configure a server instance exactly the way you want it.
  • We have updated the Directory Proxy Server so that it can use the topology registry to automatically discover and start using Ping Identity Directory Server instances without needing to change the Directory Proxy Server configuration.
  • We have improved our support for integrating with third-party monitoring services like Splunk by updating the stats collector plugin to support sending data in StatsD format to a specified endpoint. We have also updated the periodic stats logger so that it supports generating JSON-formatted output. The former CSV output format is also still supported. And we have added a new “Status Health Summary” monitor entry that provides a summary of the server’s current assessment of its health, which especially simplifies monitoring with third-party monitoring over JMX.
  • We have updated the Directory Server so that it now supports SCIMv2 in addition to the existing SCIMv1 and Directory REST API options for REST-based access to directory data. Formerly, SCIMv2 was only available through the Data Governance Server.
  • We have added a new replace-certificate tool that makes it easier to replace a server’s listener or inter-server certificate. The tool offers a non-interactive mode that is suitable for scripting support, but it also has a full-featured interactive mode that can walk you through the process of obtaining and installing a new certificate. The interactive mode will also provide you with the necessary commands to achieve the same result in non-interactive mode.
  • We have dramatically improved our support for account status notifications. We have defined a couple of new notification types that can be raised whenever an entry is created or modified by a request that matches a given set of criteria. We have also defined many new properties that can be used in the notifications. And we have added a new multi-part email account status notification handler that can be used to send plain-text and/or HTML-formatted email messages whenever an appropriate event occurs within the server.
  • We have added a new password validator that leverages the Pwned Passwords service to make it easier to reject passwords that are known to have been compromised in data breaches.
  • We have added a new password storage scheme that uses the Argon2i password hashing algorithm, which was selected as the winner of a 2015 password hashing competition.
  • We have updated our support for the PBKDF2 password storage scheme so that it offers additional variants that leverage the 256-bit, 384-bit, and 512-bit SHA-2 digest algorithms. We have also updated the default salt length and iteration count values in accordance with NIST SP 800-63B recommendations.
  • We have improved the server’s support for generating passwords. We have added a new request control that can be included in add requests to have the server generate a password for the new entry and return it to the client in a corresponding response control. We have also added a new extended operation that can be used to request that the server generate one or more passwords that can be provided to the end user as new password suggestions when creating an account or changing a password.
  • We updated the Data Synchronization Server’s password sync agent for Active Directory so that it encodes passwords using a salted 256-bit SHA-2 digest rather than the previous salted SHA-1 digest. The SHA-1 digest can still be used if necessary for purposes of backward compatibility.
  • We updated the Data Synchronization Server’s create-sync-pipe-config tool to add support for using the PingOne for Customers service as a sync source or destination.
  • We updated Delegated Admin’s support for constructed attributes. Constructed attributes can now be made read-only, and they can also reference other constructed attributes. Constructed attribute values can now also be updated when any of their dependent attributes change.
  • We updated the HTTP external server configuration to make it possible to specify the alias of the certificate chain to be presented during mutual TLS negotiation.
  • We added a new JVM-default trust manager provider that can be used to automatically trust any certificate signed by one of the trusted issuers in the JVM’s default trust store.
  • We have added a new Server SDK API for sending email messages.
  • We updated the exec task to make it possible to specify the current working directory for the command that is being executed. The server previously always used the server root as the current working directory, and that is still the default if no alternate path is specified.
  • We updated the collect-support-data tool to add a --duration argument that will cause it to capture log content for the specified duration up to the current time.
  • We fixed an issue that prevented assured replication from being honored for requests received via SCIM or the Directory REST API.
  • We fixed an issue in which the restore tool might not have automatically restored all of the dependencies of an incremental backup.
  • We fixed an issue in which the Directory Proxy Server could incorrectly report a success result for an entry-balanced search operation in which all attempts in a backend set failed with a timeout.
  • We updated log file rotation listeners, including the summarize access log and copy log file listeners, so that they perform their processing in a background thread. This can help ensure that their processing does not temporarily block logging attempts on very busy servers.
  • We fixed an issue in which the verify-index tool could report spurious error messages when examining index keys containing multi-byte UTF-8 characters.
  • We fixed an issue in which escaped special characters in schema extensions may not be handled properly. This could cause unexpected or incorrect behavior in cases where those values are interpreted by the server (for example, in the X-VALUE-REGEX constraint in attribute type definitions).
  • We fixed an issue that could cause access log messages for bind and StartTLS operations to report the client connection policy that was previously in use for the connection rather than the new policy that was assigned as a result of the associated operation.