Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-8297

Caching Issue with Pooling Enabled for LDAP

XMLWordPrintable

    • False
    • None
    • False
    • Hide

      Example LDAP Module Config:

      activemq {
         org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule required
             debug=true
             initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
             connectionURL="ldap://ad.corp.example.com:389"
             authentication="simple"
             connectionUsername="CN=xxxx,OU=Admins,OU=xxxxt,DC=main,DC=corp,DC=example,DC=com"
             connectionPassword="*********"
             connectionProtocol="s"
             connectionPool=true
             connectionTimeout="0"
             readTimeout="60000"
             userBase="DC=main,DC=corp,DC=example,DC=com"
             userSearchMatching="(&(objectClass=user)(sAMAccountName={0}))"
             userSearchSubtree=true
             userRoleName="memberOf"
             roleBase="DC=main,DC=corp,DC=example,DC=com"
             roleName="cn"
             roleSearchMatching="(&(objectCategory=group)(member={0})(CN=*AMQ*TEST*))"
             roleSearchSubtree=true
             authenticateUser=true
             referral="ignore"
             ignorePartialResultException=true
             expandRoles=true
             expandRolesMatching="(&(objectCategory=group)(member={0}))"
      noCacheExceptions="javax.naming.CommunicationException,javax.naming.NamingException,javax.naming.ServiceUnavailableException,java.net.ConnectException,java.net.SocketTimeoutException,java.net.SocketException,org.apache.activemq.artemis.api.core.ActiveMQSecurityException"
             reload=true;
      };
      

      Note: referral=follow was also tried, along with adding PartialResultException to the noCacheExceptions list

      Example JVM Pool Configuration:

          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.initsize=1"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.maxsize=20"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.prefsize=1"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.timeout=300000"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.debug=ALL"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.protocol=plain"
          JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.authentication=simple"
      

      1. Configure the broker following the example login configuration above. Use the same configuration for jms and console authentication. Use Active Directory as the target LDAP identity provider

      2. Attempt to log into the web console with an existing user, but using the wrong password. The attempt should fail.

      3. Attempt to log in as a different user, this time with the correct password.

      An log entry like: INFO (resource:2435) - AMQ601716: User anonymous@unknown failed authentication, reason: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C090AE1, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839] is observed, and the login fails. Subsequent attempts also fail

      Show
      Example LDAP Module Config: activemq { org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule required debug=true initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory" connectionURL="ldap://ad.corp.example.com:389" authentication="simple" connectionUsername="CN=xxxx,OU=Admins,OU=xxxxt,DC=main,DC=corp,DC=example,DC=com" connectionPassword="*********" connectionProtocol="s" connectionPool=true connectionTimeout="0" readTimeout="60000" userBase="DC=main,DC=corp,DC=example,DC=com" userSearchMatching="(&(objectClass=user)(sAMAccountName={0}))" userSearchSubtree=true userRoleName="memberOf" roleBase="DC=main,DC=corp,DC=example,DC=com" roleName="cn" roleSearchMatching="(&(objectCategory=group)(member={0})(CN=*AMQ*TEST*))" roleSearchSubtree=true authenticateUser=true referral="ignore" ignorePartialResultException=true expandRoles=true expandRolesMatching="(&(objectCategory=group)(member={0}))" noCacheExceptions="javax.naming.CommunicationException,javax.naming.NamingException,javax.naming.ServiceUnavailableException,java.net.ConnectException,java.net.SocketTimeoutException,java.net.SocketException,org.apache.activemq.artemis.api.core.ActiveMQSecurityException" reload=true; }; Note: referral=follow was also tried, along with adding PartialResultException to the noCacheExceptions list Example JVM Pool Configuration: JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.initsize=1" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.maxsize=20" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.prefsize=1" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.timeout=300000" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.debug=ALL" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.protocol=plain" JAVA_ARGS="${JAVA_ARGS} -Dcom.sun.jndi.ldap.connect.pool.authentication=simple" 1. Configure the broker following the example login configuration above. Use the same configuration for jms and console authentication. Use Active Directory as the target LDAP identity provider 2. Attempt to log into the web console with an existing user, but using the wrong password. The attempt should fail. 3. Attempt to log in as a different user, this time with the correct password. An log entry like: INFO (resource:2435) - AMQ601716: User anonymous@unknown failed authentication, reason: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C090AE1, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839] is observed, and the login fails. Subsequent attempts also fail

      When pooling is enabled for the LDAP login module, once a login failure occurs, subsequent login attempts also fail - even if credentials are valid. This only happens with pooling enabled and only happens (as far as we know) with Active Directory as the LDAP service provider. Attempts to reproduce the issue with ApacheDS or 389DS have failed.

              rhn-support-jbertram Justin Bertram
              rhn-support-dhawkins Duane Hawkins
              Roman Vais Roman Vais (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: