我在使用代理授权进行更新时遇到了一些问题。我使用 UnboundID 的 LDAP SDK 连接到 OpenLDAP,并发送ProxiedAuthorizationV2RequestControl更新dn: uid=me,dc=People,dc=example,dc=com
。我已经测试并验证目标用户有权执行该操作,但我得到了
访问权限不足
当我尝试通过代理认证来执行此操作时。
我已经olcAuthzPolicy=both
在原始用户cn=config
中进行了配置authzTo={0}ldap:///dc=people,dc=example,dc=com??subordinate?(objectClass=inetOrgPerson)
。authzTo 似乎正在工作;当我更改它时,我得到了
无权冒充身份
当我尝试更新时(也用于搜索)。
我现在不用 saslauthd 就可以ldapwhoami -U portal -Y DIGEST-MD5 -X u:mace -H ldap://yorktown -Z
运行它了。我只需要将代理用户(门户)的密码存储为纯文本。但当我尝试更新任何内容时,我仍然收到“访问权限不足”的提示。
代理用户
dn: uid=portal,ou=Special Accounts,dc=example,dc=com
objectClass: inetOrgPerson
cn: portal
sn: portal
uid: portal
userPassword: test
authzTo: {0}ldap:///dc=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)
有效用户:
dn: employeeNumber=1400,dc=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: shadowAccount
uid: mace
...
这是尝试更新的日志,尝试添加为employeeNumber=1385
。它似乎正确地查看了嵌套组,但似乎一旦到达 中的 employeeNumber=1400 就应该指示匹配。member
cn=Data Management
cn=administrators
op tag 0x66, time 1299022001
conn=31595 op=2 do_modify
conn=31595 op=2 do_modify: dn (cn=Data Management,dc=Roles,dc=example,dc=com)
>>> dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>
<<< dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>, <cn=data management,dc=roles,dc=example,dc=com>
conn=31595 op=2 modifications:
replace: member
multiple values
conn=31595 op=2 MOD dn="cn=Data Management,dc=Roles,dc=example,dc=com"
conn=31595 op=2 MOD attr=member
>>> dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
>>> dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1020,dc=people,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1385,dc=people,dc=example,dc=com>
dnMatch -1 "employeeNumber=1020,dc=people,dc=example,dc=com" "employeeNumber=1385,dc=people,dc=example,dc=com"
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
==> unique_modify <cn=Data Management,dc=Roles,dc=example,dc=com>
bdb_modify: cn=Data Management,dc=Roles,dc=example,dc=com
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
bdb_modify_internal: 0x00000043: cn=Data Management,dc=Roles,dc=example,dc=com
>>> dnNormalize: <cn=Administrators,ou=LDAP,dc=Applications,dc=example,dc=com>
<<< dnNormalize: <cn=administrators,ou=ldap,dc=applications,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=administrators,ou=ldap,dc=applications,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=administrators,ou=ldap,dc=applications,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
<<< dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=system administrators,dc=roles,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=system administrators,dc=roles,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1306,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1306,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1329,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1329,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1401,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1401,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1400,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1400,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
bdb_modify: modify failed (50)
send_ldap_result: conn=31595 op=2 p=3
send_ldap_result: err=50 matched="" text=""
send_ldap_response: msgid=3 tag=103 err=50
conn=31595 op=2 RESULT tag=103 err=50 text=
答案1
大约一年前我就遇到过这种情况,代理授权让我抓狂。所以我可能没有明确的答案,但也许我可以提供帮助。
首先:增加 slapd 上的日志级别!虽然冗长,但很有帮助。其次:使用 ldapwhoami 测试代理授权。您可以使用 -X 选项指定目标用户,并使用 -U 指定代理用户。
# ldapwhoami -U proxyuser -Y DIGEST-MD5 -X u:targetuser -H ldap://localhost
您应该在配置中启用两个参数。olcAuthzPolicy(你有)和olcAuthzRegexp(用于构建 SASL 身份验证字符串)。以下是我的配置内容:
olcAuthzRegexp: "^uid=([^,]+).*,cn=[^,]*,cn=auth$"
"ldap:///dc=example,dc=net??sub?(uid=$1)"
olcAuthzPolicy: to
最后,正如你所说,你的代理用户应该有一个授权属性。这是我的一个代理用户的定义:
dn: cn=proxyuser,dc=example,dc=net
uid: proxyuser
mail: [email protected]
sn: proxyuser
cn: proxyuser
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
authzTo: {0}ldap:///dc=example,dc=net??sub?(objectClass=inetOrgPerson)
userPassword:: iodqwhdowihw0123hef92e=
现在应该足以使代理授权工作(再次使用 ldapwhoami 进行测试)。我已经在我的 wiki 上写了一章关于此内容的内容(SASL 和代理授权),因为我需要它从 cyrus-imapd 和 postfix 连接到 openldap。有关更多信息,请查看它:http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openldap_debian#sasl
答案2
在 Julien 的帮助下解决了几个配置问题后,我发现 UnboundID LDAP SDK v2.0.0 中有一个错误,它显然会导致修改请求在没有控制的情况下发送。我得到了他们的论坛提供了出色的支持,在我发布日志识别问题后几个小时内,他们就为我构建了一个新的版本,听起来这个问题将在 2.1.0 版本中得到修复。现在我的代码运行正常。