使用 Microsoft Active Directory 的人群 LDAP 配置
Crowd LDAP configuration with Microsoft Active Directory
我在 Crowd 中配置 LDAP 时遇到问题。
背景
远程 CentOS 服务器 运行 Atlassian Crowd 需要与内部 Microsoft Active Directory 集成。
我们使用以下混淆细节配置了 Crowd：
- URL:ldap://ldaps.xyzgroup.com.uk:389
- 基本 DN：OU=用户，DC=xyz，DC=local
- 用户帐号：xyz\parkbasead
- 密码：
问题
Crowd 正在正确验证服务器，但在用户登录时抛出异常：
AcceptSecurityContext error, data 52e, v1db1]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e, v1db1]
鉴于上述详细信息，什么构成了基本 DN，我们是否应该使用 UPN（完全限定的用户名）从远程服务器登录？
如果 DC=local 应该用有意义的域控制器名称替换，有人可以在基本 DN 中分享想法吗？
这里一一解答，以后真的要避免一题多题。当一个问题中包含多个问题时，人们不太可能提供帮助。
- 在 Active Directory 中，Users 是容器而不是 OU。因此，在您的情况下，作为 LDAP 路径的基本 DN 实际上是：CN=Users,DC=xyz,DC=local。注意逗号后面没有空格。基本 DN 也可以只是 DC=xyz,DC=local。基本 DN 指定在 Active Directory 中搜索的根目录。根据我的经验，如果您是每个大型组织，将基本 DN 指定为目录的根目录确实会在 CPU 时间上产生稍高的成本，因为在 Active Directory 中有更多级别可以查找用户，所以我会首先尝试使用 CN=Users,DC=xyz,DC=local 作为基本 DN，如果这是所有用户所在的位置。如果不是，则尝试 DC=xyz,DC=local，这类似于下面的示例，其中 Base DN 是 ISL.local .
UPN 看起来像 parkbasead@xyz.local。根据我的经验，根据安装的身份验证库，远程服务器可能会或可能不会工作，因此也请单独尝试 parkbasead。当客户端和服务器的域成员身份为 xyz.local.
时，假定 xyz.local
请注意，域控制器名称绝不是 Base DN 的一部分，因为 Base Dn 只不过是一个 LDAP 路径。
这是我在其中找到示例和屏幕截图的关于该主题的很好的外部参考：How to find the correct Base DN setting
编辑：根据我的经验，解决您怀疑可能发送了错误密码或在 Active Directory 中被锁定的帐户问题的最佳方法是使用 Microsoft Account Lockout Status tool。它会告诉您任何帐户锁定的来源，然后您可以快速通知 AD 管理员解锁帐户。小心不要只依赖代码，LDAP 代码可能很隐晦，问题的真正根源可能与代码直接相关，也可能不直接相关。 Microsoft 帐户锁定状态工具示例：
我在 Crowd 中配置 LDAP 时遇到问题。
背景 远程 CentOS 服务器 运行 Atlassian Crowd 需要与内部 Microsoft Active Directory 集成。
我们使用以下混淆细节配置了 Crowd：
- URL:ldap://ldaps.xyzgroup.com.uk:389
- 基本 DN：OU=用户，DC=xyz，DC=local
- 用户帐号：xyz\parkbasead
- 密码：
问题 Crowd 正在正确验证服务器，但在用户登录时抛出异常：
AcceptSecurityContext error, data 52e, v1db1]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e, v1db1]
鉴于上述详细信息，什么构成了基本 DN，我们是否应该使用 UPN（完全限定的用户名）从远程服务器登录？ 如果 DC=local 应该用有意义的域控制器名称替换，有人可以在基本 DN 中分享想法吗？
这里一一解答，以后真的要避免一题多题。当一个问题中包含多个问题时，人们不太可能提供帮助。
- 在 Active Directory 中，Users 是容器而不是 OU。因此，在您的情况下，作为 LDAP 路径的基本 DN 实际上是：CN=Users,DC=xyz,DC=local。注意逗号后面没有空格。基本 DN 也可以只是 DC=xyz,DC=local。基本 DN 指定在 Active Directory 中搜索的根目录。根据我的经验，如果您是每个大型组织，将基本 DN 指定为目录的根目录确实会在 CPU 时间上产生稍高的成本，因为在 Active Directory 中有更多级别可以查找用户，所以我会首先尝试使用 CN=Users,DC=xyz,DC=local 作为基本 DN，如果这是所有用户所在的位置。如果不是，则尝试 DC=xyz,DC=local，这类似于下面的示例，其中 Base DN 是 ISL.local .
UPN 看起来像 parkbasead@xyz.local。根据我的经验，根据安装的身份验证库，远程服务器可能会或可能不会工作，因此也请单独尝试 parkbasead。当客户端和服务器的域成员身份为 xyz.local.
时，假定 xyz.local请注意，域控制器名称绝不是 Base DN 的一部分，因为 Base Dn 只不过是一个 LDAP 路径。
这是我在其中找到示例和屏幕截图的关于该主题的很好的外部参考：How to find the correct Base DN setting
编辑：根据我的经验，解决您怀疑可能发送了错误密码或在 Active Directory 中被锁定的帐户问题的最佳方法是使用 Microsoft Account Lockout Status tool。它会告诉您任何帐户锁定的来源，然后您可以快速通知 AD 管理员解锁帐户。小心不要只依赖代码，LDAP 代码可能很隐晦，问题的真正根源可能与代码直接相关，也可能不直接相关。 Microsoft 帐户锁定状态工具示例：