Подтвердить что ты не робот

Как отладить проверку подлинности 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.

4b9b3361

Ответ 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