Skip to main content
Version Pentaho
Hitachi Vantara Lumada and Pentaho Documentation

Configure Microsoft Active Directory for the DI Server

  1. Last updated
  2. Save as PDF

Overview

Explains how to configure MSAD for the DI Server.

The server does not recognize any difference among LDAP-based directory servers, including Active Directory. However, the way that you modify certain LDAP-specific files will probably be different for Microsoft Active Directory (MSAD) than for more traditional LDAP implementations. Below are some tips for specific MSAD-specific configurations that you might find helpful. The file you need to edit is applicationContext-pentaho-security-ldap.xml.

Binding

MSAD allows you to uniquely specify users in two ways, in addition to the standard DN. If the standard DN is not working, try one of the two below. Each of the following examples is shown in the context of the userDn property of the Spring Security DefaultSpringSecurityContextSource bean.

Note: The examples in this section use DefaultSpringSecurityContextSource. Be aware that you may need to use the same notation (Kerberos or Windows domain) in all of your DN patterns.

Kerberos notation example for pentahoadmin@mycompany.com:

File: applicationContext-security-ldap.properties

contextSource.providerUrl=ldap\://mycompany\:389
contextSource.userDn=pentahoadmin@mycompany.com
contextSource.password=omitted

Windows domain notation example for MYCOMPANY\pentahoadmin:

File: applicationContext-security-ldap.properties

contextSource.providerUrl=ldap\://mycompany\:389
contextSource.userDn=MYCOMPANY\pentahoadmin
contextSource.password=omitted

Referrals

If more than one Active Directory instance is serving directory information, it may be necessary to enable referral following. This is accomplished by modifying the DefaultSpringSecurityContextSource bean.

<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="referral" value="follow" />
</bean>

User DN Patterns vs. User Searches

In the LdapAuthenticator implementations provided by Spring Security (BindAuthenticator for instance), 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 for suggesting userDnPatterns 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 might not work in Active Directory.)

Note, however, that LdapUserDetailsService requires an LdapUserSearch for its constructor.

User DN Pattern example:

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

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

User Search example:

<bean id="userSearch"
class="org.springframework.security.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="contextSource" />
    </constructor-arg> 
    <property name="searchSubtree" value="true"/> 
</bean>

Nested Groups

You can remove nested or transitive groups out of Active Directory. In the LDAP popular group filter, enter the following LDAP filter for MSAD nested groups: 
(member:1.2.840.113556.1.4.1941:={0})
This will search down the whole tree of nested groups.