GitLab Active Directory аутентификация: без результатов и без аутентификации


8

Я пытаюсь настроить аутентификацию LDAP с помощью GitLab (версия 7.12.2 установлена ​​на Ubuntu 14.04, amd64 на виртуальной машине, настроен Omnibus). Я отредактировал мой файл gitlab.rb, чтобы он выглядел следующим образом:

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
 main: # 'main' is the GitLab 'provider ID' of this LDAP server
   label: 'LDAP'
   host: '********'
   port: 389
   uid: 'sAMAccountName'
   method: 'plain' # "tls" or "ssl" or "plain"
   bind_dn: 'CN=********,OU=********,OU=********,DC=********,DC=***'
   password: '********'
   active_directory: true
   allow_username_or_email_login: false
   block_auto_created_users: false
   base: 'DC=********,DC=***'
   user_filter: ''
EOS

Это приводит к страшному «Не удалось авторизовать вас из Ldapmain из-за« Неверные учетные данные »». ошибка. Я пытался, для имени пользователя (в переменной bind_dn): "johnsmith@example.com" (электронная почта на основе имени пользователя), "John Smith" (полное имя) и "johnsmith" (имя пользователя). Результаты всегда одинаковы. В моем пароле есть знак @. Я не уверен, нужно ли мне избежать этого или как.

Логи показывают это:

Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"********", "password"=>"[FILTERED]"}
Redirected to http://192.168.56.102/users/sign_in
Completed 302 Found in 14ms (ActiveRecord: 3.6ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by SessionsController#new as HTML
Completed 200 OK in 20ms (Views: 8.3ms | ActiveRecord: 2.9ms)

И gitlab-rake gitlab:ldap:checkпоказывает это:

Checking LDAP ...

LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain

Checking LDAP ... Finished

Однако, когда я использую ldapsearch из виртуальной машины Ubuntu (такая же среда), я получаю кучу результатов:

ldapsearch -x -h ******** -D "********@********.***" -W -b "OU=********,OU=********,DC=********,DC=***" -s sub "(cn=*)" cn mail sn dn

Любопытно, что DN в результатах выглядят так:

dn: CN=John Smith,OU=********,OU=********,OU=********,DC=********,DC=***

То есть там есть дополнительная OU. Я также вижу, что команда ldapsearch имеет -s sub, что, я считаю, означает поиск в подгруппах. Я не очень знаком с плюсами и минусами LDAP или Active Directory.

Поэтому я считаю, что что-то упустил в своей базе, но я не уверен, что. Это также может быть проблема с пользовательским фильтром. Я сделал необходимое Googling, которое дало мне это далеко, но теперь у меня нет идей и решений.


1
Ваша запись для baseвыглядит немного коротким. Что происходит, когда вы помещаете туда полный путь из результата ldapsearch (включая все OU)?
etagenklo

@etagenklo: вы правы. Я сделал некоторые другие изменения и смог заставить его работать. Я отправлю как ответ для потомков.
Сирида

этот ответ может быть полезен: stackoverflow.com/a/54462889/6290553
Рактим Бисвас

Ответы:


11

Я смог решить эту проблему после многих разных попыток. Несколько заметок:

  • Убедитесь, что все строки, кроме первой, имеют один пробел для отступа. Первая строка - это та, которая говорит "main:" и у которой нет отступа вообще.
  • Bind_dn - это не полный путь LDAP для пользователя bind, а просто имя пользователя. В моем случае это "xxx@example.com".
  • Основой должна быть группа Active Directory или DN или как она называется, которая содержит всех пользователей.

Вот окончательный YAML:

main: # 'main' is the GitLab 'provider ID' of this LDAP server
 label: 'Active Directory'
 host: 'ad-server.example.com'
 port: 389
 uid: 'sAMAccountName'
 method: 'plain' # "tls" or "ssl" or "plain"
 bind_dn: 'user@example.com'
 password: 'password'
 active_directory: true
 allow_username_or_email_login: false
 block_auto_created_users: false
 base: 'OU=ABC,OU=XYZ,DC=example,DC=com'
 user_filter: ''

1
столько +1! Это единственное решение во всей сети stackexchange, которое работало на меня!
Нуар
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.