We have just released the 2.0.0 version of the UnboundID LDAP SDK for Java. It is available for download on the UnboundID LDAP SDK product page or on the SourceForge project page.

This is a major new release that includes significant new functionality, including:

• A persistence API that makes it easy to interact with entries in an LDAP directory as Java objects. Annotations are used to establish mappings between LDAP attributes and content in Java objects, and the data is stored in a format that makes it easily accessible by other APIs as well. Tools are provided to help you generate source code from existing schema, or generate LDAP schema from annotated source.

• A listener API that makes it easy to develop applications that can listen for communication from LDAP clients (i.e., applications which act as an LDAP server). A new tool is provided which makes use of this API to act as a simple LDAP proxy that can intercept and decode LDAP communication as it passes between an LDAP client and server.

• New types of command-line arguments, including Boolean value arguments, duration arguments, and search scope arguments. The file argument type has also been updated to allow you to specify a base directory for relative paths so that non-absolute paths will be relative to a specified location.

There are also a few other minor enhancements and bug fixes.

I’ve never really been a big fan of Active Directory. Microsoft tends to treat standards more like suggestions than rules, and Active Directory has some good examples of that. I was recently asked a question about how you can change a password in Active Directory over LDAP. In most directory servers, you would either use the LDAP password modify extended operation (as described in RFC 3062), or you would perform a simple modify operation to replace the userPassword attribute with the clear-text password (and the server would automatically perform any necessary encoding to obscure the value). However, Active Directory has a number of very unusual requirements, so it’s probably worth making a note of them. They include:

• Active Directory doesn’t appear to support the password modify extended operation, so you must change passwords using a normal LDAP modify operation.
• Active Directory stores passwords in the unicodePwd attribute, rather than userPassword.
• Active Directory will only accept password changes over secure connections. I have only ever used SSL. It may be that you can also use StartTLS, or perhaps SASL with confidentiality, but I’m not sure about that.
• The new password must be enclosed in quotation marks, and it must use a UTF-16 little-endian encoding.
• Active Directory may impose some strength requirements on the password, although exactly what those requirements are may vary from one instance to another.

Knowing these requirements, you should be able to write code using any LDAP API that will allow you to perform password changes in Active Directory. The following code demonstrates how to do it using the UnboundID LDAP SDK for Java:

import java.io.UnsupportedEncodingException;
import javax.net.ssl.SSLSocketFactory;
import com.unboundid.ldap.sdk.LDAPConnection;
import com.unboundid.ldap.sdk.LDAPException;
import com.unboundid.ldap.sdk.Modification;
import com.unboundid.ldap.sdk.ModificationType;
import com.unboundid.ldap.sdk.ResultCode;
import com.unboundid.util.StaticUtils;
import com.unboundid.util.ssl.SSLUtil;
import com.unboundid.util.ssl.TrustAllTrustManager;
/**
* This class provides a simple utility method that may be used to change the
* password of a user stored in an Active Directory server instance.
*/
public class ADPasswordChange
{
/**
* Perform the complete set of processing required to change a user's
* password in an Active Directory server.
*
* @param  adHost        The address of the Active Directory server.
* @param  adSSLPort     The SSL-based port of the Active Directory server
*                       (typically 636).
* @param  bindDN        The DN to use when binding to the Active Directory
*                       server instance.  It must have sufficient permission
*                       to change user passwords.
* @param  bindPassword  The clear-text password to use when binding to the
*                       Active Directory server instance.
* @param  userDN        The DN of the user whose password should be changed.
* @param  newPassword   The clear-text new password to assign to the user.
*
* @throws  LDAPException  If a problem is encountered while performing any
*                         of the required processing.
*/
public static void changePasswordInAD(final String adHost,
final int adSSLPort,
final String bindDN,
final String bindPassword,
final String userDN,
final String newPassword)
throws LDAPException
{
// Properly encode the password.  It must be enclosed in quotation marks,
// and it must use a UTF-16LE encoding.
System.out.println("Going to encode the password.");
final byte[] quotedPasswordBytes;
try
{
final String quotedPassword = '"' + newPassword + '"';
quotedPasswordBytes = quotedPassword.getBytes("UTF-16LE");
}
catch (final UnsupportedEncodingException uee)
{
throw new LDAPException(ResultCode.LOCAL_ERROR,
"Unable to encode the quoted password in UTF-16LE:  " +
StaticUtils.getExceptionMessage(uee),
uee);
}
// Create an SSL socket factory to use during the course of establishing
// an SSL-based connection to the server.  For simplicity, we'll cheat and
// use a trust manager that will trust any certificate that the server
// presents, but in production environments you should validate the
// certificate more carefully.
System.out.println("Going to create the SSL socket factory.");
final SSLSocketFactory socketFactory;
final SSLUtil sslUtil = new SSLUtil(new TrustAllTrustManager());
try
{
socketFactory = sslUtil.createSSLSocketFactory();
}
catch (final Exception e)
{
throw new LDAPException(ResultCode.LOCAL_ERROR,
"Unable to create an SSL socket factory to use for establishing " +
"a secure connection:  " + StaticUtils.getExceptionMessage(e),
e);
}
// Create a secure connection to the Active Directory server.
System.out.println("Going to establish the secure connection.");
final LDAPConnection connection = new LDAPConnection(socketFactory, adHost,
adSSLPort, bindDN, bindPassword);
try
{
// Attempt to modify the user password.
System.out.println("Going to replace the user's password.");
final Modification mod = new Modification(ModificationType.REPLACE,
"unicodePwd", quotedPasswordBytes);
connection.modify(userDN, mod);
}
finally
{
System.out.println("Closing the connection.");
connection.close();
}
}
}

I have just released a new 1.1.5 release of the UnboundID LDAP SDK for Java. It is available for download from the UnboundID LDAP SDK product page, as well as from the SourceForge project page. It should be available in the Maven Central Repository in the near future.

This release has only a few changes over the previous 1.1.4 version, including:

• I have fixed a bug which could cause problems when using SSL or StartTLS over high-latency networks.

• I have fixed a bug which could cause LDAPConnection.close to close the connection without an unbind request if the connection had previously been closed and re-established.

• I have added support for the content synchronization operation as defined in RFC 4533.

I have also released a new 2.0.0-rc1 build of the LDAP SDK, which is available on the SourceForge project page. This is hopefully the last build prior to the official release. It includes the above changes, as well as the following additional changes:

• The default object encoder in the persistence framework now provides support for URL, URI, and enum objects.

• Java source code generated by the persistence framework now includes static getPersister and decode convenience methods which make it easier to interact with objects using the persistence framework.

• LDAP command-line tools now provide an option that allows you to specify the format for the key store and/or trust store when using SSL or StartTLS. It still uses the JKS format by default, but you can request an alternate format like JCEKS or PKCS12 if desired.

• The LDAP assertion control implementation now includes a generate convenience method that makes it easy to generate an assertion request control based on a provided entry. It can be used to make it easier to ensure that some or all of the attributes in the entry have not been updated since the entry was last retrieved.

• I have added a new BooleanValueArgument class, which is similar to the BooleanArgument class except that it takes an explicit value (e.g., “true”, or “false”, although it will accept other strings as well, including “yes”, “on”, and “1” for true, and “no”, “off”, and “0” for false) rather than inferring the value based only on whether the argument is present.

• I have added a new DurationArgument class, which combines an integer with a time unit (e.g., “10ms”). It can be used to specify lengths of time.

• I have updated the FileArgument class so that it is possible to specify a base DN for relative paths. By default, relative paths will be relative to the current working directory, but you can indicate that they should instead be relative to a specified parent directory.

I have published two new builds of the UnboundID LDAP SDK for Java. The 1.1.4 build is an official release that contains a number of minor enhancements and bug fixes over the previous 1.1.3 release. The 2.0.0-beta1 build is a preview of our next major release and includes significant new functionality, including frameworks for persisting Java objects in an LDAP directory and for more easily creating applications which accept communication from LDAP clients. The 1.1.4 version is available for immediate download on the UnboundID website, and both the 1.1.4 and 2.0.0-beta1 builds are available for download from the SourceForge project page. The 1.1.4 release is fully supported for production use and has a stable API that will not change in incompatible ways in the future. Although we also believe that the 2.0.0-beta1 build is also production ready, we do reserve the right to change any of the new APIs prior to the official release if there is a compelling reason to do so.

Some of the most notable changes between the 1.1.3 and 1.1.4 releases include:

• I have fixed a bug that could cause problems when trying to use SSL or StartTLS in conjunction with synchronous communication mode. This problem primarily occurred in deployments in which the client and server were not on the same network and there could be a significant delay between phases of the negotiation.

• A new search-and-mod-rate command line tool has been added that can be used to test LDAP server performance under a combined load of search and modify operations. The searches will be performed in much the same way as with the searchrate tool, but each entry returned will also be modified.

• The ldapsearch tool has been updated to provide an option to repeat the search multiple times at regular intervals. This can be useful, for example, if you want to periodically retrieve monitor information from the server.

• The traditional and thread-local connection pool implementations have been updated to provide an option to avoid closing and re-establishing a large number of connections in a short period of time in the event that a maximum connection time limit has been configured. It is now possible to specify the minimum length of time that should pass between closures of expired connections.

• If a problem is encountered while trying to decode a response read from the directory server, the exception that is thrown now includes better information about the problem that actually occurred to make it easier to diagnose the problem.

• The searchrate, modrate, and authrate tools have been updated to better handle the case in which the target directory server becomes unavailable during processing. The tools are now better able to re-establish connections to that server when it becomes available again.

The 2.0.0-beta1 build includes everything in the 1.1.4 release, as well as additional new functionality. In previous blog posts, I have discussed some of the features added to the LDAP SDK persistence framework, and that functionality has been further improved in this new version. Some of those changes include better support for operational attributes, the ability to use lazy initialization for a specified set of attributes, and adding support for simple bind operations. It also includes a new listener API, which makes it possible to easily create applications capable of accepting communication from LDAP clients. A new ldap-debugger example tool makes use of the listener API and can serve as a simple proxy which decodes all LDAP communication that passes through it.

We are very interested in getting feedback on the new APIs included in the upcoming 2.0.0 release because we are committed to maintaining compatibility once they have been officially released. If you are interested in either the persistence or the listener APIs, please at least look over the javadoc and let us know what you think.