CoreMedia Content Server Manual, Version 7.5.45-10
3.13. LDAP Integration | 3.13.4. ActiveDirectoryUserProvider

CoreMedia CMS ships with a com.coremedia.ldap.UserProvider2 class for accessing Microsoft's Active Directory Server: The com.coremedia.ldap.ad.ActiveDirectoryUserProvider. For using it you have to configure the following:

Before you may use your Active Directory Accounts within your CoreMedia CMS, you have to define rules for all the given groups your CMS user may be members of. You have to do this as user admin. Remember that all CoreMedia system users are not administrated within the Active Directory or any other LDAP server but only from inside of the CoreMedia system itself. Thus, you must not choose any domain when logging into the CoreMedia CMS as user admin.

Note

The above description is made for a Windows Server 2008. Windows Server 2000/2003 are using slightly different LDAP schemas. Basically users and groups are stored in different common names. All user accounts are stored beneath CN=Accounts,DC=<your>[,DC=<domain>]* whereas groups are stored beneath CN=Groups,DC=<your>[,DC=<domain>]*. In order to connect to an Active Directory Server on such an environment you have to change the following property: Adjust the base dns from step 2.c as follows: com.coremedia.ldap.basedns=OU=Accounts,DC=<your>,[DC=<domain>]*;OU=Groups,DC=<your>[,DC=<domain>]*

Common Customizations

By default the ActiveDirectoryUserProvider uses the userPrincipalName attribute of Active Directory's standard schema as value for a user's name and domain. However, in some projects this is not suitable for whatever reason. This section sketches popular customizations concerning users' names and domains. The approaches assume that all users are unique with respect to the considered attributes. In particular cases this may not be given, and your UserProvider might need additional refinements.

Deviating User Domains

In Active Directory a user's domain is modeled in two ways: It can be derived from the DC components of the Distinguished Name, and it is part of the userPricipalName attribute. Usually the two domains are consistent. If the domains by Distinguished Name and by userPrincipalName are ambiguous for some users however, you must decide with which domain you want your users to appear in the CMS.

Domain from userPrincipalName

If you want to use the domains from the userPrincipalName, you must specify the UserProvider's domains explicitely, because they cannot be derived from the configured basedns:

com.coremedia.ldap.domains=example.org;other.domain.org;...

Include all user domains that may occur in userPrincipalName attributes, and all groups' domains. The latter still correspond to the Distinguished Names and must thus be consistent with the basedns.

For the LdapLoginModule you must configure the domain of the userPrincipalName in jaas.conf. If there are multiple user domains, you need an LdapLoginModule for each domain.

Domain from Distinguished Name

If you want to use the domains from the distinguished names, you must handle the userPrincipalName attribute appropriately, so that the domain part is ignored. Override the following methods of the ActiveDirectoryUserProvider:

  protected String userDomainToAttrValue(String name, String domain, Properties props, int mode) {
    return null;
  }

  protected String attrValueToUserDomain(Object domain, String dn, Attributes attrs, Properties props) {
    return dnToDomain(dn);
  }

  protected String userNameToAttrValue(String name, String domain, Properties props, int mode) {
    return ldapSearchTerm(name, mode) + "@*";
  }

Alternative User Name Attributes

E-mail

The standard AD schema features the mail attribute ("E-mail" in the AD UI), which has the same format "name@domain" as userPrincipalName. So you can easily switch the attribute. Moreover, you have to add the mail attribute to user.attrs in order to be fetched at all, and handle the ambiguous domains as described in the section called “Domain from userPrincipalName”. In jndi-ad.properties the change looks like this:

com.coremedia.ldap.domains=example.org;other.domain.org;...
com.coremedia.ldap.user.attrs= ... mail
com.coremedia.ldap.user.filter=(&(objectClass=user)(mail=*))
com.coremedia.ldap.user.nameattr=mail
com.coremedia.ldap.user.domainattr=mail

sAMAccountName

Unlike the userPrincipalName the sAMAccountName attribute consists only of the actual name. So you must override the methods of the ActiveDirectoryUserProvider that deal with conversion of name and domain values:

  protected String userNameToAttrValue(String name, String domain, Properties props, int mode) {
    return ldapSearchTerm(name, mode);
  }

  protected String attrValueToUserName(Object name, String dn, Attributes attrs, Properties props) {
    return (String)name;
  }

  protected String userDomainToAttrValue(String name, String domain, Properties props, int mode) {
    return null;
  }

  protected String attrValueToUserDomain(Object domain, String dn, Attributes attrs, Properties props) {
    return dnToDomain(dn);
  }

Next, exchange the name attribute in the jndi-ad.properties:

com.coremedia.ldap.user.filter=(&(objectClass=user)(sAMAccountName=*))
com.coremedia.ldap.user.nameattr=sAMAccountName