Results 1 to 4 of 4

Thread: Nightly build problem: DefaultLdapAuthoritiesPopulator

  1. #1
    Join Date
    Dec 2005
    Location
    San Francisco
    Posts
    13

    Default 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. #2
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

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

  3. #3
    Join Date
    Dec 2005
    Location
    San Francisco
    Posts
    13

    Default

    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

  4. #4
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •