Need help configuring LDAP EE Trial

Hi there,

Currently I am running a trial for gitlab on-premise, the actual version is ultimate but when we will most likely end up using starter.

My problem is that the LDAP connection appears to be OK but doesn’t show any users in gitlab and they are not able to log in using their AD username/password.

I have the following added yo my gitlab.rb file:

   ### LDAP Settings
###! Docs: https://docs.gitlab.com/omnibus/settings/ldap.html
###! **Be careful not to break the indentation in the ldap_servers block. It is
###!   in yaml format and the spaces must be retained. Using tabs will not work.**

gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
##
## 'main' is the GitLab 'provider ID' of this LDAP server
##
main:
  ##
  ## 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: 'Qander AD'

  ##
  ## Example: 'ldap.mydomain.com'
  ##
  host: 'primeline.loc'

  ##
  ## This port is an example, it is sometimes different but it is always an
  ## integer and not a string.
  ##
  port: 389 # usually 636 for SSL
  uid: 'gitlab' # This should be the attribute, not the value that maps to uid.

  ##
  ## Examples: 'america\momo' or 'CN=Gitlab Git,CN=Users,DC=mydomain,DC=com'
  ##
  bind_dn: 'gitlab@primeline.loc'
  password: 'MyPasswordHere!'

  ##
  ## Encryption method. The "method" key is deprecated in favor of
  ## "encryption".
  ##
  ##   Examples: "start_tls" or "simple_tls" or "plain"
  ##
  ##   Deprecated values: "tls" was replaced with "start_tls" and "ssl" was
  ##   replaced with "simple_tls".
  ##
  ##
  encryption: 'plain'

  ##
  ## Enables SSL certificate verification if encryption method is
  ## "start_tls" or "simple_tls". Defaults to true since GitLab 10.0 for
  ## security. This may break installations upon upgrade to 10.0, that did
  ## not know their LDAP SSL certificates were not set up properly.
  ##
  verify_certificates: false

  ##
  ## Set a timeout, in seconds, for LDAP queries. This helps avoid blocking
  ## a request if the LDAP server becomes unresponsive.
  ## A value of 0 means there is no timeout.
  ##
  timeout: 10

  ##
  ## 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: false

  ##
  ## 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' or 'DC=mydomain,DC=com'
  ##
  ##
  base: 'DC=PRIMELINE,DC=loc'

  ##
  ## Filter LDAP users
  ##
  ##   Format: RFC 4515 https://tools.ietf.org/search/rfc4515
  ##   Ex. (employeeType=developer)
  ##
  ##   Note: GitLab does not support omniauth-ldap's custom filter syntax.
  ##
  ##   Example for getting only specific users:
  ##   '(&(objectclass=user)(|(samaccountname=momo)(samaccountname=toto)))'
  ##
  user_filter: '(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=Gitlab Users,OU=Groups,DC=primeline,DC=loc))'

  ##
  ## LDAP attributes that GitLab will use to create an account for the LDAP user.
  ## The specified attribute can either be the attribute name as a string (e.g. 'mail'),
  ## or an array of attribute names to try in order (e.g. ['mail', 'email']).
  ## Note that the user's LDAP login will always be the attribute specified as `uid` above.
  ##
  attributes:
    ##
    ## The username will be used in paths for the user's own projects
    ## (like `gitlab.example.com/username/project`) and when mentioning
    ## them in issues, merge request and comments (like `@username`).
    ## If the attribute specified for `username` contains an email address,
    ## the GitLab username will be the part of the email address before the '@'.
    ##
    username: ['uid', 'userid', 'sAMAccountName']
    email:    ['mail', 'email', 'userPrincipalName']

    ##
    ## If no full name could be found at the attribute specified for `name`,
    ## the full name is determined using the attributes specified for
    ## `first_name` and `last_name`.
    ##
    name:       'cn'
    first_name: 'givenName'
    last_name:  'sn'

  ##
  ## If lowercase_usernames is enabled, GitLab will lower case the username.
  ##
  lowercase_usernames: false

  ##
  ## EE only
  ##

  ## Base where we can search for groups
  ##
  ##   Ex. ou=groups,dc=gitlab,dc=example
  ##
  group_base: 'ou=groups,dc=PRIMELINE,dc=LOC'

  ## The CN of a group containing GitLab administrators
  ##
  ##   Ex. administrators
  ##
  ##   Note: Not `cn=administrators` or the full DN
  ##
  admin_group: 'Gitlab Admins'

  ## An array of CNs of groups containing users that should be considered external
  ##
  ##   Ex. ['interns', 'contractors']
  ##
  ##   Note: Not `cn=interns` or the full DN
  ##
  external_groups: []

  ##
  ## The LDAP attribute containing a user's public SSH key
  ##
  ##   Example: sshPublicKey
  ##
  sync_ssh_keys: false

EOS

When I run the following ldapsearch command

I have created the following command to check my user_filter and other contents of my config file.

ldapsearch -H ldap://primeline.loc:389 -D "[gitlab@primeline.loc](mailto:gitlab@primeline.loc)" -w MyPasswordHere -b "dc=PRIMELINE,dc=LOC" "(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=Gitlab Users,OU=Groups,DC=primeline,DC=loc))" gitlab

I am able to receive all users from the group “Gitlab Users” located in the OU Groups in domain Primeline.loc

When I do a gitlab-rake gitlab:ldap:check I get the following result

0iPgpkS1

I’m running on Centos7

qtXXftu1

What am I doing wrong?

Hi,

I can see lots of uppercase/lowercase mixed strings, I’d try using everything as opposed working within ldapsearch.

OU=Groups,DC=primeline,DC=loc

vs

group_base: 'ou=groups,dc=PRIMELINE,dc=LOC'

Also, the GitLab application debug logs likely tell why the ldap search didn’t find any groups or their members.

Did you run gitlab-ctl reconfigure after modifying the configuration?

Cheers,
Michael

Hi there,

because it’s MS AD upper- or lowercase will not influence the search I guess?!

I would check this value:
uid: 'gitlab' # This should be the attribute, not the value that maps to uid.

I propose you replace it by
uid: 'sAMAccountName'

Have a look here.

2 Likes

Hi this did the trick!
I filled in “gitlab” which is the actual value of the sAMAccountName attribute from the account I use to query LDAP.

:grinning:

It shouldn’t but the implementation is sometimes different hence the lowercase username option. That’s why I keep looking at this first when debugging LDAP/AD :slight_smile: