Active Directory

Active Directory provides an LDAPv3 compliant interface for performing operations and Ldaptive can be used as a client.

Controls

The following controls have concrete implementations in Ldaptive. A matrix of control to supported provider is shown here:

  JNDI JLDAP Apache LDAP UnboundID OpenDJ
DirSync
ExtendedDn
ForceUpdate
GetStats
LazyCommit
Notification
PermissiveModify
RangeRetrievalNoerr
SearchOptions
ShowDeactivatedLink
ShowDeleted
ShowRecycled
VerifyName
Functionality exists in the provider API and has been confirmed
Functionality does not exist in the provider API
Functionality exists in the provider API, but did not work in our test environment
? Functionality exists in the provider API, but has not been integrated into the ldaptive provider

Global Catalog

The Global Catalog enables searching for Active Directory objects in any domain in the forest without the need for subordinate referrals. Because the Global Catalog contains only a subset of the attributes of an object, using it is viable only if the attributes requested for the search results are stored in the Global Catalog. (Note the GC is accessible on port 3268/3269, not the standard LDAP ports of 389/636.)

Binary Attributes

Some attributes in the Active Directory may be binary and need to be declared as such when they are retrieved. To work around this issue you can invoke: SearchRequest.setBinaryAttributes(new String[] {"objectSid", "objectGUID"}). This will allow you to properly retrieve these attributes as byte arrays. If you prefer to use these attributes in their string forms, ldaptive provides two handlers that will automatically convert these values for you:

Connection conn = DefaultConnectionFactory.getConnection("ldap://directory.ldaptive.org");
try {
  conn.open();
  SearchOperation search = new SearchOperation(conn);
  SearchRequest request = new SearchRequest("dc=ldaptive,dc=org", "(uid=dfisher)");
  request.setSearchEntryHandlers(new ObjectSidHandler(), new ObjectGuidHandler());
  SearchResult result = search.execute(request).getResult();
  for (LdapEntry entry : result.getEntries()) {
    // do something useful with the entry
  }

} finally {
  conn.close();
}

Using these search entry handlers will return values like:

dn: uid=dfisher,ou=people,dc=ldaptive,dc=org
objectGUID: {B1DB3CCA-72BD-4F31-9EBF-C70CD44BDA32}
objectSid: S-1-5-21-1051162837-3568060411-1686669321-1105

JNDI Provider

Referrals

JNDI provides three ways in which to handle LDAP referrals: ‘ignore’, ‘follow’, and ‘throw’. Ldaptive does not expose the ‘ignore’ option as this sends the ManageDsaIT control. Since Active Directory does not support this control, you will avoid javax.naming.PartialResultException: Unprocessed Continuation Reference(s) exceptions. By default ldaptive sets the ‘throw’ option and exposes any referrals in SearchResult#getReferences().

If you are confident that all the referrals returned by the Active Directory can be followed then SearchRequest#setReferralHandler(new SearchReferralHandler()) can be invoked. Note that referrals often contain hostnames other than the server that is being searched. The authentication credentials for the original connection must be valid for any hosts supplied by the referrals. In addition, these hostnames must be DNS resolvable and reachable in order for the search to be successful. javax.naming.CommunicationException and java.net.UnknownHostException are commonly encountered when following referrals.

Note that Active Directory will typically use referrals for any search bases that access domain DNS objects at the root level. e.g. dc=mydomain,dc=org.