配置 Gitlab 使用 FreeIPA 作为 LDAP 服务器

Question

我遇到了一点麻烦，但似乎无法解决它。

请遵循以下场景：

我有两台服务器：

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 '[email protected]' 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 中创建了一个名为“developer”的组，该组应授予 Gitlab 登录权限。相反，我可以使用任何用户登录，而且我可以不使用密码登录。

所以，我的问题很简单：我到底做错了什么？

编辑 9 月 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)'

然而，如果我设法使登录正常工作，则过滤根本不起作用，而且我完全没有线索了。

谁知道我做错了什么？

Answer 1

您的配置有两个问题：

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指向 LDAP 中成员对象的正确的可分辨名称 (DN) 的属性。

FreeIPA 还动态导出单独的树（兼容子树），以便为需要 RFC2307 中定义的 LDAP 模式的客户端提供相同的内容。与 RFC2307bis 不同，此旧模式不允许通过其可分辨名称在 LDAP 中指定成员对象。相反，成员资格是通过使用成员对象的cn=compat,dc=example属性值来指定的。uid

当您使用 base 搜索整个树时dc=example，您会从两个子树获得响应。当您使用memberOffilter 搜索时，它将得到一个空结果，因为原始子树没有对 compat 子树的任何引用，并且 compat 子树中的条目由于使用了不同的 LDAP 架构而cn=accounts,dc=example没有属性。memberOf

兼容子树也在原始条目之前返回其条目，因此当 GitLab 尝试搜索用户时，它会对其结果感到困惑，因为它选择了第一个返回的条目，并且它不包含所有需要的属性（例如电子邮件）。

最后，确保您的请求已通过身份验证。这不是您上面的配置的问题，因为您已经在使用简单绑定，但 FreeIPA 4.x 对未经身份验证的搜索请求可见的属性设置了额外的限制，因此为了节省其他人的时间，我也会在这里提到这一点。

Answer 2

仅根据当前数据很难给出建议。您的实验室可能缺少括号，而且在一种情况下您提到developer组，developers在另一种情况下您提到。

我建议查看尾部/var/log/dirsrv/slapd-YOUR-REALM/access文件，查看发送到 FreeIPA LDAP 服务器的真实 LDAP 查询是什么，LDAP 答案是什么，然后根据这些发现更新 gitlab 配置。