5 Replies Latest reply on Nov 24, 2010 12:00 PM by shenz

    Problems with LdapExtLoginModule

    shenz

      Hi dear all,

       

      I've a problem with the LdapExtLoginModule when trying to connect to a Jboss security domain. Hopefully somebody can help me out.

       

      Here is the problem:

      The "dn" for every user is given by

       

      uid=<userName>,ou=<department>,ou=users,dc=company,dc=de

       

      I defined the security domain "jbossmq" and created the following entry in the login-config.xml:

       

      <application-policy name="jbossmq">

             <authentication>

                  <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">

                  <module-option name="debug">true</module-option>

                  <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>

                  <module-option name="java.naming.provider.url">ldap://<ldapServer>:636/</module-option>

                  <module-option name="java.naming.security.protocol">ssl</module-option>

                  <module-option name="java.naming.security.authentication">simple</module-option>

                  <module-option name="bindDN">uid=queryAccount,ou=<department>,ou=users,dc=company,dc=de</module-option>

                  <module-option name="bindCredential"><password></module-option>

                  <module-option name="baseCtxDN">ou=users,dc=company,dc=de</module-option>

                  <module-option name="baseFilter">(uid={0})</module-option>

                  <module-option name="searchTimeLimit">5000</module-option>

                  <module-option name="searchScope">SUBTREE_SCOPE</module-option>

                  <module-option name="allowEmptyPasswords">false</module-option>

               </login-module>

            </authentication>

         </application-policy>

       

      Here the <password> for the user "queryAccount" who can perform a ldapsearch is given in an not encrypted manner.

      And <department> can be different depending to which department the user with <username>, who wants to login, belongs to.

      But when deploying the according EJB application, typing in the "username" of the user and the according "password", I always get an error message like

       

      21:38:45,146 TRACE [LdapExtLoginModule] initialize
      21:38:45,146 TRACE [LdapExtLoginModule] Security domain: jbossmq
      21:38:45,146 TRACE [LdapExtLoginModule] login
      21:38:45,324 DEBUG [LdapExtLoginModule] Bad password for username=<username>

       

      Instead when I'm using the LdapLoginModule (as given below) with a fixed <department>, I can login in. But, as I mentioned above, the <department> is not the same for every username and therefore the LdapLoginModule can't be used in the productive system.

      The according LapLoginModule entry for the "jbossmq" security domain for which a login for a fixed <department> is possible, if the user belongs to this department, looks like

       

      <application-policy name="jbossmq">
             <authentication>
                  <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required">
                  <module-option name="debug">true</module-option>
                  <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
                  <module-option name="java.naming.provider.url"><ldapServer>:636/</module-option> -->
                  <module-option name="java.naming.security.protocol">ssl</module-option>
                  <module-option name="java.naming.security.authentication">simple</module-option>
                  <module-option name="principalDNPrefix">uid=</module-option>
                  <module-option name="principalDNSuffix">,ou=<department>,ou=users,dc=company,dc=de</module-option>
                  <module-option name="searchTimeLimit">5000</module-option>
                  <module-option name="searchScope">SUBTREE_SCOPE</module-option>
                  <module-option name="allowEmptyPasswords">false</module-option>
               </login-module>
            </authentication>
         </application-policy>

       

      Does anybody has a glue what is wrong with the entry in the LdapExtLoingModule and can help me?

       

      Thanks in advance,

      Stefan

        • 1. Re: Problems with LdapExtLoginModule
          peterj

          See if this discussion helps: http://community.jboss.org/message/564569

          • 2. Re: Problems with LdapExtLoginModule
            shenz

            Hi Peter,

             

            thanks for the link.  I read the whole discussion, unfortunately it didn't help so far. We are using an Openldap server. Because the "dn" of each user looks like

            uid=<userName>,ou=<department>,ou=users,dc=company,dc=de

             

            I'm expecting for "baseCtxDN" and for "baseFilter" the entries

             

            <module-option name="baseCtxDN">ou=users,dc=company,dc=de</module-option>

            and

            <module-option name="baseFilter">(uid={0})</module-option>

             

            are correct. But unfortunately the authentifiation does not work with the LdapExtLoginModule. I can't say what's going, i.e. if the ldapsearch does not work because of a wrong filter or if I can't connect to the Openldap server.

            At least the connection to the Openldap server works with the LdapLoginModule. So I'm expecting the ldapsearch does not work. I just wonder, if the password of the "bindDN" are allowed to be in clear text, i.e. not encrypted and if the authentication "simple" is correct. I've at least the following

             

            <module-option name="java.naming.provider.url"><ldapServer>:636/</module-option>
            <module-option name="java.naming.security.protocol">ssl</module-option>
            <module-option name="java.naming.security.authentication">simple</module-option>

            and

            <module-option name="bindDN">uid=queryAccount,ou=<department>,ou=users,dc=company,dc=de</module-option>

            <module-option name="bindCredential"><password></module-option>

             

            But still the authentication with the LdapExtLoginModule does not work. I've to use this module because the department which is part of each users "dn" may differ.

             

            Best wishes,

            Stefan

            • 3. Re: Problems with LdapExtLoginModule
              shenz

              Hi Peter,

               

              once again thanks for your answering, but it didn't unfortunately not help.

              Checking the ldapsearch via normal Java (filter uid=username) and specifying the same searchBase = "ou=users,dc=company,dc=de" and all the other stuff as given in my login-config.xml (SECURITY_PROTOCOL, "ssl" etc), I can say an ldapsearch is working Java. So it has to be a Jboss configuration problem. Maybe the login-config.xml by its own or some other configuration adaption is missing. But as mentioned alreay the authentification via the LdapLoginModule is working.

               

              Working now for some months with Jboss I'm really disappointed how bad sometimes the stuff is documented. The problems could be easier solved when being better documented.

               

              Best wishes,

              Stefan

              • 4. Re: Problems with LdapExtLoginModule
                peterj

                Have you set logging for "org.jboss.security.auth" to TRACE level? That might reveal more info about what the LDAP login module is doing and what results it is getting. That might help you resolve the issue. Other than that, debugging the LDAP login module is probably your best bet.

                 

                I have often found open source software to be poorly documented. It seems that many open source developers think that all you need to do is read the code to find out how it works. And of course the source code is rarely contains any comments because "well written code is self-documenting."

                • 5. Re: Problems with LdapExtLoginModule
                  shenz

                  Hi Peter

                   

                  yes I've set the logging for "org.jboss.security.auth" now also, and get the same information which I've already gotten in advance when setting the log ALL security output to a new console appender as given on the website http://www.techienuggets.com/Comments?tx=69337 at the bottom.

                   

                  The trace output I'll give at the end of this post. It seems that either Jboss can't perform a ldapserach (whereas this is possible with Java code) or Jboss can't retrieve the correct password from the ldap server.

                  In order to be sure that also the configured certificates are read, I first switched on the handshaking debugging by

                  adding

                  JAVA_OPTS="$JAVA_OPTS -Djavax.net.debug=ssl,handshake"

                  in run.conf

                  And second, explicitly determined the location of truststore which in my case is /etc/java-6-sun/security/cacerts because I added the generated ssl certificate with keytool to this file, by adding also the line

                  JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/etc/java-6-sun/security/cacerts"

                  in the file run.conf

                   

                  Because I've not change the default trustStorePassword, I've not added the line

                  JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStorePassword=changeit

                   

                  But, if I did, it didn't change the behaviour of not working, i.e. the authentifcation via LdapExtloginModule does not work.

                   

                  The ssl handshaking at least with the LdapLoginModule seems to work, because  in the later case the authentification via ldap works.

                  I'm not sure, if the problem with the LdapExtLoginModule might be a bug in the used Jboss version, which is jboss-5.1.0.GA/

                   

                  And below now follows the TRACE of org.jboss.security.auth". But I can't see any real hint, besides it says bad password for <username>:

                   

                  2010-11-24 16:33:44,527 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8080-1) Setting threadlocal:{}
                  2010-11-24 16:33:44,529 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8080-1) Setting threadlocal:null
                  2010-11-24 16:33:44,529 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8080-1) Setting threadlocal:null
                  2010-11-24 16:33:44,594 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:{}
                  2010-11-24 16:33:44,622 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationContext] (http-0.0.0.0-8443-1) Control flag for entry:org.jboss.security.authorization.config.AuthorizationModuleEntry{org.jboss.security.authorization.modules.DelegatingAuthorizationModule:{}REQUIRED}is:[REQUIRED]
                  2010-11-24 16:33:44,708 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:null
                  2010-11-24 16:33:44,708 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:null
                  2010-11-24 16:33:55,959 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:{}
                  2010-11-24 16:33:55,970 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.jbossmq] (http-0.0.0.0-8443-1) Begin isValid, principal:shenz, cache info: null
                  2010-11-24 16:33:55,972 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.jbossmq] (http-0.0.0.0-8443-1) defaultLogin, principal=shenz
                  2010-11-24 16:33:55,976 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (http-0.0.0.0-8443-1) Begin getAppConfigurationEntry(jbossmq), size=12
                  2010-11-24 16:33:55,984 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (http-0.0.0.0-8443-1) End getAppConfigurationEntry(jbossmq), authInfo=AppConfigurationEntry[]:
                  [0]
                  LoginModule Class: org.jboss.security.auth.spi.LdapExtLoginModule
                  ControlFlag: LoginModuleControlFlag: required
                  Options:
                  name=baseFilter, value=(uid={0})
                  name=java.naming.security.authentication, value=simple
                  name=java.naming.factory.initial, value=com.sun.jndi.ldap.LdapCtxFactory
                  name=allowEmptyPasswords, value=false
                  name=bindCredential, value=****
                  name=bindDN, value=uid=uid=queryAccount,ou=<department>,ou=users,dc=company,dc=de
                  name=java.naming.provider.url, value=ldap://<ldapServer>:636/
                  name=searchTimeLimit, value=5000
                  name=java.naming.security.protocol, value=ssl
                  name=baseCtxDN, value=ou=users,dc=company,dc=de
                  name=debug, value=true
                  name=searchScope, value=SUBTREE_SCOPE

                   

                  2010-11-24 16:33:55,996 TRACE [org.jboss.security.auth.spi.LdapExtLoginModule] (http-0.0.0.0-8443-1) initialize
                  2010-11-24 16:33:55,997 TRACE [org.jboss.security.auth.spi.LdapExtLoginModule] (http-0.0.0.0-8443-1) Security domain: jbossmq
                  2010-11-24 16:33:55,997 TRACE [org.jboss.security.auth.spi.LdapExtLoginModule] (http-0.0.0.0-8443-1) login
                  2010-11-24 16:33:56,168 DEBUG [org.jboss.security.auth.spi.LdapExtLoginModule] (http-0.0.0.0-8443-1) Bad password for username=<username>
                  2010-11-24 16:33:56,168 TRACE [org.jboss.security.auth.spi.LdapExtLoginModule] (http-0.0.0.0-8443-1) abort
                  2010-11-24 16:33:56,168 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.jbossmq] (http-0.0.0.0-8443-1) Login failure
                  javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
                       at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:252)
                       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                       at java.lang.reflect.Method.invoke(Method.java:597)
                       at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
                       at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
                       at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
                       at java.security.AccessController.doPrivileged(Native Method)
                       at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
                       at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
                       at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:552)
                       at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:486)
                       at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365)
                       at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160)
                       at org.jboss.web.tomcat.security.JBossWebRealm.authenticate(JBossWebRealm.java:384)
                       at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:258)
                       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:417)
                       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
                       at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
                       at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
                       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
                       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
                       at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
                       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
                       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
                       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
                       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
                       at java.lang.Thread.run(Thread.java:662)
                  2010-11-24 16:33:56,171 TRACE [org.jboss.security.plugins.auth.JaasSecurityManagerBase.jbossmq] (http-0.0.0.0-8443-1) End isValid, false
                  2010-11-24 16:33:56,172 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:null
                  2010-11-24 16:33:56,172 TRACE [org.jboss.security.SecurityRolesAssociation] (http-0.0.0.0-8443-1) Setting threadlocal:null

                   

                  Any more clue?

                   

                  Thanks and best wishes,

                  Stefan