Page Comparison

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

Note: The examples in this Binding section use DefaultInitialDirContextFactoryshow 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

<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory"> <constructor-arg value="ldap

Code Block

xml

none
	none
title	applicationContext-security-ldap.properties


# backslash before colon to escape it
contextSource.providerUrl=ldap\://mycompany\:389" />
  <property name="managerDn" value="
contextSource.userDn=pentahoadmin@mycompany.com" />
  <property name="managerPassword" value="omitted" />
</bean>
contextSource.password=secret

Windows domain notation

Example: MYCOMPANY\pentahoadmin

<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory"> <constructor-arg value="ldap

Code Block

	none	xml	xml

	none
title	applicationContext-security-ldap.properties


# backslash before colon to escape it
contextSource.providerUrl=ldap\://mycompany\:389"
# />backslash before backslash <property name="managerDn" value="MYCOMPANY\pentahoadmin" />
  <property name="managerPassword" value="omitted" />
</bean>
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 DefaultInitialDirContextFactory 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.

Code Block

	xml
	xml

<bean id="initialDirContextFactorycontextSource" class="org.springframework.acegisecuritysecurity.ldap.DefaultInitialDirContextFactoryDefaultSpringSecurityContextSource">
  <constructor-arg value="ldap://mycompany:389" ${contextSource.providerUrl}"/>
  <property name="managerDnuserDn" value="MYCOMPANY\pentahoadmin" ${contextSource.userDn}"/>
  <property name="managerPasswordpassword" value="omitted" ${contextSource.password}"/>
  <property name="extraEnvVarsbaseEnvironmentProperties">
    <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 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.)

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

User DN Patterns

Code Block

	xml
	xml

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

Code Block

	none
	none
title	applicationContext-security-ldap.properties


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

Code Block

	xml
	xml
title	applicationContext-spring-security-ldap.xml

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