Configure Microsoft Active Directory for the DI Server
Overview
Explains how to configure MSAD for the DI Server.
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
- Stop the DI Server.
- Change the securities.properties file located in /pentaho-solutions/system folder from provider=jackrabbit to provider=ldap
- Save and close the file.
- Restart the DI Server.
Making MSAD Configuration File Changes
To make Microsoft Active Directory (MSAD) configuration file changes, you need to edit this file:
applicationContext-pentaho-security-ldap.xml
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.
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.
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, 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.