Ldap – Configure Gitlab to use FreeIPA as LDAP server

freeipagitlabldap

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?

Best Answer

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.

Related Solutions

Linux – cannot add ldap group to system local user

I have searched for the answer to the same question (as you can see).

My conclusion is that you cannot assign an LDAP group to a user that exists locally only.

These are two worlds: - either the user (and its groups) are local - or they are not, i.e. all is stored in the directory.

For example: what would happen if the user already has a primary group that is local, and you'd try to add a secondary group to that user? Usually, that would be stored in /etc/group, but in this case it would have to modify the directory which it probably can't.

So I guess that's a no-go.

GitLab & OpenLDAP: Invalid credentials

First of all, you shall probably change the configuration for allow_username_or_email_login to true.

Then you probably want to create a group gitlabusers holding the users you wish to grant access to the server and modify the user_filter to '(memberOf=cn=gitlabusers,ou=groups,dc=courseproject,dc=org)'

Then apply the changes using gitlab-ctl reconfigure and check the LDAP configuration using

   gitlab-rake gitlab:ldap:check RAILS_ENV=production

Unless this command succeed to give you the list of users you expect, you have a mistake in your configuration...

For info, my below configuration (against a FreeIPA server) works:

 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: 'IPA'
     host: 'ipa.mydomain.com'
     port: 389
     uid: 'uid'
     method: 'tls' # "tls" or "ssl" or "plain"
     bind_dn: 'uid=gitlab,cn=sysaccounts,cn=etc,dc=mydomain,dc=com'
     password: '<password>'
     active_directory: false
     allow_username_or_email_login: true
     #block_auto_created_users: false
     base: 'cn=users,cn=accounts,dc=mydomain,dc=com'
     user_filter: '(memberOf=cn=gitlabusers,cn=groups,cn=accounts,dc=mydomain,dc=com)'
     ## EE only
     group_base: 'cn=groups,cn=accounts,dc=mydomain,dc=com'
     #admin_group: ''
     #sync_ssh_keys: true
 EOS

Best Answer

Explanation

Related Solutions

Linux – cannot add ldap group to system local user

GitLab & OpenLDAP: Invalid credentials

Related Topic