If you're using Microsoft Active Directory (MSAD), the tips on this page may help you. MSAD can be accessed via LDAP so the instructions in Changing to the LDAP Security DAO are applicable and should be consulted first.

Binding

MSAD allows you to uniquely specify users in two ways, in addition to the standard DN. If you're not having luck with the standard DN, give one of the two below a try. Each of the examples below is shown in the context of the userDn property of the Spring Security contextSource bean.

Note: The examples in this Binding section show the contextSource bean. Be aware that you may need to use the same notation (i.e. Kerberos or Windows domain) in your user DN patterns (in the authenticator bean).

Kerberos notation

Example: pentahoadmin@mycompany.com

applicationContext-security-ldap.properties

# backslash before colon to escape it
contextSource.providerUrl=ldap\://mycompany\:389
contextSource.userDn=pentahoadmin@mycompany.com
contextSource.password=secret

Windows domain notation

Example: MYCOMPANY\pentahoadmin

applicationContext-security-ldap.properties

# backslash before colon to escape it
contextSource.providerUrl=ldap\://mycompany\:389
# backslash before backslash to escape it
contextSource.userDn=MYCOMPANY\\pentahoadmin
contextSource.password=secret

Referrals

If more than one Active Directory instance is serving directory information, it may be necessary to enable referral following. This is done by modifying the contextSource bean. Basically you create a map (via the <map> element) and set that as the extraEnvVars property value. The map below has a single entry. The key part of the entry below matches the REFERRAL constant defined in the Context class. The value part in the entry is one of the following: follow, ignore, or throw. (These values are also defined in the javadoc for the REFERRAL constant.

<bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
  <constructor-arg value="${contextSource.providerUrl}"/>
  <property name="userDn" value="${contextSource.userDn}"/>
  <property name="password" value="${contextSource.password}"/>
  <property name="baseEnvironmentProperties">
    <map>
      <entry>
        <key>
          <value>java.naming.referral</value>
        </key>
        <value>follow</value>
      </entry>
    </map>
  </property>
</bean>

User DN Patterns vs. User Searches

In the LdapAuthenticator implementations provided by Spring Security (e.g. BindAuthenticator), you must either specify a userDnPatterns, or a userSearch, or both. If you're using the Kerberos or Windows domain notation, you should use userDnPatterns exclusively in your LdapAuthenticator.

Note: The reason that userDnPatterns is suggested when using Kerberos or Windows domain notation is that the LdapUserSearch implementations do not give the control over the DN that userDnPatterns does. (The LdapUserSearch implementations try to derive the DN in the standard format, which may or may not work in Active Directory.)

User DN Patterns

<bean id="authenticator" class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator">
  <constructor-arg>
    <ref local="contextSource" />
  </constructor-arg>
  <property name="userDnPatterns">
    <list>
      <value>{0}@mycompany.com</value>
      <!-- and/or -->
      <value>domain\{0}</value>
    </list>
  </property>
</bean>

User Searches

The sAMAccountName attribute should be used as the username in user searches. The searchSubtree property (which influences the SearchControls) should most likely be true. Otherwise, it searches the specified base plus one level down.

applicationContext-security-ldap.properties

# backslash before opening and closing braces to escape them
userSearch.searchFilter=(sAMAccountName=\{0\})

applicationContext-spring-security-ldap.xml

<bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg index="0" value="${userSearch.searchBase}" />
<constructor-arg index="1" value="${userSearch.searchFilter}" />
<constructor-arg index="2">
<ref local="contextSource" />
</constructor-arg>
  <property name="searchSubtree" value="true" />
</bean>

Group names in the security configuration

Depending on your Active Directory configuration, you also need to change the group names of authorized users in pentaho-solutions/system/pentaho.xml and pentaho-solutions/system/applicationContext-spring-security.xml.

References

SEC-130: Support for Active Directory logins

How to login with a Windows Domain account

Javadoc for javax.naming.Context

Installing Pentaho BI Suite 3.6GA with Active Directory as LDAP

Browser not supported