我遇到了一些麻烦，我似乎无法解决这个问题。
请按照以下scheme：
我有两台服务器：
ONE（10.0.3.10）：基于Ubuntu，具有以下configuration安装的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 az 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中创build了一个名为'developer'的组，它应该是能够访问Gitlablogin的组。 相反，我可以与任何用户login，进一步我可以login没有密码。
所以，我的问题很简单：我究竟做错了什么？
9月21日编辑
所以…我设法部分configurationgitlab工作。 我发现自己的一些东西，用一些@abbra来帮助我。
我设法将我的FreeIPA VM从RHEL 6.5更新到RHEL 7，现在有了FreeIPA 4.1。
另外我的IPA设置采取了以下forms：
ipa-server-install -U -r EXAMPLE -n example.local --hostname=ipa.example.lo -p FreeIPAAll -a FreeIPAAll
至于gitlabconfiguration，它变成这样（使用deb包，我决定使用下面的forms，这应该是与上面的表格大致相同）。
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)'
但是 ，如果我设法使login工作，过滤不起作用，我完全没有线索。
任何人有任何想法我做错了什么？
你的configuration有两个问题：
您正在使用过于一般和不正确的设置：
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=users,cn=accounts,dc=example和cn=groups,cn=accounts,dc=example cn=users,cn=accounts,dc=example下的容器中。通过此结构基于RFC2307bis，它允许使用memberOf属性指向LDAP中成员对象的正确的可分辨名称（DN）。
FreeIPA还dynamic地在cn=compat,dc=example下导出一个单独的树（compat子树） cn=compat,dc=example以便为需要在RFC2307中定义的LDAP模式的客户端呈现相同的内容。 与RFC2307bis不同，这个较旧的模式不允许通过其专有名称在LDAP中指定成员对象。 相反，通过使用成员对象的属性uid的值来指定成员资格。
当你使用base dc=example对整个树进行search时，你会从这两个子树得到响应。 当使用memberOf筛选进行search时，由于cn=accounts,dc=example中的原始子树没有任何对compat子树的引用，并且compat子树中的条目没有到期的memberOf属性使用不同的LDAP模式。
compat子树也在原来的条目之前返回它的条目，所以当试图search用户时，GitLab会被他们的结果所困惑，因为它select了第一个返回的条目，而且它不包含所有必需的属性（如电子邮件）。
最后，确保您的请求已通过身份validation。 这不是你上面configuration的问题，因为你已经使用了一个简单的绑定，但FreeIPA 4.x已经对未经身份validation的search请求可见的属性加上了额外的限制，所以为了节省其他人的时间，我也会在这里提到它。
仅基于当前的数据很难提供build议。 在实验室中可能会缺less括号，在一个案例中，您是指developer小组，另一个是developers 。
我推荐的是tail /var/log/dirsrv/slapd-YOUR-REALM/access文件，查看发送到FreeIPA LDAP服务器的真正的LDAP查询是什么，LDAP的答案是什么，然后更新gitlabconfiguration这些发现。