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

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

Следуйте за ревом сценария:

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

ОДИН (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

ДВА (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 VM от 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)'

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

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

2
задан 21 September 2015 в 12:29
2 ответа

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

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

    base: "dc=пример
    Group_base: 'OU=группы, DC=пример'.
    

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

     базовыми: "cn=счета, dc=пример".
    Group_base: 'cn=группы,cn=счета,DC=пример'.
    
  2. Ваша проверка пользователей осуществляется против неправильного subtree:

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

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

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

Пояснение

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

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

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

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

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

.
3
ответ дан 3 December 2019 в 10:01

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

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

.
1
ответ дан 3 December 2019 в 10:01

Теги

Похожие вопросы