Subversion: Apache mod_ldap - 30 секунд для первой аутентификации
У меня проблема с установкой сервера Subversion с Apache (mod_ldap и mod_authnz_ldap) и подключением LDAP к Microsoft Active Directory. Я использую систему CentOS5 64Bit с Collabnet Subversion EDGE.
Проблема в подключении к моему 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)
Как вы можете видеть, существует временной интервал в 30 секунд с использованием URL-адреса ldap и принятой аутентификации. Нужно ли перезагружать страницу после первой медленной, но успешной аутентификации, все делается за одну секунду, см. Этот фрагмент файла журнала:
==> /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: сначала он успешно связывается, затем очень быстро выполняет поисковый запрос и получает запись поискового запроса с полными значениями пользователя mymydapUser, затем пользователь еще не аутентифицирован и через 30 секунд, он снова вызывает Active Directory с пользовательской информацией записи запроса поиска, и после этого пользователь принимается.
Кто-нибудь знает, что происходит Вонг?
Я также публикую этот вопрос здесь, но это не проблема subversion, это связано с Apache и mod_ldap, поэтому я думаю, что там мне не помогут: http://subversion.open.collab.net/ds/viewMessage. делать? dsForumId = 3 & dsMessageId = 417998
4 ответа
Ради полноты вы должны опубликовать свои действительные директивы конфигурации mod_authz_ldap, а не только фрагменты журнала. Для меня это звучит как проблема DNS где-то между Apache и AD, но без дополнительной информации я не могу быть уверен.
Вы должны попытаться выполнить аутентификацию вручную, используя, например, ldapsearch на компьютере CentOS и посмотрите, можете ли вы воспроизвести проблему там. Что-то вроде:
ldapsearch -xLLLZ -D sAMAccountName=myLdapUSer,dc=mycompany,dc=com -W \
-b dc=mycompany,dc=com -H ldap://10.10.10.11
Учитывая мой опыт работы с Active Directory "LDAP" (и я использую этот термин свободно), это может быть проблемой рефералов.
По умолчанию, когда вы подключаетесь к порту 389 на контроллере каталогов, помимо обычных ответов LDAP вы получаете ссылку от "directory.ads.example.com". Большинство клиентов LDAP (включая Apache) следуют рекомендациям, и если у вас много контроллеров домена, особенно если они географически распределены, ваш клиент LDAP может быть отправлен в сеть. Однажды у меня был клиент LDAP в Монреале, Канада, который регулярно посещал один из наших офисов в Сиднее, Австралия.
Таким образом, вместо того, чтобы иметь что-то подобное в вашей конфигурации 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 В будущем, пожалуйста, сделайте привычкой публиковать соответствующие части вашего конфигурационного файла (ов) (не стесняйтесь скрывать любые имена пользователей, пароли и / или домены).
Похоже, что-то не так с DNS. 30 секунд может быть тайм-аутом для некоторого DNS-запроса на стороне сервера Apache или LDAP. Я бы еще раз проверил это!
Я бы сделал анализ пакетов в сети, чтобы увидеть, где происходит задержка. Он должен показать вам, требуется ли много времени для ответа DNS, или если ответ LDAP медленный, или есть какая-то другая задержка, которую вы не ожидали, например, направление LDAP, как предлагает DAM.