Add new comment

Never boring: Gitlab, AD, and LDAP in general

While making our internal network services ready to scale once they need, I recently added most internal services (e. g. Mediawiki, bug trackers, and whatever there is to add to a centrally admin’d SSO domain). Not too surprisingly, there are several caveats, most of which need no mention here (Google to the rescue, as most times). However, the most horrifying piece of work was integrating Gitlab, not just a free, but a great software (in almost any other aspect). Not even that the guys there were to blame; they are rather quite good in responding even if you are not (yet) a subscribed support user. The gap is just between several systems, as always, and hopefully my findings fill it for at least some others.

Actual issue:

However: After having installed Gitlab CE (MR 7, „omnibus“), I searched, found and followed some recipes on the basic LDAP steps. Aside others, most helpful was one which points out the importance of proper bind and base DNs, which actually is the key, in the end.

How to find gitlab.yml in the omnibus package

Simple: Not at all. Despite most available documentation, the config file used in „omnibus“ packages is /etc/gitlab/gitlab.rb. And it is not a YAML file, but a ruby configuration, as the filename suggests. You will succed to manage it anyway, I suppose.

What followed, was less pleasant, took a couple of hours and some browser tabs. Regardless of which suggested DN string (NTDOMAIN\user, cn=user,dc=domain[,dc=tld], uid=user,dc=…, …) I tried, unless I changed settings related to the connection itself, I got stuck with the somehow notorious LDAP error 49, data code 52e, translating to „invalid credentials provided“ (indicating that AD was reachable and responding).

Valid credential is (in)valid

You may want to suggest I tried to verify just the rejected credentials, of course I did, by logging into other services, on to Windows workstations or VMs, all working fine. So, it wouldn’t be long until I came to debugging ldapsearch (on a different machine, I must add), which wouldn’t work either - first with the same error (49), just so from second thru 9000, then (after having Kerberos installed) stubbornly refusing any search result (no objects). Long story short, this wasn’t it either.

What worked here: Mind permissions and OUs!

Finally having Gitlab authenticate with our SBS (which actually is a W2008R2 bundle) mainly took two steps.

1. Properly permit your bind user

This key insight came from Dinesh’s very helpful post on MS AD LDAP security details. In your Active Directory Users and Computers, first climb up the OU tree up to the parent container of all users or groups you want to have in Gitlab (or create one and link these users there). Then, enable View > Advanced features. This will bring up further property tabs if you now open the OU’s properties, go to the Security tab and make sure your bind user has read permission for this OU and all descending objects.
This step may not be necessary in all cases, from what I’ve read there has been a paradigm change at some time having rendered MS removing default read permissions for normal users. In our case, we had to.

2. Mind DNs!


As the post linked above states: Highly important. And also easy. In the AD users console, still open with advanced features as of step 1, open your actual bind user’s properties and navigate to the Attributes (editor) tab. Find the entry for distinguished name, open it, copy the value and just paste it into the Gitlab LDAP config for bind_dn (you still need to provide the bind user’s password). Then, take your favorite OU from step 1, and do just the same, this time for the base_dn value. Reload your gitlab configuration, log in and there you go. Or, actually, at least I did. :-)