Question

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

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

Answer 1

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

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

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

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经理”的凭据，但是它可以是具有足够权限以对目标用户条目执行搜索的任何帐户。

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

编辑-尽管文档说明了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授权

1 个答案: