Announcement Announcement Module
Collapse
No announcement yet.
LDAP - url with space problem Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Luke Taylor View Post
    You shouldn't really be using 3.0.3 since it is vulnerable to this issue.

    Without some more information on what your "login error" is (the exception and debug log) then there's not much anyone will be able to do to help.
    thank you sir. i'll try to migrate to 3.0.5 and hopefully, there is no drastic change with regards to the API and its paths.

    Comment


    • #17
      Hello again Sir. i was able to migrate successfully from 3.0.3 to 3.0.5. but then again, authentication is not successful.

      Code:
      <constructor-arg value="ldap://TEST-CORP.company.biz:389/OU=Company Users,OU=US-users,DC=Test-corp,DC=company,DC=biz" />
      i got an exception:
      nested exception is java.lang.IllegalArgumentException: Root DNs must be the same when using multiple URLs

      These are the logs:

      INFO org.springframework.security.ldap.DefaultSpringSec urityContextSource:main
      04/04/11 23:03:23 - URL 'ldap://TEST-CORP.company.biz:389/OU=Company%20Users,OU=US-users,DC=Test-corp,DC=company,DC=biz'

      DEBUG org.springframework.ldap.core.support.AbstractCont extSource:main
      04/04/11 23:03:23 - Trying provider Urls: ldap://TEST-CORP.company.biz:389/ou=Company%2520Users,ou=US-Users,OU=US-users,DC=Test-corp,DC=company,DC=biz

      INFO org.springframework.security.ldap.search.FilterBas edLdapUserSearch:main
      04/04/11 23:03:23 - SearchBase not set. Searches will be performed from the root: ou=Company%20Users,ou=US-Users,DC=Test-corp,DC=company,DC=biz

      INFO org.springframework.security.ldap.DefaultSpringSec urityContextSource:main
      04/04/11 23:03:23 - URL 'ldap://TEST-CORP.company.biz:389/OU=Company', root DN is 'OU=Company'

      INFO org.springframework.security.ldap.DefaultSpringSec urityContextSource:main
      04/04/11 23:03:23 - URL 'Users,OU=US-users,DC=Test-corp,DC=company,DC=biz', root DN is 'Users,OU=US-users,DC=Test-corp,DC=company,DC=biz'


      the space is being treated as delimiter for multiple URLS thus an exception occurs and the server did not start correctly
      Exception encountered:

      Constructor threw exception; nested exception is java.lang.IllegalArgumentException: Root DNs must be the same when using multiple URLs


      I used the %20 in replace of the space
      Code:
      <constructor-arg value="ldap://TEST-CORP.company.biz:389/OU=Company%20
      Users,OU=US-users,DC=Test-corp,DC=company,DC=biz" />
      And i got these logs:
      DEBUG com.filter.CustomUsernamePasswordAuthenticationFil ter:26243678@qtp-27227813-1 04/04/11 23:55:41 - Authentication request failed: org.springframework.security.authentication.Authen ticationServiceException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece

      DEBUG com.filter.CustomUsernamePasswordAuthenticationFil ter:26243678@qtp-27227813-1 04/04/11 23:55:41 - Updated SecurityContextHolder to contain null Authentication

      DEBUG com.filter.CustomUsernamePasswordAuthenticationFil ter:26243678@qtp-27227813-1 04/04/11 23:55:41 - Delegating to authentication failure handlerorg.springframework.security.web.authentica tion.SimpleUrlAuthenticationFailureHandler@5ddffa


      -Error code 49 is the equivalent of bad credentials at login

      Hope this would explain further. thank you so much.

      Comment


      • #18
        If you use a space, that is not a valid LDAP URL. This should be clear from the original thread. You need to add the %20 encoding.

        525 is an Active directory "user not found" error. Please follow my advice to the OP and make sure you can write a working test in plain Java before trying a full Spring Security setup.

        Comment


        • #19
          pardon my persistency, but i really need someone who can help me on this issue.

          i was able to test my ldap connection through jndi with the space being replace with %20. it works properly and i was able to connect to my ldap server.

          here's my test class code
          Code:
          		Hashtable env = new Hashtable();
          		env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
          		env.put(Context.PROVIDER_URL, "ldap://TEST-CORP.company.biz:389/OU=Company%20Users,OU=US-Users,DC=Test-corp,DC=company,DC=biz");
          		env.put(Context.SECURITY_AUTHENTICATION, "simple");
          		env.put(Context.SECURITY_PRINCIPAL, "[email protected]");
          		env.put(Context.SECURITY_CREDENTIALS, "password321");
          i was able to retrieve the values such as the CN and some other attributes.
          but upon integrating it to spring security, i was not able to authenticate the user.

          these are my logs

          DEBUG org.springframework.ldap.core.support.AbstractCont extSource:4497427@qtp-32002750-0
          04/26/11 14:10:13 - Got Ldap context on server 'ldap://TEST-CORP.company.biz:389/ou=Company%2520Users,ou=US-Users,dc=Test-corp,dc=company,dc=biz'

          DEBUG com.company.filter.CustomeUsernamePasswordAuthenti cationFilter:4497427@qtp-32002750-0
          04/26/11 14:10:13 - Authentication request failed: org.springframework.security.authentication.Authen ticationServiceException: [LDAP: error code 32 - 0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of:
          'OU=US-users,DC=Test-corp,DC=company,DC=biz'

          ; nested exception is javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of:
          'OU=US-users,DC=Test-corp,DC=company,DC=biz'


          it seems like the OU with %20 is lost somewhere.

          my code is as follows
          Code:
          <bean id="LDAPConnection"		class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
          		<constructor-arg value="ldap://TEST-CORP.company.biz:389/OU=Company%20Users,OU=US-Users,DC=Test-corp,DC=company,DC=biz" />
          		<property name="userDn" value="[email protected]" />
          		<property name="password" value="password321" />
          	</bean>
          i would really really love any enlightenment on this issue.. thank you in advance.

          Comment


          • #20
            I'd suggest performing another unit test using just Spring LDAP. I suspect that the issue actually lies there rather than with Spring Security. If nothing else it will help narrow down where to look.

            Comment


            • #21
              finally, i was able to solve this problem. it seems like there is space double conversion. the %20 is again converted to %2520. %25 is the ascii value of the %. i used the org.springframework.ldap.core.support.LdapContextS ource instead of org.springframework.security.ldap.DefaultSpringSec urityContextSource, and the double conversion problem is eliminated. essentially, the manager is already authenticated.

              but upon authenticating the logged-in user, a Naming Exception occurs thus returning a Bad Credentials exception. i've checked the BindAuthenticator and NamingException occurs on this part:
              Code:
              ctx = contextSource.getContext(fullDn.toString(), password);
              this is due to the fact that fullDn is not yet the full DN. it only contains the userDN since
              Code:
              ctxSource.getBaseLdapPath()
              returns a null value. thereby, passing a Bad Credentials Exception.
              what i did was to add and set a baseDN property. and retrieve it in the customized BindAuthenticator class. then, i prepend the baseDN value to the fullDN and this solves the problem.

              feel free to message me if you have further questions. thanks.

              Comment


              • #22
                Is this fixed in 3.1?

                This is still an issue in 3.0.5. The constructor of DefaultSpringSecurityContextSource parses the URL, but it doesn't remove the URL encoding from the DN when it sets the Base DN.

                An easy fix is to call #setBase again after constructing the DefaultSpringSecurityContextSource instance, but it's admittedly a hack. Really the static LdapUtils.parseRootDnFromUrl(url) call should be doing the proper unescaping (turning %20 into a single whitespace, for example).

                Comment


                • #23
                  Originally posted by dhalbrook View Post
                  This is still an issue in 3.0.5. The constructor of DefaultSpringSecurityContextSource parses the URL, but it doesn't remove the URL encoding from the DN when it sets the Base DN.

                  An easy fix is to call #setBase again after constructing the DefaultSpringSecurityContextSource instance, but it's admittedly a hack. Really the static LdapUtils.parseRootDnFromUrl(url) call should be doing the proper unescaping (turning %20 into a single whitespace, for example).
                  i think you're right, dhalbrrok. i can see the log from spring ldap:
                  INFO [org.springframework.security.ldap.DefaultSpringSec urityContextSource] - URL 'ldap://myhost:389/dc=my%20services,dc=company,dc=net', root DN is 'dc=my%20services,dc=company,dc=net'

                  so the correct root DN should be "dc=my services,dc=company,dc=net".

                  Comment


                  • #24
                    hi, Luke. can you fix this? otherwise, i have to re-set the base in configuration file.


                    Code:
                    <beans:bean id="contextSource"
                    		class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
                    		<beans:constructor-arg value="ldap://myhost:389/dc=my%20services,dc=company,dc=net" />
                    		<beans:property name="base" value="dc=my services,dc=company,dc=net" />
                    </beans:bean>
                    Last edited by hauer; Mar 22nd, 2013, 05:20 AM.

                    Comment

                    Working...
                    X