Я вбегаю, столкнулся с небольшой проблемой, и, похоже, я не могу ее исправить.
Пожалуйста, следуйте приведенному ниже сценарию:
У меня два сервера:
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)'
тем не мение, если мне удалось заставить вход в систему работать, фильтрация вообще не работает, и у меня нет никаких подсказок.
Кто-нибудь знает, что я делаю не так?
В вашей конфигурации есть две проблемы:
Вы используете слишком общие и неправильные настройки:
base: 'dc=example' group_base: 'OU=groups,DC=example'
Вместо этого они должны быть
base: 'cn=accounts,dc=example' group_base: 'cn=groups,cn=accounts,DC=example'
Ваша проверка для пользователей выполняется против неправильного поддерева:
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 на основе этих результатов.