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

查看:37
本文介绍了用户 DN 不一致的组的 rabbitmq ldap 授权的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用 in_groupin_group_nested 查询针对 LDAP(Microsoft Active Directory)设置 rabbitmq 授权.然而,由于我们的 OU 结构在我们的用户之间是不一致的,这导致了各种 DN 模式,我不得不依赖一个 user_dn_pattern绑定时只需传递 "domainaccount",从身份验证的角度来看,这对 Microsoft Active Directory 非常有效.但是,当涉及到 in_group/in_group_nested 查询时,它不匹配,因为 members 属性是实际 DN 的列表,并且日志显示它正在尝试在成员列表中查找 "domainaccount".

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 "domainaccount" 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 "domainaccount" 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 设置为元组 {UserDN, Password}.

To do the lookup before binding, set auth_ldap.dn_lookup_bind to a tuple {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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆