Copy of Using Active Directory 2.x-3.0.x

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 managerDn property of the Acegi Security DefaultInitialDirContextFactory bean.

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

Kerberos notation

Example: pentahoadmin@mycompany.com

<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
  <constructor-arg value="ldap://mycompany:389" />
  <property name="managerDn" value="pentahoadmin@mycompany.com" />
  <property name="managerPassword" value="omitted" />
</bean>

Windows domain notation

Example: MYCOMPANY\pentahoadmin

<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
  <constructor-arg value="ldap://mycompany:389" />
  <property name="managerDn" value="MYCOMPANY\pentahoadmin" />
  <property name="managerPassword" value="omitted" />
</bean>

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 DefaultInitialDirContextFactory 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="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
  <constructor-arg value="ldap://mycompany:389" />
  <property name="managerDn" value="MYCOMPANY\pentahoadmin" />
  <property name="managerPassword" value="omitted" />
  <property name="extraEnvVars">
    <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 Acegi 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.)

Note however that Pentaho's LdapUserDetailsService requires an LdapUserSearch for its userSearch property.

User DN Patterns

<bean id="authenticator" class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
  <constructor-arg>
    <ref local="initialDirContextFactory" />
  </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.

<bean id="userSearch" class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
  <constructor-arg index="0" value="DC=mycompany,DC=com" />
  <constructor-arg index="1">
    <value>(sAMAccountName={0})</value>
  </constructor-arg>
  <constructor-arg index="2">
    <ref local="initialDirContextFactory" />
  </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-acegi-security.xml.

References

SEC-130: Support for Active Directory logins
How to login with a Windows Domain account
Javadoc for javax.naming.Context