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
property of the Acegi Security DefaultInitialDirContextFactory
bean.
Kerberos notation
Example: pentahoadmin@mycompany.com
<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory"> <constructor-arg value="ldap://mycompany:389" /> <property name="managerDn" value="pentahoadmin@mycompany.com" /> <property name="managerPassword" value="omitted" /> </bean>
Windows domain notation
Example: MYCOMPANY\pentahoadmin
<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory"> <constructor-arg value="ldap://mycompany:389" /> <property name="managerDn" value="MYCOMPANY\pentahoadmin" /> <property name="managerPassword" value="omitted" /> </bean>
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
bean. Basically you create a map (via the <map>
element) and set that as the extraEnvVars
property value. The map has a single key-value pair. The key part of the key-value pair below matches the REFERRAL
constant defined in the Context class. The value part in the key-value pair is one of the following: follow
, ignore
, or throw
. (These values are also defined in the javadoc for the REFERRAL constant.
<bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory"> <constructor-arg value="ldap://mycompany:389" /> <property name="managerDn" value="MYCOMPANY\pentahoadmin" /> <property name="managerPassword" value="omitted" /> <property name="extraEnvVars"> <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 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
.
Technical Information
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
<bean id="authenticator" class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator"> <constructor-arg> <ref local="initialDirContextFactory" /> </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.
<bean id="userSearch" class="org.acegisecurity.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="initialDirContextFactory" /> </constructor-arg> <property name="searchSubtree" value="true" /> </bean>
References
SEC-130: Support for Active Directory logins
How to login with a Windows Domain account
Javadoc for javax.naming.Context