Как отладить проверку подлинности LDAP Gitlab?
Я пытаюсь настроить LDAP-аутентификацию с помощью gitlab. Моя конфигурация имеет следующий вид:
ldap:
enabled: true
host: 'ldap.example.com'
base: 'ou=People,o=example.com'
port: 636
uid: 'uid'
method: 'ssl' # "ssl" or "plain"
bind_dn: 'cn=gitlab,ou=Apps,o=example.com'
password: 'password'
allow_username_or_email_login: true
Я тестировал его со следующим:
ldapsearch -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldaps://ldap.example.com:636 -w "password" -x "([email protected])"
Строка выше работает, но когда я пытаюсь войти в систему с использованием LDAP, у меня всегда были "недопустимые учетные данные".
Как я могу устранить эту проблему и сузить основную причину этой проблемы?
Редактировать 26/09:
Вот некоторые вещи, которые я нашел на production.log:
Started GET "/users/sign_in" for 127.0.0.1 at 2013-09-23 17:42:58 -0300
Processing by Devise::SessionsController#new as HTML
Rendered devise/sessions/_new_ldap.html.haml (1.7ms)
Rendered devise/sessions/_new_base.html.haml (1.8ms)
Rendered devise/sessions/_oauth_providers.html.haml (0.0ms)
Rendered devise/sessions/new.html.haml within layouts/devise (4.2ms)
Rendered layouts/_head.html.haml (1.6ms)
Rendered layouts/_flash.html.haml (0.1ms)
Completed 200 OK in 9ms (Views: 6.9ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2013-09-23 17:43:00 -0300
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"â", "authenticity_token"=>"AwqZsVHRqOeZr+GLWWeGM7MyOAdk7cFl8/rZgbVRU+8=", "username"=>"[email protected]", "password"=>"[FILTERED]"}
Redirected to http://example.com/users/sign_in
Completed 302 Found in 3ms (ActiveRecord: 0.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2013-09-23 17:43:00 -0300
Processing by Devise::SessionsController#new as HTML
Rendered devise/sessions/_new_base.html.haml (2.8ms)
Rendered devise/sessions/_oauth_providers.html.haml (0.1ms)
Rendered devise/sessions/new.html.haml within layouts/devise (3.7ms)
Rendered layouts/_head.html.haml (1.7ms)
Rendered layouts/_flash.html.haml (0.1ms)
Completed 200 OK in 9ms (Views: 6.6ms | ActiveRecord: 0.0ms)
Started GET "/" for 127.0.0.1 at 2013-09-23 18:50:08 -0300
Processing by DashboardController#show as HTML
Completed 401 Unauthorized in 1ms
Изменить: я наконец получил ответ: конфигурация при разработке была лишена необходимости после "@". Я не могу вспомнить точное имя, но я могу опубликовать сообщение, как только я получу доступ к машине. Я обнаружил это, добавив журналы в ldap oauth login.
Ответы
Ответ 1
OP kidbomb упоминает:
Конфигурация при разработке была удалила все после "@
" .
Я обнаружил это, добавив журналы в ldap oauth login.
Проверьте, доступен ли сервер LDAP через ldap
(не ldaps://
)
ldapsearch -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldap://ldap.example.com:389 -w "password" -x "([email protected])"
Если да, попробуйте изменить файл настроек gitlab.yml
ldap.method
с 'ssl' на "plain
".
Цель состоит в том, чтобы проверить, является ли сертификат, используемый для связи с сервером ldap, здесь или нет.
Если вы можете связаться с сервером через ldap://(без сертификата), это даст вам хотя бы обходной путь.
Если нет (вам нужно пройти через ldaps://
), вам нужно более подробно изучить сертификат, связанный с сервером LDAP.
openssl s_client -connect ldap.example.com:636 2>/dev/null < /dev/null
(Я не использую -CAFile
или -CAPath
здесь, полагая, что CA находятся по умолчанию по умолчанию, указанному в /etc/ssl/openssl.cnf
)
Если вы получите в конце вывода этой команды сообщение:
error:num=21:unable to verify the first certificate
Это означает, что вам нужно получить сертификат от эмитента.
См. " Как проверить сертификат SSL из командной строки.
Ответ 2
У нас были gitlabs, настроенные с учетными данными LDAP, но всякий раз, когда кто-то вошел в систему, мы получали сообщения "500 Internal Server Error". Проблема, казалось, ушла, однако, когда мы отформатировали файл /etc/gitlab/gitlab.rb правильно. Кажется, есть разные способы форматирования переменных ldap, в зависимости от того, какую версию gitlabs вы используете: 7.3.2.omnibus и master.
Ответ 3
Я вижу, что вы нашли решение для своего сценария, но я подумал, что включу некоторые дополнительные шаги по устранению неполадок для других, которые сталкиваются с проблемами аутентификации с GitLab и LDAP.
- Запустите GitLab LDAP rake check, чтобы локализовать проблему.
https://docs.gitlab.com/ce/administration/raketasks/ldap.html#check
. Там также более всеобъемлющий, который указан в документе установки GitLab, который вы используете.
- Если вы используете SELinux, установите его в разрешающем режиме.
- Если вы используете Apache с GitLab: установите LDAP - Apache Directory Studio
и попытайтесь установить соединение. Если вы не можете
вероятно, неправильно в файле config.yml. Я бы начал с рассмотрения
основа.
- Запустите tcpdump и импортируйте файл .pcap в WireShark для insepction.
- Просмотрите журналы на вашем сервере LDAP и сервере GitLab