Mandate Group Search Condition in Dex LDAP Coonector - kubernetes

I am using Dex as our Identity provider and connecting it to LDAP. Below is my ldap config in Dex:
connectors:
- type: ldap
id: ldap
name: LDAP
config:
host: myhost.staging.com:636
insecureNoSSL: false
insecureSkipVerify: false
bindDN: cn=prometheus-proxy,ou=serviceaccounts,dc=staging,dc=comp,dc=com
bindPW: 'prometheus'
rootCA: /etc/dex/ldap/ca-bundle.pem
userSearch:
baseDN: ou=people,dc=staging,dc=comp,dc=com
filter: "(objectClass=person)"
username: uid
idAttr: uid
emailAttr: mail
nameAttr: uid
groupSearch:
baseDN: ou=appgroups,dc=staging,dc=comp,dc=com
filter: "(objectClass=groupOfMembers)"
userAttr: DN
groupAttr: member
nameAttr: cn
And below is a sample userSearch & groupSearch Result:
dn: uid=swedas01,ou=people,dc=staging,dc=comp,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Sweta Das
gecos: Sweta Das
gidNumber: 50000
givenName: Sweta
mail: Sweta.Das#comp.com
sn: Das
uid: swedas01
memberOf: cn=jenkins,ou=appgroups,dc=staging,dc=comp,dc=com
homeDirectory: /home/swedas01
dn: cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com
objectClass: top
objectClass: groupOfMembers
cn: prometheus
member: uid=testl01,ou=people,dc=staging,dc=comp,dc=com
When I login to my Prometheus instance which uses the above config, even though my userID is not part of the Group that is being used ie Prometheus, I am still able to login.
Dex logs shows there is no groups associated with my id.
time="2019-10-07T19:05:48Z" level=info msg="performing ldap search ou=people,dc=staging,dc=comp,dc=com sub (&(objectClass=person)(uid=swedas01))"
time="2019-10-07T19:05:48Z" level=info msg="username \"swedas01\" mapped to entry uid=swedas01,ou=people,dc=staging,dc=comp,dc=com"
time="2019-10-07T19:05:48Z" level=info msg="performing ldap search cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com sub (&(objectClass=groupOfMembers)(member=uid=swedas01,ou=people,dc=staging,dc=comp,dc=com))"
time="2019-10-07T19:05:48Z" level=error msg="ldap: groups search with filter \"(&(objectClass=groupOfMembers)(member=uid=swedas01,ou=people,dc=staging,dc=comp,dc=com))\" returned no groups"
time="2019-10-07T19:05:48Z" level=info msg="login successful: connector \"ldap\", username=\"swedas01\", email=\"Sweta.Das#comp.com\", groups=[]"
But why is it still allowing me to login? Is there any way I can mandate this setting if group serach returns empty, login should fail?

Since your directory supports memberOf attribute, you can try adding a membership condition in the userSearch filter.
Now look :
username: uid
filter: "(objectClass=person)"
yields the following ldap filter :
"(&(objectClass=person)(uid=<uid>))"
So it might be possible to add the membership condition without operator in the filter setting, as dex is actually adding the operator itself (tested and confirmed by #MohammadYusefpur).
Like :
filter: "(objectClass=person)(memberOf=cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com)"
so that the actual ldap filter results in
(&(objectClass=person)(memberOf=cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com)(uid=<uid>))

I am still not sure if this is the right answer. But as far as I could understood, Dex's group search is just for ldap search. It returns the groups a user is memberof. Once you get the groups back, you can put RBAC policies on those group to control what kind of access you want to give to the user.
However, for tools which do not have any auth methods of its ownn(eg Prometheus), I am still not sure how to implement ldap group auth!

Related

ActiveMQ Artemis AMQ222216: Security problem while authenticating: AMQ229031: Unable to validate user from SSL certificate subject DN: unavailable

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]

How to integrate OpenLDAP to Keycloak correctly?

Installed OpenLDAP by helm
helm install openldap stable/openldap
Check data in the initialized server
kubectl port-forward $OPENLDAP_POD_NAME 3890:389
ldapsearch -x -H ldap://localhost:3890 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=org> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.org
dn: dc=example,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example Inc.
dc: example
# admin, example.org
dn: cn=admin,dc=example,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: [HIDDEN]
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
Install keycloak
helm install keycloak codecentric/keycloak
kubectl port-forward $KEYCLOAK_POD_NAME 8080
Bind it to Keycloak in the User Federation -> Add user storage provider -> ldap as below.
Why can't connect to ldap server? I login to the ldap pod to see the log but didn't find where is it.
The "Connection URL" should most probably be ldap://openldap.default:389 (and if openldap was deployed in a different namespace, replace default with that).

rd-acl says I can make a project, but the Rundeck UI says I can't. What is wrong here?

I put an acl policy in /etc/rundeck for my group.
rd-acl test -c application -g "Cloud Team" -a create -G project
Using configured Rundeck etc dir: /etc/rundeck
The decision was: allowed
The test passed
Then I log into Rundeck via the website and I see this:
You have no authorized access to projects.
Contact your administrator. (User roles: ..., Cloud Team, ...)
For good measure, I temporarily made another acl policy for my user.
I pass the test with my user name.
rd-acl test -c application -u myuser -a create -G project
I also tried a group that does not have a space in the name and got the same results.
If it makes a difference, I am logging in using my AD credentials and the groups are being pulled in from AD.
This is in Rundeck 3.0.20-20190408
My acl policy
description: Admin, all access.
context:
project: '.*' # all projects
for:
resource:
- allow: '*' # allow read/create all kinds
adhoc:
- allow: '*' # allow read/running/killing adhoc jobs
job:
- allow: '*' # allow read/write/delete/run/kill of all jobs
node:
- allow: '*' # allow read/run for all nodes
by:
group: Cloud Team
---
description: Admin, all access.
context:
application: 'rundeck'
for:
resource:
- allow: '*' # allow create of projects
project:
- allow: '*' # allow view/admin of all projects
project_acl:
- allow: '*' # allow admin of all project-level ACL policies
storage:
- allow: '*' # allow read/create/update/delete for all /keys/* storage content
by:
group: Cloud Team
I see errors like this in rundeck.access.log
Evaluating Decision for: res<type:resource, kind:project> subject<Username:MyNameHere Group:OneOfMyGroups Group:AnotherGroup Group:Cloud Team> action<create> env<rundeck:auth:env:application:run
deck>: authorized: false: No context matches subject or environment => REJECTED_NO_SUBJECT_OR_ENV_FOUND (0ms)

Groups are empty while authenticating using DEX (LDAP)

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

openldap setup on Kubernetes cluster

I want to set up OpenLDAP in a Kubernetes cluster running on AWS.
I’ve applied YAML files “https://github.com/osixia/docker-openldap/tree/stable/example/kubernetes/simple” except for service type I choose load balancer.
I’ve added below two ldif files:
base.ldif
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=example,dc=com
objectClass: organizationalUnit
ou: Group
test.ldif
dn: uid=test,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: test
uid: test
uidNumber: 9999
gidNumber: 100
homeDirectory: /home/test
loginShell: /bin/bash
gecos: test admin user
userPassword: password
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
I’ve setup LDAP client on centos 7 system but no result is showing if I execute “getent passwd test”
Please help me with this?