Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 Acegi Security DefaultInitialDirContextFactory bean.

Kerberos notation

<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

<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 (e.g. BindAuthenticator) provided by Acegi Security, 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.)

However, Pentaho's

User DN Patterns

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 specify 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

  • No labels