Configure Gitlab to use FreeIPA as LDAP server

Question

I'm running in ran into a bit of a trouble and I don't seem to be able to fix it.

Please follow the scenario bellow:

I have two servers:

ONE (10.0.3.10): Ubuntu based, having Gitlab (as deb package) installed with the following configuration

/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 based, having FreeIPA installed

ipa-server-install -U -r EXAMPLE -n example.com --hostname=ipa.example.com -p FreeIPAAll -a FreeIPAAll

Problem sounds like this:

According to Gitlab Documentation this should allow Gitlab to let me associate groups from the LDAP server to groups from Gitlab. However, this is not my goal.

I have created a group within FreeIPA, named 'developer' which should be the one giving access to Gitlab login. In stead, I can login with any users, further more I can login without password.

So, my question is pretty simple: What on earth am I doing wrong ?

Edit Sept. 21st

So... I've managed to partial configure gitlab to work. Some of the things I've discovered my self, with some @abbra was more than helpful.

I managed to update my FreeIPA VM from RHEL 6.5 to RHEL 7, now having FreeIPA 4.1.

Also my IPA setup took the following form:

ipa-server-install -U -r EXAMPLE -n example.local --hostname=ipa.example.lo -p FreeIPAAll -a FreeIPAAll

As for gitlab config, it became like this (using the deb package, I decided to use the following form, which should be about he same with the form above).

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)'

However, if I managed to make the login work, filtering doesn't work at all and I'm totally out of clues.

Anyone has any idea what am I doing wrong?

score 4 · Answer 1 · answered Sep 18 '15 at 13:25

You have two problems in your configuration:

You are using too generic and incorrect settings:

base: 'dc=example'
group_base: 'OU=groups,DC=example'

Instead, they should be

base: 'cn=accounts,dc=example'
group_base: 'cn=groups,cn=accounts,DC=example'

Your check for users is done against wrong subtree:

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

Instead, you should use main subtree:

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

Explanation

FreIPA stores users and groups in the containers under cn=accounts,dc=example, e.g. cn=users,cn=accounts,dc=example for users and cn=groups,cn=accounts,dc=example for groups.The LDAP schema used by this structure is based on RFC2307bis which allows using memberOf attribute pointing to the proper distinguished name (DN) of a member object in LDAP.

FreeIPA also dynamically exports a separate tree (compat subtree) under cn=compat,dc=example to present the same content for clients that expect an LDAP schema defined in RFC2307. Unlike RFC2307bis, this older schema does not allow to specify a member object in LDAP by its distinguished name. Instead, a membership is specified by using a value of an attribute uid of the member object.

When you do search against whole tree using base dc=example, you get responses from the both subtrees. When you do search with memberOf filter, it will come with an empty result because the original subtree in cn=accounts,dc=example does not have any reference to the compat subtree, and entries in the compat subtree don't have memberOf attribute due to use of a different LDAP schema.

The compat subtree is also returning its entries before the original ones, so GitLab is confused by their result when trying to search a user as it selects a first returned entry and it doesn't contain all needed attributes (like email).

Finally, make sure your requests are authenticated. This is not a problem wiht your configuration above because you are using a simple bind already but FreeIPA 4.x has put additional limitations on what attributes are visible to unauthenticated search requests, so to save others' time I'd mention it here as well.

Hello @abbra, I owe you a great debt for explaining this to me. I am barely learning this new things. I need a bit more help please. It seems that user filter does not want to work. Think you could assist me a little more please? — Dragos Cirjan, Sep 21 '15 at 09:32
You need to show logs from `/var/log/dirsrv/slapd-EXAMPLE/access` that correspond to your connection from gitlab host (under gitlab credentials) to see what it is doing and if it does it wrong. — abbra, Sep 22 '15 at 06:14
I think this happens because I do not have an account bind to gitlab. Available information about LDAP account is pretty limited unless you also provide a binded account (not just a group). Same thing happens to me on my redmine setup (I cannot use the filter option). Seems I have to read a bit more about binding an account (i.e. http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDAP_Group_memberships). I will return once I've learned a bit more about this. — Dragos Cirjan, Sep 24 '15 at 12:14
Yes, as I wrote in the last sentence in my answer, you have to have authenticated binds. — abbra, Sep 25 '15 at 05:29

score 1 · Answer 2 · answered Sep 17 '15 at 12:50

It is difficult to advise based just on current data. It may be parentheses missing in your lab, also in one case you refer to developer group and to developers in the other.

What I would recommend is to tail /var/log/dirsrv/slapd-YOUR-REALM/access file, see what is the real LDAP query being sent to the FreeIPA LDAP server, what is the LDAP answer and then update gitlab configuration based on these findings.

Configure Gitlab to use FreeIPA as LDAP server

2 Answers2

Explanation