Announcement Announcement Module
No announcement yet.
UnsupportedOperationException when authenticating a user with LDAP Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • UnsupportedOperationException when authenticating a user with LDAP

    I'm having problems with the user authentication using ldap.

    As far as I can tell the admin bind works fine.
    However when I try to verify a normal username/password, I get an UnsupportedOperationException in the SimpleNamingContext.

    AFAIK the ldap server is an Active Directory server.

    My test code:

    ServiceLocator serviceLocator = new ServiceLocatorBean(MockApplicationContext.getMockA pplicationContext());
    UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(username, password);
    AuthenticationProvider authenticationProvider = (AuthenticationProvider) serviceLocator.getAppContext().getBean("ldapAuthen ticationProvider");
    authenticationProvider.authenticate(authentication Token);

    I've attached the relevant piece of application context and the stacktrace, as they contain 'too many images' to post directly :-)

    I have tried replacing the ',' with ';', putting '\\' in front of the ',' and using a PasswordComparisonAuthenticator instead of the BindAuthenticator.
    All of them leading to weird and wonderful new errors.

    Could anyone help me in the right direction?

    Paul Siegmann

  • #2
    The info you've posted seems a bit confused. You're running something called FilterBasedLdapUserSearchTest, but the search object in your app context isn't actually referenced by any other beans.

    There also appears to be a space after the "ldap:" in your URL which doesn't look very healthy.

    I have tried replacing the ',' with ';', putting '\\' in front of the ','
    I don't know what you mean here. Everything should be proper DN syntax, apart from the substituted parameters, like "{0}".


    • #3
      Thanks for taking a look.

      You're right, the search object is not used in this particular test.
      It's used in a different test to retreive the user's data.
      And it works fine, from which I conclude that the admin login works fine as well.

      I've put the space after the ldap: because the tool to post messages to this forum complained that there were too many images in the post.
      The space is not in the actual applicationContext.xml.

      The biggest problem I have with this situation is that I don't get a normal error like 'host not found', or 'invalid credentials', but I get this:

      "problems during authentication test:null
      at org.springframework.mock.jndi.SimpleNamingContext. getNameInNamespace()Ljava.lang.String;(SimpleNamin"

      I expect to get an LdapInitialNamingContext.
      How did this SimpleNamingContext get there?

      Paul Siegmann


      • #4
        Hmm. I hadn't noticed there was a Spring class there... are you loading other objects in the same context which could be making use of Spring's mock JNDI provider? You could then end up with Spring acting as the default InitialContext provider and it looks like SimpleNamingContext isn't up to the job.

        Try running with only the LDAP config in the context.


        • #5
          I've got a working setup now. It will never win a beauty contest, but at least it does what it's supposed to do.

          The solution consists of two parts.
          The first part is that I was testing the login procedure using a junit test.
          The junit test uses the SimpleNamingContextBuilder.
          Somehow this causes the call to getInitialDirContextFactory() in the BindAuthenticator.bindWithDn method to create a org.springframework.mock.jndi.SimpleNamingContext instead of a com.sun.jndi.ldap.LdapCtx.
          This despite passing an environment Map with the "java.naming.factory.initial" value set to "com.sun.jndi.ldap.LdapCtxFactory".

          Should I file a bug report for this?

          The second part involves subclassing the DefaultLdapAuthoritiesPopulator in ways that clearly show either mine or the ldap server administrators lack of understanding of LDAP.