Skip to main content
Pentaho Documentation

Manual MSAD Configuration

Before making any edits to your Pentaho security configuration, you must manually switch from Pentaho default security to LDAP security. The LDAP Properties reference article contains supplemental information for LDAP values.

Switching to LDAP Security

  1. Stop the DI Server.
  2. Change the file located in /pentaho-solutions/system  folder from provider=jackrabbit to provider=ldap
  3. Save and close the file.
  4. Restart the DI Server. 

Making MSAD Configuration File Changes 

To make Microsoft Active Directory (MSAD) configuration file changes, you need to edit this file:  


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 MSAD than for more traditional LDAP implementations.


MSAD allows you to uniquely specify users in two ways (Kerberos notion or Windows domain notion), in addition to the standard DN. If the standard DN is not working, try one of the following two methods. Each of the following examples is shown in the context of the userDn property of the Spring Security DefaultSpringSecurityContextSource bean.

The examples in this section use DefaultSpringSecurityContextSource. You may need to use the same notation (Kerberos or Windows domain) in all of your DN patterns.

The following code block is an example of the Kerberos notation for



The following code block is an example of the Windows domain notation for MYCOMPANY\pentahoadmin:




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

<bean id="contextSource" class="">
    <constructor-arg value="${contextSource.providerUrl}"/>
    <property name="userDn" value="${contextSource.userDn}"/>
    <property name="password" value="${contextSource.password}"/>
    <property name="referral" value="follow" />

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 are using the Kerberos or Windows domain notation, you should use userDnPatterns exclusively in your LdapAuthenticator.

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.

However, the LdapUserDetailsService requires an LdapUserSearch for its constructor.

The following code block is an example of the User DN Pattern:

<bean id="authenticator"
    <ref local="contextSource"/> 
    </value> <!-- and/or --> 

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

The following code block is an example of the User Search:

<bean id="userSearch"
    <constructor-arg index="0" value="DC=mycompany,DC=com" />
    <constructor-arg index="1">    
    </constructor-arg> <constructor-arg index="2">
    <ref local="contextSource" />
    <property name="searchSubtree" value="true"/> 

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:


This will search down the whole tree of nested groups.