用户DN不一致的组的Rabbitmq ldap授权 [英] rabbitmq ldap authorization for groups with inconsistent user DNs

问题描述

我正在尝试使用 in_group 或 in_group_nested 查询针对LDAP(Microsoft Active Directory)设置Rabbitmq授权.但是，由于我们的 OU 结构在整个用户中不一致，导致出现各种 DN 模式，因此我不得不依靠 user_dn_pattern 绑定时只需传递"domain \ account" ，这从Microsoft Active Directory的身份验证角度来看非常有用.但是，当涉及到 in_group / in_group_nested 查询时，由于成员属性是实际 DN 的列表，因此它不匹配，日志显示它正在尝试在成员列表中找到"domain \ account" .

I'm trying to set up rabbitmq authorization against LDAP (Microsoft Active Directory) using the in_group or in_group_nested queries. However, since our OU structure is inconsistent across our users, which results in a variety of DN patterns, I had to rely on a user_dn_pattern that simply passes the "domain\account" when binding, which works great from an authentication perspective with Microsoft Active Directory. However, when it comes to the in_group/in_group_nested queries, it doesn't match because the members property is a list of actual DNs, and logs show that it's trying to find "domain\account" in the member list.

由于LDAP插件要求使用单一模式从提供的用户名构造 DN ，所以我是否很幸运在RabbitMQ中使用组级LDAP授权?

Since the LDAP plugin demands a single pattern to construct DNs from the supplied username, am I simply out of luck to use group level LDAPauthorization in RabbitMQ?

推荐答案

即使考虑DN不一致也应该是可能的，这里的问题似乎在于身份验证期间将用户名转换为DN的方式.

It should be possible even considering DN inconsistencies, the issue here seems to reside in the way usernames are translated into DNs during the authentication.

与其依靠dn模式，不如尝试通过LDAP查找.

Instead of relying on a dn pattern, try via an LDAP lookup.

关键是设置 dn_lookup_bind 在用户身份验证之前 进行查找.这样，LDAP插件将首先与这些凭据绑定以进行查找，然后与匹配条目的DN绑定以进行用户登录:

The key is to set dn_lookup_bind to do the lookup before the user authentication. This way, the LDAP plugin will bind with these credentials first to do the lookup, then bind with the matching entry's DN to do the user login :

auth_ldap.dn_lookup_attribute = userPrincipalName     # or sAMAccountName
auth_ldap.dn_lookup_base = dc=example,dc=com          # restrict to user ou if any
auth_ldap.dn_lookup_bind = {managerDN, Password}      # AD manager account

# auth_ldap.user_dn_pattern should be left unset to be sure the lookup actually searches 
# for a match in dn_lookup_attribute and not for a built-up dn. 

我提到了来自"AD经理"的凭据，但是它可以是具有足够权限以对目标用户条目执行搜索的任何帐户.

I mentioned credentials from an 'AD manager' but it could be any account with sufficient permissions to perform a search on the targeted user entries.

鉴于该配置，当插件进入授权过程时，它可以使用实际用户dn正确处理组成员身份查找.

Given that configuration, when the plugin comes to the authorization process, it can properly handle the group membership lookup using the actual user dn.

编辑-尽管文档说明了有关 auth_ldap.dn_lookup_bind

Edit - Despite what the documentation states about auth_ldap.dn_lookup_bind

要在绑定之前进行查找，请将auth_ldap.dn_lookup_bind设置为a元组 {UserDN，Password} .

显式设置可能更安全:

auth_ldap.dn_lookup_bind.user_dn = <UserDN>
auth_ldap.dn_lookup_bind.password = <Password>
# (OP was required to do so to make it work)

这篇关于用户DN不一致的组的Rabbitmq ldap授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！