> In this period applications cannot connect to the broker due to login
failure.
Any user that has previously authenticated successfully and whose
authentication has been cached should still be able to connect successfully
to the broker due to the cache. Only users who aren't in the cache should
fail to connect.
> Is it possible to handle this exception in the LDAPLoginModule and assume
that this server is not operational, and it needs to try to connect to
another server?
There is currently no functionality in the LDAPLoginModule to retry on
specific failures. Such a feature would have to be implemented, although
I'm not sure that would be a good idea at this point.
It's worth noting that the com.sun.jndi.ldap.LdapCtxFactory (provided by
the JVM) is ultimately responsible for which URL is used to make the
connection. According to this documentation [1]:
If the list contains more than one URL, the provider should attempt to
use each URL in turn until it is able to create a successful connection,
and after creation, set the property to the successful URL.
Therefore, the fact that the LDAP server is actually listening on the LDAP
port and the network connection is successful indicates to me that this
wouldn't solve your problem. The problem isn't that the network connection
fails. The problem is that the network connection succeeds but the LDAP
server isn't fully operational.
It might actually be better to configure multiple "sufficient" instances of
the LDAPLoginModule with one server in the URL instead of one "required"
instance of LDAPLoginModule with multiple URLs, e.g.:
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule
sufficient
debug=true
initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
ignorePartialResultException=true
noCacheExceptions="javax.naming.AuthenticationException,java.net.ConnectException,java.net.SocketTimeoutException,java.net.NoRouteToHostException,java.net.SocketException"
connectionURL="ldaps://server1.domain.tld:636"
connectionUsername="user_for_ldap_bind"
connectionPassword=""
connectionProtocol="s"
connectionTimeout="5000"
readTimeout="5000"
authentication=simple
userBase="DC=domain,DC=tld"
userSearchMatching="(sAMAccountName={0})"
userSearchSubtree=true
userRoleName="memberOf"
roleName="CN"
;
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule
sufficient
debug=true
initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
ignorePartialResultException=true
noCacheExceptions="javax.naming.AuthenticationException,java.net.ConnectException,java.net.SocketTimeoutException,java.net.NoRouteToHostException,java.net.SocketException"
connectionURL="ldaps://server2.domain.tld:636"
connectionUsername="user_for_ldap_bind"
connectionPassword=""
connectionProtocol="s"
connectionTimeout="5000"
readTimeout="5000"
authentication=simple
userBase="DC=domain,DC=tld"
userSearchMatching="(sAMAccountName={0})"
userSearchSubtree=true
userRoleName="memberOf"
roleName="CN"
;
Justin
[1]
https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-ldap-gl.html#url
On Wed, Apr 3, 2024 at 10:56 AM MILOVIDOV Aleksandr
<aleksandr.milovi...@raiffeisen.ru.invalid> wrote:
> Hi All,
>
> We are using LDAPLoginModule with Active Directory. For some reason, when
> LDAP server is restarted, it begins to listen LDAP port, but returns
> authentication errors until it was fully loaded. Usually it takes about
> 30-60 seconds to begin normal operation. In this period applications cannot
> connect to the broker due to login failure.
>
> The error is: Failed to open context
> javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308:
> LdapErr: DSID-0C09050F, comment: AcceptSecurityContext error, data 52e,
> v4f7c^@]
> Caused by: javax.security.auth.login.FailedLoginException: Error opening
> LDAP connection
>
> I have configured noCacheExceptions with this exception and most common
> errors which can be received when connecting to LDAP, but it helps only to
> avoid caching these errors, not to completely avoid it (even if we have
> specified two servers in LDAP connection URL).
> Is it possible to handle this exception in the LDAPLoginModule and assume
> that this server is not operational, and it needs to try to connect to
> another server?
>
> Example LDAPLoginModule configuration section:
>
> org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule required
> debug=true
> initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
> ignorePartialResultException=true
>
> noCacheExceptions="javax.naming.AuthenticationException,java.net.ConnectException,
> java.net
> .SocketTimeoutException,java.net.NoRouteToHostException,java.net.SocketException"
> connectionURL="ldaps://server1.domain.tld:636
> ldaps://server2.domain.tld:636"
> connectionUsername="user_for_ldap_bind"
> connectionPassword=""
> connectionProtocol="s"
> connectionTimeout="5000"
> readTimeout="5000"
> authentication=simple
> userBase="DC=domain,DC=tld"
> userSearchMatching="(sAMAccountName={0})"
> userSearchSubtree=true
> userRoleName="memberOf"
> roleName="CN"
> ;
>
> I also read documentation for JNDI LDAP (
> https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-ldap.html
> section 6.2)
> and found that I can specify URL in format like
> "ldaps://DC=domain,DC=tld". It could work as auto-discovery for LDAP
> service.
> The result was strange: broker tries to connect randomly to each domain
> controller to port 389 (not LDAPS 636) and receives connection refused
> (probably because each server's name was FQDN with "." on the end):
> javax.naming.CommunicationException: server1.domain.tld.:389
>
> --
> Best regards,
> Aleksandr
>
>
> -----------------------------------
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient
> any use, distribution, copying or disclosure is strictly prohibited. If you
> have received this message in error, please notify the sender immediately
> either by telephone or by e-mail and delete this message and any attachment
> from your system. Correspondence via e-mail is for information purposes
> only. AO Raiffeisenbank neither makes nor accepts legally binding
> statements by e-mail unless otherwise agreed.
>
> -----------------------------------
>
