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

    Problems with LdapExtLoginModule

    Stefan Henz Newbie

      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

        • 2. Re: Problems with LdapExtLoginModule
          Stefan Henz Newbie

          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
            Stefan Henz Newbie

            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
              Peter Johnson Master

              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
                Stefan Henz Newbie

                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