☰

Subversion：Apache mod_ldap - 首次身份验证需要 30 秒

tag-icon • tag-icon active-directory svn ldap subversion-edge
Subversion：Apache mod_ldap - 首次身份验证需要 30 秒

我在使用 Apache（mod_ldap 和 mod_authnz_ldap）安装 Subversion 服务器以及与 Microsoft Active Directory 的 LDAP 连接时遇到问题，我正在使用带有 Collabnet Subversion EDGE 的 CentOS5 64 位系统。

问题在于与我的 LDAP 的连接，因为第一次身份验证需要整整 30 秒。

以下是日志文件片段。

首次身份验证myLdapUser：

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:00 2012] [debug] mod_authnz_ldap.c(403): [client xx.xx.xx.xx] [3122] auth_ldap authenticate: using URL ldap://10.10.10.11/DC=mycompany,DC=com?sAMAccountName?sub

==> /opt/csvn/data/logs/access_2012_04_24.log <==
xx.xx.xx.xx - myLdapUser [24/Apr/2012:10:42:00 +0200] "GET /svn/ HTTP/1.1" 200 132

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:30 2012] [debug] mod_authnz_ldap.c(518): [client xx.xx.xx.xx] [3122] auth_ldap authenticate: accepting myLdapUser
[Tue Apr 24 10:42:30 2012] [info] [client xx.xx.xx.xx] Access granted: 'myLdapUser' GET (null)

如您所见，使用 ldap URL 和接受的身份验证之间存在 30 秒的时间间隔。在第一次缓慢但成功的身份验证后，我是否重新加载页面，一切都在一秒钟内完成，请参阅此日志文件片段：

==> /opt/csvn/data/logs/access_2012_04_24.log <==
xx.xx.xx.xx - myLdapUser [24/Apr/2012:10:42:51 +0200] "GET /svn/ HTTP/1.1" 200 132

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:51 2012] [debug] mod_authnz_ldap.c(403): [client xx.xx.xx.xx] [3123] auth_ldap authenticate: using URL ldap://10.10.10.11/DC=mycompany,DC=com?sAMAccountName?sub
[Tue Apr 24 10:42:51 2012] [debug] mod_authnz_ldap.c(518): [client xx.xx.xx.xx] [3123] auth_ldap authenticate: accepting myLdapUser
[Tue Apr 24 10:42:51 2012] [info] [client xx.xx.xx.xx] Access granted: 'myLdapUser' GET (null)

看一下 LDAP 服务器：首先它成功绑定，然后它非常快速地执行搜索请求并获取具有用户“myLdapUser”完整值的搜索请求条目，然后，用户尚未经过身份验证，30 秒后，它使用搜索请求条目的用户信息再次调用 Active Directory，之后，用户被接受。

有人知道发生什么事了吗？

我也在这里发布了这个问题，但这不是一个颠覆性的问题，它与 Apache 和 mod_ldap 有关，所以我认为我不会在那里得到帮助：http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=417998

答案1

为了完整起见，您应该发布实际的 mod_authz_ldap 配置指令，而不仅仅是日志片段。对我来说，这听起来像是 Apache 和 AD 之间的某个 DNS 问题，但如果没有更多信息，我无法确定。

ldapsearch您应该尝试在 CentOS 机器上手动进行身份验证，看看是否可以在那里重现该问题。例如：

ldapsearch -xLLLZ -D sAMAccountName=myLdapUSer,dc=mycompany,dc=com -W \
 -b dc=mycompany,dc=com -H ldap://10.10.10.11

答案2

根据我对 Active Directory 的“LDAP”（我大致使用该术语）的经验，这可能是一个引用问题。

默认情况下，当您连接到目录控制器上的端口 389 时，除了常规 LDAP 答案之外，您还会从对“directory.ads.example.com”的引用中获得答案。大多数 LDAP 客户端（包括 Apache）都遵循引用，如果您有许多 DC（尤其是如果它们在地理上分散），那么您的 LDAP 客户端可能会被发送到网络中。我曾经有一个位于加拿大蒙特利尔的 LDAP 客户端定期前往我们位于澳大利亚悉尼的 DC 之一。

因此，您的 Apache 配置中不应存在如下内容：

AuthLDAPURL ldap://mydc1.example.com/dc=example,dc=com?uid?one

这将转到端口 389，始终确保指定全局目录端口：

AuthLDAPURL ldap://mydc1.example.com:3268/dc=example,dc=com?uid?one

如果您需要 SSL，那么就是端口 3269。（真希望 MS 不要将他们的服务称为 LDAP，因为在很多方面它都不是，而且只会造成混乱。）

PS 将来，请养成发布配置文件相关部分的习惯（可以随意混淆任何用户名、密码和/或域名）。

答案3

看起来 DNS 出了点问题。30 秒可能是 Apache 或 LDAP 服务器端某些 DNS 查询的超时时间。我会再检查一下！

答案4

我会嗅探网络数据包，看看延迟发生在哪里。它应该会显示 DNS 响应是否需要很长时间才能返回，或者 LDAP 响应是否缓慢，或者是否存在其他您未预料到的延迟，例如 DAM 建议的 LDAP 引用。

相关内容