Announcement Announcement Module
Collapse
No announcement yet.
Nightly build problem: DefaultLdapAuthoritiesPopulator Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Nightly build problem: DefaultLdapAuthoritiesPopulator

    I am testing out the LDAP authentication upgrade from 1.0.0-RC2 to the last full nightly build (May 22). Under 1.0.0-RC2, if there were no groups for the user, the authenication failed gracefully and returned user not authenticated, but with the nightly build, I get the following stack trace:

    Code:
    06:51:34,441 DEBUG DefaultLdapAuthoritiesPopulator,http-8080-Processor25:220 - S
    earching for roles for user 'admin', DN = 'uid=admin,dc=panscopic,dc=com', with
    filter (|(objectclass=groupofURLs)(objectclass=groupofuniquenames)) in search ba
    se 'dc=panscopic,dc=com'
    06:51:34,566 ERROR [default],http-8080-Processor25:260 - Servlet.service() for s
    ervlet default threw exception
    org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP: error code 3
    2 - No Such Object]; nested exception is javax.naming.NameNotFoundException: [LD
    AP: error code 32 - No Such Object]; remaining name 'dc=panscopic,dc=com'
    Caused by:
    javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; rema
    ining name 'dc=panscopic,dc=com'
            at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3010)
            at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
            at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
            at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1808)
            at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1731)
            at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1748)
            at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirCon
    text.java:394)
            at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCom
    positeDirContext.java:376)
            at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCom
    positeDirContext.java:358)
            at javax.naming.directory.InitialDirContext.search(InitialDirContext.jav
    a:267)
            at org.acegisecurity.ldap.LdapTemplate$1SingleAttributeSearchCallback.do
    InDirContext(LdapTemplate.java:169)
            at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:98)
            at org.acegisecurity.ldap.LdapTemplate.searchForSingleAttributeValues(Ld
    apTemplate.java:196)
            at org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopu
    lator.getGroupMembershipRoles(DefaultLdapAuthoritiesPopulator.java:226)
            at org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopu
    lator.getGrantedAuthorities(DefaultLdapAuthoritiesPopulator.java:178)
            at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.createUse
    rDetails(LdapAuthenticationProvider.java:190)
            at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveU
    ser(LdapAuthenticationProvider.java:162)

    Thanks,


    Sherman
    JasperSoft

  • #2
    It looks to me like you are configuring your group search under an invalid name. The search base should be relative to the root DN. So if your context factory is using "ldap://monkeymachine:389/dc=acegisecurity,dc=org" as the provider Url, and you want to search from the root, then your search base should be "", not "dc=acegisecurity,dc=org". It's hard to be sure without more information though...

    Comment


    • #3
      I know I have a problem in actually getting the groups which I have to fix.

      The issue I have is that under RC2, I was not getting a full exception thrown. The group search failed to find anything with a No such object, the exception was caught somewhere and so the authentication failed gracefully. Under the nightly build I was using, instead we have an uncaught Exception thrown that, in my case, came all the way back to the screen (which I will have to fix anyway). I prefer the RC2 behavior of the group search failing gracefully.


      Thanks,

      Sherman

      Comment


      • #4
        If the search is failing because of a configuration error (such as a non-existent search base name, which seems to be the problem here), then "failing gracefully" doesn't really make much sense. If that was the bahaviour in RC2 then I would say it was a bug as a config error should always be a fail-fast situation.

        Comment

        Working...
        X