Announcement Announcement Module
Collapse
No announcement yet.
Active Directory authentication in Spring 3.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Active Directory authentication in Spring 3.1

    I'm fairly new to Spring and setting up active directory authentication as described here in section 19.5.
    http://static.springsource.org/sprin...ngle.html#ldap

    I have the authentication provider and associated bean set up in the security file:

    <authentication-manager alias="authenticationManager">
    <authentication-provider ref="adAuthenticationProvider"/>
    </authentication-manager>
    ...
    <beans:bean id="adAuthenticationProvider" class="org.springframework.security.ldap.authentic ation.ad.ActiveDirectoryLdapAuthenticationProvider ">
    <beans:constructor-arg value="my.domain" />
    <beans:constructor-arg value="ldap://my.ldap.server/" />
    <!-- Convert AD errors. -->
    <beansroperty name="convertSubErrorCodesToExceptions" value="true" />
    </beans:bean>

    When supplying an invalid password I see the following error, which looks correct:
    org.springframework.security.ldap.authentication.a d.ActiveDirectoryLdapAuthenticationProvider handleBindException
    INFO: Active Directory authentication failed: Supplied password was invalid

    Every time a valid user/password is provided I get this exception:
    org.springframework.security.ldap.SpringSecurityLd apTemplate searchForSingleEntryInternal
    INFO: Ignoring PartialResultException

    I've tried adding the base to the LDAP URL like this:
    <beans:constructor-arg value="ldap://my.ldap.server/dc=comp1,dc=comp1" />

    This gives a different error:
    org.springframework.security.ldap.authentication.a d.ActiveDirectoryLdapAuthenticationProvider doAuthentication
    SEVERE: Failed to locate directory entry for authenticated user: user1
    javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0, best match of:
    'DC=comp1,DC=comp2'
    ]; remaining name 'dc=comp1,dc=comp2'
    at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
    ...

    How do I get past this error? There seems to be very little documentation out there for AD and Spring 3.1 security.

  • #2
    Working with our Active Directory expert we've determined the source of the problem but still have no solution.

    The authentication is successful but there is a problem binding to the object. This throws the PartialResultException. As a test we moved one AD user to the root and the authentication worked (PartialResultException was thrown on successful login). It is quite uncommon to have all user nodes at the root level so this is not a feasible workaround. This problem was alleviated in prior security implementations by setting the "referral" property to "follow" but this property is not available in the ActiveDirectoryLdapAuthenticationProvider class. Why?!

    The question remains - how do I implement active directory authentication with Spring Security 3.1? I read something about creating a custom login filter. Is that the only way to get past this problem?

    Comment


    • #3
      We've pinpointed the source of the problem and it appears to be a bug in Spring. It was not a matter of the AD user being located in the root as originally suspected. It is a problem with how Spring searches AD.

      The problem is that the account name (sAMAccountName) is being used for authentication but the 1st part of the user name (userPrincipalName) is being used for the search. That causes the PartialResultException. Once each user was updated by putting the sAMAccountName in to the 1st part of the userPrincipalName then the authentication worked.

      How/where can a bug be filed to get this fixed?

      Comment


      • #4
        We've encountered the same problem. Any update on the resolution?

        Comment


        • #5
          I asume this is still a bug in Spring. I filed a bug report but heard nothing of it. The only workaround was to do what was stated in my last post - the sAMAccountName was loaded in to the 1st part of the userPrincipalName so that the authentication mand AD search use the same info.

          Comment

          Working...
          X