The same user with the same password works after we restart the broker (ActiveMQ Artemis 2.19.0).
With different random users we get the following error message:
AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.27.48.12:49550. Username: lot-sfmsri.fenmqprd; SSL certificate subject DN: unavailable
2021-11-16 23:05:03,150 WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure to /172.27.48.12:49478 has been detected: User name [lot-sfmsri.fenmqprd] or password is invalid. [code=GENERIC_EXCEPTION] component = org.apache.activemq.artemis.core.clienthost = fenacosrv43113log_level = WARNsource = /amq_prd/log/artemis.log
After a restart of the broker other users have the same problem.
We use an ActiveDirectory as the LDAP directory (multiple servers). Here's the login.config:
activemq {
/*
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
debug=false
reload=true
org.apache.activemq.jaas.properties.user="artemis-users.properties"
org.apache.activemq.jaas.properties.role="artemis-roles.properties";
org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule sufficient
debug=false
org.apache.activemq.jaas.guest.user="admin"
org.apache.activemq.jaas.guest.role="amq";
*/
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule sufficient
debug=true
initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
/*
connectionURL - specify the location of the directory server using an ldap URL, ldap://Host:Port.
You can optionally qualify this URL, by adding a forward slash, /, followed by the DN of a particular node in the directory tree.
For example, ldap://ldapserver:10389/ou=system.
*/
/*
connectionURL="ldap://main.corp.fenaco.com:389/"
*/
connectionURL="ldap://ad-ldap-rzsur.main.corp.fenaco.com:389/"
/*
authentication - specifies the authentication method used when binding to the LDAP server. Can take either of the values,
- simple (username and password),
- GSSAPI (Kerberos SASL) or
- none (anonymous)
*/
authentication="simple"
/*
connectionUsername - the DN of the user that opens the connection to the directory server. For example, uid=admin,ou=system.
Directory servers generally require clients to present username/password credentials in order to open a connection.
*/
connectionUsername="CN=lot-fenit.amq,OU=Admins,OU=fou-fenit,DC=main,DC=corp,DC=fenaco,DC=com"
/*
connectionPassword - the password that matches the DN from connectionUsername. In the directory server, in the DIT, the password is normally stored as a userPassword attribute in the corresponding directory entry.
*/
connectionPassword="xxxxxxxxxxxxx"
/*
saslLoginConfigScope - the scope in JAAS configuration (login.config) to use to obtain Kerberos initiator credentials when the authentication method is SASL GSSAPI. The default value is broker-sasl-gssapi
*/
/*
connectionProtocol - currently, the only supported value is a blank string.
In future, this option will allow you to select the Secure Socket Layer (SSL) for the connection to the directory server.
This option must be set explicitly to an empty string, because it has no default value.
*/
connectionProtocol=""
/*
connectionPool - boolean, enable the LDAP connection pool property 'com.sun.jndi.ldap.connect.pool'. Note that the pool is configured at the jvm level with system properties.
*/
connectionPool=true
/*
connectionTimeout - specifies the string representation of an integer representing the connection timeout in milliseconds.
If the LDAP provider cannot establish a connection within that period, it aborts the connection attempt. The integer should be greater than zero.
An integer less than or equal to zero means to use the network protocol's (i.e., TCP's) timeout value.
If connectionTimeout is not specified, the default is to wait for the connection to be established or until the underlying network times out.
When connection pooling has been requested for a connection, this property also determines the maximum wait time for a connection when all connections in the pool are in use and the maximum pool size has been reached.
If the value of this property is less than or equal to zero under such circumstances, the provider will wait indefinitely for a connection to become available; otherwise,
the provider will abort the wait when the maximum wait time has been exceeded. See connectionPool for more details.
*/
connectionTimeout="0"
/*
readTimeout - specifies the string representation of an integer representing the read timeout in milliseconds for LDAP operations. If the LDAP provider cannot get a LDAP response within that period,
it aborts the read attempt. The integer should be greater than zero. An integer less than or equal to zero means no read timeout is specified which is equivalent to waiting for the response infinitely until it is received.
If readTimeout is not specified, the default is to wait for the response until it is received.
*/
readTimeout="60000"
/*
userBase - selects a particular subtree of the DIT to search for user entries. The subtree is specified by a DN, which specifes the base node of the subtree.
For example, by setting this option to ou=User,ou=ActiveMQ,ou=system, the search for user entries is restricted to the subtree beneath the ou=User,ou=ActiveMQ,ou=system node.
*/
userBase="DC=main,DC=corp,DC=fenaco,DC=com"
/*
userSearchMatching - specifies an LDAP search filter, which is applied to the subtree selected by userBase. Before passing to the LDAP search operation,
the string value you provide here is subjected to string substitution, as implemented by the java.text.MessageFormat class.
Essentially, this means that the special string, {0}, is substituted by the username, as extracted from the incoming client credentials.
After substitution, the string is interpreted as an LDAP search filter, where the LDAP search filter syntax is defined by the IETF standard, RFC 2254.
A short introduction to the search filter syntax is available from Oracle's JNDI tutorial, Search Filters.
For example, if this option is set to (uid={0}) and the received username is jdoe, the search filter becomes (uid=jdoe) after string substitution.
If the resulting search filter is applied to the subtree selected by the user base, ou=User,ou=ActiveMQ,ou=system, it would match the entry,
uid=jdoe,ou=User,ou=ActiveMQ,ou=system (and possibly more deeply nested entries, depending on the specified search depth—see the userSearchSubtree option).
*/
userSearchMatching="(sAMAccountName={0})"
/*
userSearchSubtree - specify the search depth for user entries, relative to the node specified by userBase. This option is a boolean.
- false indicates it will try to match one of the child entries of the userBase node (maps to javax.naming.directory.SearchControls.ONELEVEL_SCOPE).
- true indicates it will try to match any entry belonging to the subtree of the userBase node (maps to javax.naming.directory.SearchControls.SUBTREE_SCOPE).
*/
userSearchSubtree=true
/*
userRoleName - specifies the name of the multi-valued attribute of the user entry that contains a list of role names for the user (where the role names are interpreted as group names by the broker's authorization plug-in).
If you omit this option, no role names are extracted from the user entry.
*/
userRoleName="memberOf"
/*
roleBase - if you want to store role data directly in the directory server, you can use a combination of role options (roleBase, roleSearchMatching, roleSearchSubtree, and roleName)
as an alternative to (or in addition to) specifying the userRoleName option. This option selects a particular subtree of the DIT to search for role/group entries.
The subtree is specified by a DN, which specifes the base node of the subtree. For example, by setting this option to ou=Group,ou=ActiveMQ,ou=system,
the search for role/group entries is restricted to the subtree beneath the ou=Group,ou=ActiveMQ,ou=system node.
*/
roleBase="DC=main,DC=corp,DC=fenaco,DC=com"
/*
roleName - specifies the attribute type of the role entry that contains the name of the role/group (e.g. C, O, OU, etc.). If you omit this option, the role search feature is effectively disabled.
*/
roleName="cn"
/*
roleSearchMatching - specifies an LDAP search filter, which is applied to the subtree selected by roleBase. This works in a similar manner to the userSearchMatching option,
except that it supports two substitution strings, as follows:
- {0} - substitutes the full DN of the matched user entry (that is, the result of the user search).
For example, for the user, jdoe, the substituted string could be uid=jdoe,ou=User,ou=ActiveMQ,ou=system.
- {1} - substitutes the received username. For example, jdoe.
For example, if this option is set to (member=uid={1}) and the received username is jdoe, the search filter becomes (member=uid=jdoe) after string substitution (assuming ApacheDS search filter syntax).
If the resulting search filter is applied to the subtree selected by the role base, ou=Group,ou=ActiveMQ,ou=system, it matches all role entries that have a member attribute
equal to uid=jdoe (the value of a member attribute is a DN).
This option must always be set, even if role searching is disabled, because it has no default value.
If you use OpenLDAP, the syntax of the search filter is (member:=uid=jdoe)
*/
roleSearchMatching="(member:1.2.840.113556.1.4.1941:={0})"
/*
roleSearchSubtree - specify the search depth for role entries, relative to the node specified by roleBase. This option can take boolean values, as follows:
- false (default) - try to match one of the child entries of the roleBase node (maps to javax.naming.directory.SearchControls.ONELEVEL_SCOPE).
- true — try to match any entry belonging to the subtree of the roleBase node (maps to javax.naming.directory.SearchControls.SUBTREE_SCOPE).
*/
roleSearchSubtree=true
/*
authenticateUser - boolean flag to disable authentication. Useful as an optimisation when this module is used just for role mapping of a Subject's existing authenticated principals;
default is false
*/
authenticateUser=true
/*
referral - specify how to handle referrals; valid values: ignore, follow, throw;
default is ignore
*/
referral="ignore"
/*
ignorePartialResultException - boolean flag for use when searching Active Directory (AD). AD servers don't handle referrals automatically,
which causes a PartialResultException to be thrown when referrals are encountered by a search, even if referral is set to ignore. Set to true to ignore these exceptions;
default is false
*/
ignorePartialResultException=true
/*
expandRoles - boolean indicating whether to enable the role expansion functionality or not;
default false.
If enabled, then roles within roles will be found. For example, role A is in role B. User X is in role A, which means user X is in role B by virtue of being in role A
*/
expandRoles=false
/*
expandRolesMatching - specifies an LDAP search filter which is applied to the subtree selected by roleBase. Before passing to the LDAP search operation,
the string value you provide here is subjected to string substitution, as implemented by the java.text.MessageFormat class.
Essentially, this means that the special string, {0}, is substituted by the role name as extracted from the previous role search.
This option must always be set to enable role expansion because it has no default value. Example value: (member={0})
*/
expandRolesMatching="(member:1.2.840.113556.1.4.1941:={0})"
reload=true;
};
there are many of these error messages "PartialResultException"
2021-11-23 14:53:39,282 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57345. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,282 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57345 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57345. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,285 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57346. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,285 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57346 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57346. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,285 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57347. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,285 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57347 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57347. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,287 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57349. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,287 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57349 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57349. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,288 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] User CN=lot-fenit.mds.test,OU=Admins,OU=fou-fenit,DC=main,DC=corp,DC=fenaco,DC=com successfully bound.
2021-11-23 14:53:39,288 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Get user roles.
2021-11-23 14:53:39,288 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Looking for the user roles in LDAP with
2021-11-23 14:53:39,288 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] base DN: DC=main,DC=corp,DC=fenaco,DC=com
2021-11-23 14:53:39,288 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] filter: (member:1.2.840.113556.1.4.1941:=CN=lot-fenit.mds.test,OU=Admins,OU=fou-fenit,DC=main,DC=corp,DC=fenaco,DC=com)
2021-11-23 14:53:39,290 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57348. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,290 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57348 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57348. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,290 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57350. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,290 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57350 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57350. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,292 WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from /172.28.84.139:57351. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,293 INFO [org.apache.activemq.audit.resource] AMQ601716: User anonymous#172.28.84.139:57351 failed authentication, reason: AMQ229031: Unable to validate user from /172.28.84.139:57351. Username: lot-b4l9992.fenmqtst; SSL certificate subject DN: unavailable
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] User CN=lot-sfmsri.fenmqtst,OU=Service_Accounts,OU=Admins,OU=fou-fenaco,DC=main,DC=corp,DC=fenaco,DC=com successfully bound.
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] User CN=lot-fenit.mds.test,OU=Admins,OU=fou-fenit,DC=main,DC=corp,DC=fenaco,DC=com successfully bound.
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Get user roles.
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Looking for the user roles in LDAP with
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Get user roles.
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] base DN: DC=main,DC=corp,DC=fenaco,DC=com
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] filter: (member:1.2.840.113556.1.4.1941:=CN=lot-sfmsri.fenmqtst,OU=Service_Accounts,OU=Admins,OU=fou-fenaco,DC=main,DC=corp,DC=fenaco,DC=com)
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] Looking for the user roles in LDAP with
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] base DN: DC=main,DC=corp,DC=fenaco,DC=com
2021-11-23 14:53:39,314 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] filter: (member:1.2.840.113556.1.4.1941:=CN=lot-fenit.mds.test,OU=Admins,OU=fou-fenit,DC=main,DC=corp,DC=fenaco,DC=com)
2021-11-23 14:53:39,507 DEBUG [org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule] PartialResultException encountered and ignored: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'DC=main,DC=corp,DC=fenaco,DC=com'
at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3022) [java.naming:]
at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2996) [java.naming:]
at java.naming/com.sun.jndi.ldap.AbstractLdapNamingEnumeration.getNextBatch(AbstractLdapNamingEnumeration.java:148) [java.naming:]
at java.naming/com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:217) [java.naming:]
at java.naming/com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189) [java.naming:]
at org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule.addRoles(LDAPLoginModule.java:499) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule.resolveRolesForDN(LDAPLoginModule.java:290) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule.authenticate(LDAPLoginModule.java:270) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule.login(LDAPLoginModule.java:196) [artemis-server-2.19.0.jar:2.19.0]
at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726) [java.base:]
at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665) [java.base:]
at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663) [java.base:]
at java.base/java.security.AccessController.doPrivileged(Native Method) [java.base:]
at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663) [java.base:]
at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574) [java.base:]
at org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.getAuthenticatedSubject(ActiveMQJAASSecurityManager.java:138) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager.authenticate(ActiveMQJAASSecurityManager.java:91) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:175) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1681) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:183) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:97) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:820) [artemis-core-client-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:428) [artemis-core-client-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:396) [artemis-core-client-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:688) [artemis-server-2.19.0.jar:2.19.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73) [artemis-core-client-2.19.0.jar:2.19.0]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-all-4.1.68.Final.jar:4.1.68.Final]
at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.19.0.jar:2.19.0]
I have been trying to authenticate OIDC using DEX for LDAP. I have succeeded in authenticating but the problem is, LDAP search is not returning the groups. Following are my DEX configs and LDAP Data. Please help me out
Screenshot: Login successful, groups are empty
My Dex Config
# User search maps a username and password entered by a user to a LDAP entry.
userSearch:
# BaseDN to start the search from. It will translate to the query
# "(&(objectClass=person)(uid=<username>))".
baseDN: ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
# Optional filter to apply when searching the directory.
#filter: "(objectClass=posixAccount)"
# username attribute used for comparing user entries. This will be translated
# and combine with the other filter as "(<attr>=<username>)".
username: mail
# The following three fields are direct mappings of attributes on the user entry.
# String representation of the user.
idAttr: uid
# Required. Attribute to map to Email.
emailAttr: mail
# Maps to display name of users. No default value.
nameAttr: uid
# Group search queries for groups given a user entry.
groupSearch:
# BaseDN to start the search from. It will translate to the query
# "(&(objectClass=group)(member=<user uid>))".
baseDN: dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
# Optional filter to apply when searching the directory.
#filter: "(objectClass=posixGroup)"
# Following two fields are used to match a user to a group. It adds an additional
# requirement to the filter that an attribute in the group must match the user's
# attribute value.
userAttr: uid
groupAttr: memberUid
# Represents group name.
nameAttr: cn
My LDAP Data
dn:
ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
ou: People objectClass: organizationalUnit
dn:
uid=johndoe,ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
gecos: John Doe uid: johndoe loginShell: / bin / bash mail:
john.doe#example.org homeDirectory: / home / jdoe cn: John Doe sn: Doe
uidNumber: 10002 objectClass: posixAccount objectClass: inetOrgPerson
objectClass: top userPassword: bar gidNumber: 10002
dn:
uid=janedoe,ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
gecos: Jane Doe uid: janedoe loginShell: / bin / bash mail:
jane.doe#example.org homeDirectory: / home / jdoe cn: Jane Doe sn: Doe
uidNumber: 10001 objectClass: posixAccount objectClass: inetOrgPerson
objectClass: top userPassword: foo gidNumber: 10001
dn:
ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
ou: Groups objectClass: organizationalUnit
dn:
cn=admins,ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
cn: admins objectClass: posixGroup objectClass: top gidNumber: 20001
memberUid: janedoe memberUid: johndoe
dn:
cn=developers,ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
cn: developers objectClass: posixGroup objectClass: top gidNumber:
20002 memberUid: janedoe
Sorry for a late replay but I didnt know the answer until now :)
I had the same problem, in my setup I used dex (quay.io/dexidp/dex:v2.16.0) to use MS AD. I used kubernetes 1.13 in my tests.
To generate kubeconfig i used heptiolabs/gangway (gcr.io/heptio-images/gangway:v3.0.0) and for handle dashboard login i used pusher/oauth2_proxy (quay.io/pusher/oauth2_proxy).
I spent a lot of time trying different ldap setups in dex but didnt get the AD groups to show up in dex log or get them to work in kubernetes, and every example I read was using only users.
The problem and solution for me was not in the dex config, dex will request groups from ldap if you tell dex to do so.
Its all in the clients. OIDC have a "concept" of scopes and I guess that most (all?) oidc clients implement it, at least both gangway and oauth2-proxy does.
So the solution for me was to configure the client (gangway and oauth2-proxy in my case) so that they also ask dex for groups.
In gangway I used the following config (including the comments)
# Used to specify the scope of the requested Oauth authorization.
# scopes: ["openid", "profile", "email", "offline_access"]
scopes: ["openid", "profile", "email", "offline_access", "groups"]
For oauth2-proxy I added this to the args deployment
- args:
- --scope=openid profile email groups
And then I could use groups instead of users in my rolebindings, dont forget to also configure the api-server to use dex for its oidc.
Hope that helps
-Robert