How to determine the values for an LDAP bind to a Windows Server 2012 DC? [Gitlab Omnibus 7.0.0; ldap_bind: Invalid Credentials (49)]

Question

EDIT: This question has gotten a lot of views, and I never really came back and provided a precise, step-by-step solution. So I came back 18 months later and did that. This solution works for simple binds, and the original question is posed in the context of trying to get a Gitlab Omnibus installation to bind to the LDAP server, but it should work in the case of any simple LDAP bind. See my accepted answer for the exact steps I did to produce a solution. Here are my Gitlab version details (for those who have this problem with Gitlab):

• GitLab 7.0.0

• GitLab Shell 1.9.6

• GitLab API v3

• Ruby 2.1.1p76

• Rails 4.1.1

Original Post: I have been trying for nearly 6 hours to get my Gitlab deployment to authenticate via Windows Server 2012 Essentials Active Directory LDAP.

I am running Ubuntu 14.04 for my Gitlab server. It's already connected to the domain controller via SSSD.

Gitlab itself uses LDAP settings from in the gitlab.rd configuration file like follows:

# These settings are documented in more detail at
# https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/gitlab.yml.example#L118
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = 'hostname of LDAP server'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'sAMAccountName'
gitlab_rails['ldap_method'] = 'plain' # 'ssl' or 'plain'
gitlab_rails['ldap_bind_dn'] = 'CN=query user,CN=Users,DC=mycorp,DC=com'
gitlab_rails['ldap_password'] = 'query user password'
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'DC=mycorp,DC=com'

I am able to query the server, but no matter what settings I choose, I ALWAYS get the same message:

"Invalid Credentials"

I have tried to manually query the DC using ldapsearch and the same error message:

"ldap_bind: invalid credentials (49)

I already created the user I am using to bind on the Active Directory Users section in my Windows Server 2012 Server Manager.

I have tried every single combination of OU=Users, and CN=Users and other users, made sure that all the email address fields for all users in the AD are populated, but I cannot get a single proper response.

Isn't there an easy way to return all the Bind_dn and Base information for an Active Directory object? This is getting very frustrating.

No matter where I look on the internet, all the information pertains to old versions of Windows (ldapsearch, etc...). I am very new at this Systems stuff (this is at my very first summer internship job).

Here is an example of the current settings I am using:

gitlab_rails['ldap_bind_dn'] = 'CN=Gitlab LDAP,OU=Users,DC=servername,DC=local'
gitlab_rails['ldap_base'] = 'OU=Users,DC=servername,DC=local'

And a corresponding example of how I've been trying to use ldapsearch to find the proper bind settings for my Windows AD DS:

ldapsearch -b "ou=Users,dc=servername,dc=local" -h 192.168.0.3 -p 389 -D "uid=Gitlab LDAP,ou=Users,dc=servername,dc=local" -w "<password>"

To no avail. I've tried dozens of combinations. The user "gitlab" has a display name of "Gitlab LDAP" in the Windows Server, with an email, all in lower-case. Bottom line: Is there some easy way to click on object in the Windows DC and retrieve the correct LDAP settings to use that user object for ldap binds?! If I were prone to emotional outbursts, this is where I would do it.

Always the same error message: "Invalid Credentials"

Thank you for your time and consideration, any and all help will be greatly appreciated.

Solution 1

NOTE: Alligator (<>) braces are to be removed from values, and are only there to indicate generic values.

1. Create a User on the DC to use for LDAP binding. Here is an example for my context:

   I don't think I changed anything really, but I did, under the Account tab, set it so that the User cannot change password and the Password never expires. Note I redacted the URL from the end of the domain on the user email. For the rest of these instructions, I am going to use <Domain>.<local>, but this URL can be anything corresponding to your DC's actual FQDN (e.g. microsoft.com).

2. On the DC itself (preferably) or on a network connected and authorized machine, run LDP.exe with elevated privileges. Under Connection enter the FQDN for the DC or localhost (depending on where you are connecting from), at port 389 (or whichever port you have it forwarded to, 389 is the default LDAP port). Once connected you should see many lines, but one of the first lines will be:

   configurationNamingContext: CN=Configuration,DC=<Domain>,DC=<local>

   Take note of these values (the DC values correspond to your FQDN and will be used in LDAP Search later).

3. Once connected, we will perform a simple bind with that user. Click the Connection tab and select the bind option. Fill in the options as such (using the user info you created in the first step):

   

   If successful, you should get a message Authenticated as: <Domain>\<username>

4. Once bind is successful to the DC with ldp.exe, under the Browse tab click the Search option:

   

   In the Base DN field you will copy the exact DC URL values noted when you connected to the server. So if the connection showed CN=Configuration,DC=microsoft,DC=com; then you would put dc=microsoft,dc=com in the Base DN field.

   The filter I used is just a wildcard search on my username that I created previously. In the attributes field, I used the following values:

   objectClass;name;description;canonicalName;lDAPDisplayName

5. Click Run to execute your search. The following output is produced:

   

   This line marked RED are the values I used to bind in my gitlab.rb config as such (note that this file has been changed/redacted to reflect the example here). This worked perfectly when I logged into Gitlab:

   

   Those are the steps I took. I'm pretty sure those with more admin muscle than I could probably modify this approach to find out whatever they want. (Special thanks to Nitz for pointing me in the right direction).

Lastly: Depending on which version of windows you are using, your client might use SAMAccountName or the UserPrincipleName attribute, as mentioned by Ryan Bolger in the comments of the other answer by Nitz. More information on this attribute can be found here.

Solution 2

I know this isn't a complete answer, but I can't comment because of reputation.
Some points to consider:

• From the DC itself, launch ldp.exe. It's an actual LDAP client, so if you manage to configure it to work correctly, chances are the same parameters will work for Gitlab.
  See this for basic ldp guidance, and make sure you read LDP's output. It may reveal some more information needed for your configuration.
• When it comes to LDAP access, the version of Windows Server doesn't matter that much - maybe only on encryption-related issues.
  
• ldap_uid may expect the form DOMAIN\UserName or CN=UserCN,DN=Location,DC=Bla (DistinguishedName).
• Consider checking the windows event logs for the DC you're trying to connect to. It may have some information about why the connection failed. Try "failed audits" in the "security" log

Post back with additional info, and maybe I can help!

Comments

[Aubrey Robertson]

Sorry it took so long for me to get back and check this as the answer. LDP.exe was the ticket. I banged my head against this wall several hours and with LDP.exe I was able to quickly try many permutations of possible values. Along with some documentation and powerful access to LDAP protocols, I was able to determine the correct LDAP Bind settings (Domain Organizational Units). I can post my Gitlab config if anyone wants.

[Ryan Bolger]

For future reference when doing LDAP against Active Directory, you don't actually have to use a DN formatted value as the bind username. It's actually a better idea to use the userPrincipalName (UPN) attribute on the account because the DN is subject to change if the account moves to a different OU. But UPN stays the same regardless of its location.

[Ryan Bolger]

My comment about the UPN was for the value of ldap-bind-dn instead of using the actual DN value. DNs in AD are fragile because they can change based on the name/location of all parent containers in the path. But UPNs generally never change unless the domain is renamed.

[Ryan Bolger]

As a separate topic, you can also choose to use userPrincipalName instead of sAMAccountName for the value of ldap-uid which can be useful if your Gitlab is running against multiple different LDAP directories. It forces users to qualify which domain their username belongs to so you don't run into problems where you have multiple users with the same username in different domains.

[Noir]

If someone still has trouble check this out: serverfault.com/questions/707770/…