Configure Microsoft Active Directory for the DI Server
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.
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
(member:1.2.840.113556.1.4.1941:={0})This will search down the whole tree of nested groups.