The class LdapUserProvider), is an abstract base class to fetch LDAP entries. It provides all general LDAP-related functionality, especially session handling, searching and caching. It is abstract concerning the membership relation which depends on the particular underlying LDAP schema. This class can not be configured as provider class but can be subclassed by concrete provider classes. It has some configuration options (see LdapUserProviderConfigurationProperties), many of which are specific to concrete subclasses, like particular LDAP attributes for names and IDs. Subclasses can override com.coremedia.ldap.LdapUserProvider.completeJndiConfiguration and com.coremedia.ldap.LdapUserProvider.completeLdapConfiguration to complete the configuration with reasonable default values in order to allow for short configurations. Ideally, only a few environmental properties like the LDAP hostname and the account to use need to be configured, like in the above example for an ActiveDirectoryUserProvider).

All properties which start with java.naming are evaluated by the JNDI framework. Some mandatory java.naming properties, like java.naming.security.principal and java.naming.security.credentials are covered by the JndiConfigurationProperties, so that you can configure them directly as Spring configuration properties. These properties are sufficient for most JNDI environments. If you need other java.naming properties in your environment, though, you can add them to the generic Map-valued cap.server.userproviders.properties property, and the LdapUserProvider propagates them to the JNDI environment.

cap.server.userproviders[0].java.naming.security.principal=\
CN=Rudy ReadOnly,CN=Users,DC=acme,DC=com
cap.server.userproviders[0].java.naming.security.credentials=123456
cap.server.userproviders[0].properties[java.naming.language]=en

        

The last mandatory environmental property denotes the distinguished names of the LDAP subtrees to search for users and groups. In the easiest case, you simply configure a single high-level subtree. In more complex LDAP directory layouts, you might want to restrict the CMS access more fine grained to particular subtrees. The following example configures the CN=Users subtree of the domain as base distinguished name, which is suitable for the default ActiveDirectory structure.

cap.server.userproviders[0].ldap.base-distinguished-names[0]=\
CN=Users,DC=acme,DC=com

Caution

Due to a bug in the JNDI implementation since Java 8 CoreMedia's LDAP integration cannot correctly cope with referrals. If you use Active Directory with Trust Relationships, you can only use DNs underneath the DC level. For instance, it works fine with CN=Users,DC=example,DC=org, but it crashes with DC=example,DC=org. The problem manifests in exceptions like

  2016-03-01 16:24:23 [ERROR] com.coremedia.ldap.LdapUserProvider - Exception while serving
  com.coremedia.ldap.ad.ActiveDirectoryUserProvider#getUsers: java.util.Vector cannot be cast
  to java.lang.String
  java.lang.ClassCastException: java.util.Vector cannot be cast to java.lang.String
  at com.sun.jndi.ldap.LdapReferralException.getNextReferral(LdapReferralException.java:241)
  ~[na:1.8.0_65]
  at com.sun.jndi.ldap.LdapReferralException.skipReferral(LdapReferralException.java:201) ~[na:1.8.0_65]
  at com.coremedia.ldap.impl.LdapConnector.ldapSearch(LdapConnector.java:335)
  ~[coremedia-ldap-7.1.11-5.jar:7.1.11-5]

If you cannot express the search scope for users and groups in terms of distinguished names, you may specify two sorts of filters: OU filters (LdapUserProviderConfigurationProperties.Ou#filter), which operate on the LDAP level, and member filters (LdapUserProviderConfigurationProperties#memberFilter), which operate on the Java level. Both have negative drawbacks (see their Javadoc for details), though, so you should try to get along with distinguished names only.