Настройте Gitlab для использования FreeIPA в качестве LDAP-сервера.

Я столкнулся с небольшой проблемой, и, похоже, не могу её решить.

Пожалуйста, следуйте сценарию ниже:

У меня есть два сервера:

ОДИН (10.0.3.10): основан на Ubuntu, на котором установлен Gitlab (как deb пакет) с следующей конфигурацией

/etc/gitlab/gitlab.rb

# URL, через который будет осуществляться доступ к GitLab.
external_url "https://gitlab.example.com/"

# Перенаправлять http на https или нет.
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/ssl/my-ssl/ssl-unified.crt"
nginx['ssl_certificate_key'] = "/etc/ssl/my-ssl/ssl.key"

# Каталог, где будут храниться Git репозитории.
git_data_dir "/var/opt/gitlab/git-data"

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # не забудьте закрыть этот блок 'EOS' ниже
main: # 'main' - это 'provider ID' GitLab для этого LDAP сервера
  ## метка
  #
  # Человеко-доступное имя вашего LDAP сервера. Изменять метку позже нормально,
  # например, если вы обнаружите, что она слишком велика, чтобы разместиться на веб-странице.
  #
  # Пример: 'Париж' или 'Acme, Ltd.'
  label: 'LDAP'

  host: '10.0.3.100'
  port: 389
  #uid: 'sAMAccountName'
  uid: 'uid'
  method: 'plain' # "tls" или "ssl" или "plain"
  bind_dn: 'uid=gitlab_ldap,cn=users,cn=accounts,dc=example'
  password: 'test'

  # Эта настройка указывает, является ли LDAP сервер Active Directory LDAP сервером.
  # Для не AD серверов она пропускает специфичные для AD запросы.
  # Если ваш LDAP сервер не AD, установите это значение в false.
  #active_directory: true

  # Если разрешен вход через имя пользователя или электронную почту, GitLab будет игнорировать всё
  # после первого '@' в имени пользователя LDAP, введённом пользователем при входе.
  #
  # Пример:
  # - пользователь вводит '[email protected]' и 'p@ssw0rd' в качестве учетных данных LDAP;
  # - GitLab запрашивает LDAP сервер с 'jane.doe' и 'p@ssw0rd'.
  #
  # Если вы используете "uid: 'userPrincipalName'" на ActiveDirectory, вам нужно
  # отключить эту настройку, потому что userPrincipalName содержит '@'.
  allow_username_or_email_login: true

  # Чтобы поддерживать строгий контроль над числом активных пользователей в вашей установке GitLab,
  # включите эту настройку, чтобы новые пользователи были заблокированы до тех пор, пока их не освободит администратор
  # (по умолчанию: false).
  block_auto_created_users: false

  # База, где мы можем искать пользователей
  #
  #   Пример: ou=People,dc=gitlab,dc=example
  #
  base: 'dc=example'
  group_base: 'OU=groups,DC=example'

  # Фильтр LDAP пользователей
  #
  #   Формат: RFC 4515 http://tools.ietf.org/search/rfc4515
  #   Пример: (employeeType=developer)
  #
  #   Примечание: GitLab не поддерживает кастомный синтаксис фильтров omniauth-ldap.
  #
  #user_filter: ''
  user_filter: 'memberOf=cn=developers,cn=groups,cn=compat,dc=example'

# Только GitLab EE: добавьте больше LDAP серверов
# Выберите идентификатор, состоящий из a-z и 0-9. Этот идентификатор будет храниться в базе данных,
# чтобы GitLab мог запомнить, к какому LDAP серверу принадлежит пользователь.
# uswest2:
#   label:
#   host:
#   ....
EOS

ДВА (10.0.3.100): основан на Oracle 6.5, на котором установлен FreeIPA

ipa-server-install -U -r EXAMPLE -n example.com --hostname=ipa.example.com -p FreeIPAAll -a FreeIPAAll

Проблема звучит так:

Согласно документации Gitlab, это должно позволить Gitlab связать группы с LDAP сервера с группами из Gitlab. Однако это не моя цель.

Я создал группу в FreeIPA, названную ‘developer’, которая должна предоставлять доступ к входу в Gitlab. Вместо этого я могу войти с любыми пользователями, более того, я могу войти без пароля.

Таким образом, мой вопрос довольно прост: Что же я делаю не так?

Редактировать 21 сентября

Итак… Я смог частично настроить gitlab для работы. Некоторые из вещей я обнаружил сам, с некоторыми @abbra был более чем полезен.

Я смог обновить свою виртуальную машину FreeIPA с RHEL 6.5 до RHEL 7, теперь у меня FreeIPA 4.1.

Также моя настройка IPA приняла следующую форму:

ipa-server-install -U -r EXAMPLE -n example.local --hostname=ipa.example.lo -p FreeIPAAll -a FreeIPAAll

Что касается конфигурации gitlab, она стала такой (используя deb пакет, я решил использовать следующую форму, которая должна быть примерно такой же, как и выше).

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = '10.1.3.100'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'uid'
gitlab_rails['ldap_method'] = 'plain' # 'ssl' или 'plain'
gitlab_rails['ldap_bind_dn'] = 'cn=users,cn=accounts,dc=example,dc=local'
gitlab_rails['ldap_password'] = ''
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'cn=accounts,dc=example,dc=local'
gitlab_rails['ldap_group_base'] = 'cn=groups,cn=accounts,dc=example,dc=local'
#gitlab_rails['ldap_user_filter'] = '(memberOf=cn=gitlab,cn=groups,cn=accounts,dc=example,dc=local)'

Однако, если я смог сделать вход работающим, фильтрация вообще не работает, и у меня совершенно нет идей.

У кого-нибудь есть идеи, что я делаю не так?

У вас две проблемы в вашей конфигурации:

1. Вы используете слишком общие и неправильные настройки:

   base: 'dc=example'
   group_base: 'OU=groups,DC=example'
   

   Вместо этого они должны быть такими

   base: 'cn=accounts,dc=example'
   group_base: 'cn=groups,cn=accounts,DC=example'
   

2. Ваша проверка пользователей осуществляется против неправильного поддерева:

   user_filter: 'memberOf=cn=developers,cn=groups,cn=compat,dc=example'
   

   Вместо этого вам следует использовать основное поддерево:

   user_filter: 'memberOf=cn=developers,cn=groups,cn=accounts,dc=example'
   

Объяснение

FreIPA хранит пользователей и группы в контейнерах под cn=accounts,dc=example, например, cn=users,cn=accounts,dc=example для пользователей и cn=groups,cn=accounts,dc=example для групп. LDAP схема, используемая этой структурой, основана на RFC2307bis, которая позволяет использовать атрибут memberOf, указывающий на соответствующее полное имя (DN) члена объекта в LDAP.

FreeIPA также динамически экспортирует отдельное дерево (совместимое поддерево) под cn=compat,dc=example, чтобы представить тот же контент для клиентов, которые ожидают LDAP схему, определённую в RFC2307. В отличие от RFC2307bis, эта старая схема не позволяет указывать объект члена в LDAP по его полному имени. Вместо этого членство указывается с использованием значения атрибута uid объекта члена.

Когда вы делаете поиск по всему дереву, используя базу dc=example, вы получаете ответы из обоих поддеревьев. Когда вы делаете поиск с фильтром memberOf, он не даст результата, потому что оригинальное поддерево в cn=accounts,dc=example не имеет никакой ссылки на совместимое поддерево, а записи в совместимом поддереве не имеют атрибута memberOf из-за использования другой LDAP схемы.

Совместимое поддерево также возвращает свои записи перед оригинальными, поэтому GitLab путается с их результатом, когда пытается искать пользователя, так как выбирает первую возвращаемую запись, а она не содержит всех необходимых атрибутов (таких как электронная почта).

Наконец, убедитесь, что ваши запросы аутентифицированы. Это не проблема с вашей конфигурацией выше, потому что вы уже используете простую привязку, но FreeIPA 4.x ввела дополнительные ограничения на то, какие атрибуты видны для неаутентифицированных поисковых запросов, поэтому, чтобы сэкономить время другим, я упомяну это здесь тоже.

Трудно давать советы, основываясь только на текущих данных. Возможно, в вашем lab не хватает скобок, также в одном случае вы ссылаетесь на группу developer, а в другом – на developers.

Что бы я рекомендовал, так это следить за файлом /var/log/dirsrv/slapd-YOUR-REALM/access, посмотреть, какой настоящий LDAP запрос отправляется на сервер FreeIPA, каков ответ LDAP, а затем обновить конфигурацию gitlab на основе этих находок.

Поднимаю это на 2024/25 –

Минимум для интеграции LDAP из GitLab-EE с FreeIPA требует:

  gitlab_rails['ldap_enabled'] = true
# gitlab_rails['prevent_ldap_sign_in'] = false

###! **не забудьте закрыть этот блок 'EOS' ниже**
  gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
    main: # 'main' это 'provider ID' GitLab для этого LDAP сервера
      label: 'LDAP'
      host: 'IPA Server'
      port: 389
      uid: 'uid' или 'ldapuser' ?
      bind_dn: 'cn=this,cn=that,dc=example,dc=com'
      password: '_пароль_пользователя_привязки' <- ldapuser ?
      encryption: 'plain' # сначала plain, затем либо crypto
#     verify_certificates: true
#     smartcard_auth: false
#     active_directory: true
#     smartcard_ad_cert_field: 'altSecurityIdentities'
#     smartcard_ad_cert_format: null # 'issuer_and_serial_number', 'issuer_and_subject', 'principal_name'
#     allow_username_or_email_login: false
#     lowercase_usernames: false
#     block_auto_created_users: false
#     base: ''
      user_filter: 'cn=developers,DC=REALM'
#     ## EE только
#     group_base: ''
#     admin_group: ''
#     sync_ssh_keys: false
#
EOS