Назад | Перейти на главную страницу

Как определить значения для привязки LDAP к контроллеру домена Windows Server 2012? [Gitlab Omnibus 7.0.0; ldap_bind: Недействительные учетные данные (49)]

РЕДАКТИРОВАТЬ: Этот вопрос получил много просмотров, и я никогда не возвращался и не предлагал точное, пошаговое решение. Итак, я вернулся через 18 месяцев и сделал это. Это решение работает для простых привязок, и исходный вопрос задается в контексте попытки привязать установку Gitlab Omnibus к серверу LDAP, но оно должно работать в случае любого простого связывания LDAP. См. В моем принятом ответе точные шаги, которые я сделал для решения. Вот подробности моей версии Gitlab (для тех, у кого есть эта проблема с Gitlab):

Исходное сообщение: Я почти 6 часов пытаюсь настроить свое развертывание Gitlab для аутентификации через Windows Server 2012 Essentials Active Directory LDAP.

Я использую Ubuntu 14.04 для своего сервера Gitlab. Он уже подключен к контроллеру домена через SSSD.

Сам Gitlab использует настройки LDAP из конфигурационного файла gitlab.rd следующим образом:

# These settings are documented in more detail at
# https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/gitlab.yml.example#L118
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = 'hostname of LDAP server'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'sAMAccountName'
gitlab_rails['ldap_method'] = 'plain' # 'ssl' or 'plain'
gitlab_rails['ldap_bind_dn'] = 'CN=query user,CN=Users,DC=mycorp,DC=com'
gitlab_rails['ldap_password'] = 'query user password'
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'DC=mycorp,DC=com'

Я могу запросить сервер, но какие бы настройки я ни выбрал, я ВСЕГДА получаю одно и то же сообщение:

"Invalid Credentials"

Я попытался вручную запросить DC с помощью ldapsearch и того же сообщения об ошибке:

"ldap_bind: invalid credentials (49)

Я уже создал пользователя, которого использую для привязки к разделу «Пользователи Active Directory» в моем диспетчере сервера Windows Server 2012.

Я пробовал каждую комбинацию OU = Users, CN = Users и других пользователей, убедился, что все поля адресов электронной почты для всех пользователей в AD заполнены, но я не могу получить ни одного правильного ответа.

Нет ли простого способа вернуть всю информацию Bind_dn и Base для объекта Active Directory? Это очень расстраивает.

Где бы я ни смотрел в Интернете, вся информация относится к старым версиям Windows (ldapsearch и т. Д.). Я новичок в этой работе с Системами (это моя первая летняя стажировка).

Вот пример текущих настроек, которые я использую:

gitlab_rails['ldap_bind_dn'] = 'CN=Gitlab LDAP,OU=Users,DC=servername,DC=local'
gitlab_rails['ldap_base'] = 'OU=Users,DC=servername,DC=local'

И соответствующий пример того, как я пытался использовать ldapsearch, чтобы найти правильные настройки привязки для моих Windows AD DS:

ldapsearch -b "ou=Users,dc=servername,dc=local" -h 192.168.0.3 -p 389 -D "uid=Gitlab LDAP,ou=Users,dc=servername,dc=local" -w "<password>"

Но безрезультатно. Я перепробовал десятки комбинаций. Пользователь "gitlab" имеет отображаемое имя "Gitlab LDAP" в Windows Server с адресом электронной почты, все в нижнем регистре. Итог: есть ли какой-нибудь простой способ щелкнуть объект в Windows DC и получить правильные настройки LDAP для использования этого пользовательского объекта для привязок ldap ?! Если бы я был склонен к эмоциональным всплескам, я бы сделал это именно здесь.

Всегда одно и то же сообщение об ошибке: «Недействительные учетные данные»

Спасибо за ваше время и внимание, любая помощь будет принята с благодарностью.

Я знаю, что это неполный ответ, но я не могу комментировать из-за репутации.
Некоторые моменты для рассмотрения:

  • Из самого ДЦ запускаем ldp.exe. Это настоящий клиент LDAP, поэтому, если вам удастся настроить его для правильной работы, скорее всего, те же параметры будут работать и для Gitlab.
    Видеть этот для основных ldp руководство и убедитесь, что вы прочитали вывод LDP. Это может показать дополнительную информацию, необходимую для вашей конфигурации.
  • Когда дело доходит до доступа LDAP, версия Windows Server не имеет большого значения - возможно, только для проблем, связанных с шифрованием.
  • ldap_uid может ожидать форму DOMAIN\UserName или CN=UserCN,DN=Location,DC=Bla (DistinguishedName).
  • Рассмотрите возможность проверки журналов событий Windows для контроллера домена, к которому вы пытаетесь подключиться. Он может содержать некоторую информацию о том, почему не удалось установить соединение. Попробуйте "неудачные проверки" в журнале "безопасности"

Отправьте ответ с дополнительной информацией, и, возможно, я смогу помочь!

ПРИМЕЧАНИЕ. Скобки типа «крокодил» (<>) необходимо удалить из значений, они используются только для обозначения общих значений.

  1. Создайте пользователя на контроллере домена, чтобы использовать его для привязки LDAP. Вот пример для моего контекста:

    Не думаю, что я действительно что-то изменил, но я изменил учетная запись вкладку, установите ее так, чтобы Пользователь не может изменить пароль и Пароль никогда не истекает. Обратите внимание, что я удалил URL-адрес из конца домена в электронном письме пользователя. Для остальных инструкций я буду использовать <Domain>.<local>, но этот URL может быть любым, соответствующим фактическому полному доменному имени вашего DC (например, microsoft.com).

  2. На самом DC (желательно) или на подключенной к сети и авторизованной машине запустите LDP.exe с повышенными привилегиями. Под Подключение введите полное доменное имя для DC или localhost (в зависимости от того, откуда вы подключаетесь) на порт 389 (или в зависимости от того, на какой порт вы его перенаправили, 389 является портом LDAP по умолчанию). После подключения вы должны увидеть много строк, но одна из первых строк будет:

    configurationNamingContext: CN=Configuration,DC=<Domain>,DC=<local>

    Обратите внимание на эти значения (значения DC соответствуют вашему полному доменному имени и будут использоваться в поиске LDAP позже).

  3. После подключения мы выполним простую привязку к этому пользователю. Щелкните значок Подключение вкладку и выберите связывать вариант. Заполните параметры как таковые (используя информацию о пользователе, которую вы создали на первом шаге):

    В случае успеха вы должны получить сообщение Authenticated as: <Domain>\<username>

  4. После успешного связывания с контроллером домена с помощью ldp.exe под Просматривать вкладка щелкните Поиск вариант:

    В поле Base DN вы скопируете точные значения URL DC, указанные при подключении к серверу. Итак, если соединение показало CN=Configuration,DC=microsoft,DC=com; тогда вы бы положили dc=microsoft,dc=com в поле Base DN.

    Фильтр, который я использовал, - это просто поиск по шаблону для моего имени пользователя, которое я создал ранее. В поле атрибутов я использовал следующие значения:

    objectClass;name;description;canonicalName;lDAPDisplayName

  5. Нажмите Бегать для выполнения вашего поиска. Создается следующий вывод:

    Эта строка, отмеченная КРАСНЫМ, - это значения, которые я использовал для привязки в моей конфигурации gitlab.rb как таковой (обратите внимание, что этот файл был изменен / отредактирован, чтобы отразить приведенный здесь пример). Это отлично сработало, когда я вошел в Gitlab:

    Это шаги, которые я предпринял. Я почти уверен, что те, у кого больше административных возможностей, чем я, вероятно, могли бы изменить этот подход, чтобы узнать все, что они хотят. (Особая благодарность Nitz за то, что указали мне в правильном направлении).

И наконец: в зависимости от того, какую версию Windows вы используете, ваш клиент может использовать SAMAccountName или атрибут UserPrincipleName, как указано в Райан Болджер в комментариях к другому ответу Нитца. Более подробную информацию об этом атрибуте можно найти Вот.