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

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

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

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

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

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

/etc/gitlab/gitlab.rb

# The URL through which GitLab will be accessed.
external_url "https://gitlab.example.com/"

# Whether to redirect http to 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"

# The directory where Git repositories will be stored.
git_data_dir "/var/opt/gitlab/git-data"


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
  #
  # A human-friendly name for your LDAP server. It is OK to change the label later,
  # for instance if you find out it is too large to fit on the web page.
  #
  # Example: 'Paris' or 'Acme, Ltd.'
  label: 'LDAP'

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

  # This setting specifies if LDAP server is Active Directory LDAP server.
  # For non AD servers it skips the AD specific queries.
  # If your LDAP server is not AD, set this to false.
  #active_directory: true

  # If allow_username_or_email_login is enabled, GitLab will ignore everything
  # after the first '@' in the LDAP username submitted by the user on login.
  #
  # Example:
  # - the user enters 'jane.doe@example.com' and 'p@ssw0rd' as LDAP credentials;
  # - GitLab queries the LDAP server with 'jane.doe' and 'p@ssw0rd'.
  #
  # If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
  # disable this setting, because the userPrincipalName contains an '@'.
  allow_username_or_email_login: true

  # To maintain tight control over the number of active users on your GitLab installation,
  # enable this setting to keep new users blocked until they have been cleared by the admin
  # (default: false).
  block_auto_created_users: false

  # Base where we can search for users
  #
  #   Ex. ou=People,dc=gitlab,dc=example
  #
  base: 'dc=example'
  group_base: 'OU=groups,DC=example'

  # Filter LDAP users
  #
  #   Format: RFC 4515 http://tools.ietf.org/search/rfc4515
  #   Ex. (employeeType=developer)
  #
  #   Note: GitLab does not support omniauth-ldap's custom filter syntax.
  #
  #user_filter: ''
  user_filter: 'memberOf=cn=developers,cn=groups,cn=compat,dc=example'

# GitLab EE only: add more LDAP servers
# Choose an ID made of a-z and 0-9 . This ID will be stored in the database
# so that GitLab can remember which LDAP server a user belongs to.
# uswest2:
#   label:
#   host:
#   ....
EOS

TWO (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 под названием «разработчик», которая должна предоставлять доступ к входу в 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' or '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.

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

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

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

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