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

[Docs] Caching Issue with Pooling Enabled for LDAP

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • None
    • AMQ 7.10.2.GA, AMQ 7.11.1.GA
    • console, documentation, security
    • None
    • 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.

        1. image-2024-05-14-10-51-49-619.png
          image-2024-05-14-10-51-49-619.png
          104 kB

              jcliffor@redhat.com John Clifford
              rhn-support-dhawkins Duane Hawkins
              Michal Toth Michal Toth
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: