Access denied for your LDAP account

I just tested on a fresh install... No issues. I am going to clone my Production 6.6 environment and test the upgrade and see how it pans out.

Could you post your LDAP section of gitlab.yml? (Sanitized, of course)

Update: Upgraded the production clone successfully. I would make sure you restart nginx and gitlab after you run the upgrade script. I saw a few issues before doing that, but LDAP seems to work fine through a regular browser and also from my phone.

Status changed to closed

Status changed to reopened

Ok here it is:

  ldap:
    enabled: true
    host: '127.0.0.1'
    base: 'ou=users,dc=crowd'
    port: 10389
    uid: 'uid'
    method: 'plain' # "ssl" or "plain"
    bind_dn: 'uid=bind_user,ou=users,dc=crowd'
    password: 'PASSWORD'
    allow_username_or_email_login: true

What is that, OpenLDAP or 389? All looks well, did you try maybe swapping out 127.0.0.1 for localhost instead? Double check and make sure your bind_user password hasn't expired either.

Its OpenLDAP. the password hasn't expired, and no i did not try swapping out the host. I figured that wasn't the problem because gitlab connected to it and could tell an invalid password or not because the error message displayed changed.

Well, some changes were definitely made to the LDAP code in 6-7-stable. It looks like LDAP user filters were added. However, the ldap_security_check method your login is hanging on is located here. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/application_controller.rb#L183

I assume you already have, but log in locally and make sure the LDAP accounts are granted access.

I'll have to double check later as I downgraded because I needed critical access during the day. My guess as well is that it has to do with the user filter addition.

We have troubles with ldap too since 6.7. The reason here is the new (but bad) username determination in lib/gitlab/ldap/user.rb:89. We don't have any nicknames set in our ldap (and no samaccountname), so the authentication failes since the update.

Not sure if that's the same problem as Daniel has, but maybe it helps. However if that's not the same, please tell me so I'll open a new issue for "my" problem.

Yes, I agree. Looks to be locked to either nickname or samaccountname. I would bet that this is the same issue that Daniel is experiencing. We're running samaccountname here no issues.

Looks like that may be it. My LDAP solution is an intermediary between Atlasssian CROWD and it looks like it is not broadcasting samaccountname.

Confirmed: Commenting out the 'username' override in lib/gitlab/ldap/user.rb:88 (and therefore falling back to the version in lib/gitlab/oauth/user.rb:60) fixes LDAP authentication for our setup too. For reference, we use email addresses as the 'uid' field (e.g. uid=firstname.lastname@domain.tld,ou=People,o=domain.tld), with no samAccountName or nickname fields in the LDAP tree.

Yeah, the username instance method seems to be the culprit. Tomorrow I'll try testing that out if I have time and make a merge request.

Daniel, if you want to give this a shot, I made a branch for you to try. I just tested it and it seems OK here, but mine worked the whole time. See if it resolves your issue.

pull down the 'LDAP_FIX' branch from https://gitlab.com/bdwyertech/gitlab-ce.git

Ok. Will do later tonight! thanks!

Nope that was a no go still got the access denied for your ldap account. Unless there was another parameter added that my ldap is not using.

Hi Daniel, I had the same issue recently upgrading to 6.7. I noticed you have the option "base" in your list above. I removed that line because in 6.7 it is used later in the file. Right before the "Filter LDAP users" section, there is a parameter to enter the base in there to search. Your specific issue may be different, but I would double check that. My LDAP authentication started working after I made that change and restarted services.

Bryan still a no go.

I'm also receiving the same errors.

Is there any update on this? If it helps I am using this as my LDAP server https://github.com/dwimberger/crowd-ldap-server It looks like sAMAccountName is a microsoft active directory/samba attribute only.

Anybody have any other ideas?

I'm at a loss.. I added the sAMAccountName attribute and it still gives me the same error. I setup a virtual machine from bitnami with all the defaults except my ldap config

LDAP User

     dn[]: dn=daniel_brooks,ou=users,dc=crowd
    objectClass: organizationalPerson
    objectClass: person
    objectClass: inetOrgPerson
    objectClass: top
    uid: daniel_brooks
    sn: Brooks
    mail: daniel_brooks@email.com
    givenname: Daniel
    ou: users
    cn: Daniel Brooks
    sAMAccountName: daniel_brooks
    memberof: cn=confluence-administrators,ou=groups,dc=crowd
    memberof: cn=confluence-users,ou=groups,dc=crowd
    memberof: cn=crowd-administrators,ou=groups,dc=crowd
    memberof: cn=dabsquared-admins,ou=groups,dc=crowd
    memberof: cn=dabsquared-users,ou=groups,dc=crowd
    memberof: cn=gitlab-users,ou=groups,dc=crowd
    memberof: cn=google-apps,ou=groups,dc=crowd
    memberof: cn=graylog-users,ou=groups,dc=crowd
    memberof: cn=jenkins-users,ou=groups,dc=crowd
    memberof: cn=jira-administrators,ou=groups,dc=crowd
    memberof: cn=jira-users,ou=groups,dc=crowd
    memberof: cn=klinche-admins,ou=groups,dc=crowd
    memberof: cn=klinche-users,ou=groups,dc=crowd
    memberof: cn=spark-admins,ou=groups,dc=crowd
    memberof: cn=spark-users,ou=groups,dc=crowd
    memberof: cn=tronix-users,ou=groups,dc=crowd

And My config:

## LDAP settings
  # You can inspect a sample of the LDAP users with login access by running:
  #   bundle exec rake gitlab:ldap:check RAILS_ENV=production
  ldap:
    enabled: true
    host: 192.168.2.64
    port: 10389
    uid: 'uid'
    method: 'plain' # "tls" or "ssl" or "plain"
    bind_dn: 'uid=bind_user,ou=users,dc=crowd'
    password: 'password'
    # 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

    # Base where we can search for users
    #
    #   Ex. ou=People,dc=gitlab,dc=example
    #
    base: 'ou=users,dc=crowd'

    # Filter LDAP users
    #
    #   Format: RFC 4515
    #   Ex. (employeeType=developer)
    #
    user_filter: ''

Am I missing something at all or am I still the only one getting this?

Ok even weird is that the ldap check command lists all the users and when I login as a standard user after trying a new ldap user, I can see that the ldap user got populated and is in the database. No access is blocked for them either. Anyone have any clue?

And here's the log file showing it creating the user

# Logfile created on 2014-04-22 03:03:05 +0000 by logger.rb/31641
April 22, 2014 03:03: User "Daniel Brooks" (daniel_brooks@email.com) was created
April 22, 2014 03:03: (OAuth) Creating user daniel_brooks@email.com from login with extern_uid => dn=daniel_brooks,ou=users,dc=crowd

Also this is now on 6.8 with the same issue.

Does anyone have any updates on this?

We have a very fresh install. Not being able to log-in with LDAP account.

Daniel,

I have commented out lines 191:193 in file embedded/service/gitlab-rails/app/controllers/application_controller.rb

 #sign_out current_user
 #flash[:alert] = "Access denied for your LDAP account."
 #redirect_to new_user_session_path

Can you test it for me?

@davidhrbac actually I cannot anymore as I have switched to an omniauth implementation.

Can you share your solution? Since it seems that commenting out is not enough. Command line push, clone do not work anymore when LDAP is enabled. It seems to me, that LDAP is not working in GitLab.

@davidhrbac I actually don't have a solution, I'm just lucky enough to have an alternative auth method.

@bass_rock I mean, can you share your alternative auth configuration? Thanks.

@davidhrbac I am using Atlassian Crowd as my auth source so I just installed the omniauth plugin for that.

@bass_rock Well, thanks. Will have to dive again into the source code. Seems to me that LDAP is broken in GitLab.

I have the exact same problem. I traced the problem to lib/gitlab/ldap/person.rb where the active_directory_disabled? function uses an Active Directory-specific filter to omit "disabled" users. Returning false from this function bypasses the problem for now. IMO, such provider-specific code should never have been added to the core; this is exactly what the filter parameter should be used for

I also have the exact same problem. I use the omnibus package of Gitlab CE 7.3.2 f092e53e.

What I'm expecting : configure gitlab.rb correctly to allow users to connect via LDAP.

What I get : When a user try to log in, he gets a "Denied Access" message.

The following extracts are all sanitized.

I configured the /etc/gitlab/gitlab.rb file as follow :

# Change the external_url to the address your users will type in their browser
external_url 'http://my.external.url/' #This URL is a DNS redirect to my public IP.

#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'] = '[the.ldap.server]'
gitlab_rails['ldap_port'] = 636
gitlab_rails['ldap_uid'] = 'uid'
gitlab_rails['ldap_method'] = 'ssl' # 'ssl' or 'plain'
gitlab_rails['ldap_bind_dn'] = '[my bind dn]'
gitlab_rails['ldap_password'] = '[bind dn password]'
gitlab_rails['ldap_allow_username_or_email_login'] = false
gitlab_rails['ldap_base'] = '[the branch to look up]'

I don't use a user filter field because I want all user in the base to be able to log in. My bind dn has all necessary rights.

Then I run

gitlab-ctl reconfigure

This is the ldap section of my /var/opt/gitlab/gitlab-rails/etc/gitlab.yml file without GitLab's comments after reconfiguring :

  ldap:
    enabled: true
    host: '[server]'
    port: 636
    uid: 'uid'
    method: 'ssl' # "tls" or "ssl" or "plain"
    bind_dn: '[my bind dn]'
    password: '[bind dn password]'

    sync_time: 
    allow_username_or_email_login: false
    base: '[base to search in]'
    user_filter: 
    group_base: 
    admin_group: 
    sync_ssh_keys:

Hereafter my production.log (from GitLab's admin interface) after the unsuccessful LDAP log in attempt :

Started GET "/users/sign_in" for XXX.XXX.XXX.XXX at 2014-10-18 16:46:57 +0200
Processing by SessionsController#new as HTML
Completed 200 OK in 12ms (Views: 3.8ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for XXX.XXX.XXX.XXX at 2014-10-18 16:46:58 +0200
Processing by OmniauthCallbacksController#ldap as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"theAuthenticityToken=", "username"=>"[myUsername]", "password"=>"[FILTERED]"}
Redirected to http://my.external.url/users/sign_in
Completed 302 Found in 45ms (ActiveRecord: 0.9ms)

And the content of my /var/log/gitlab/unicorn/unicorn_stdout.log :

I, [2014-10-18T16:46:58.742636 #9641]  INFO -- omniauth: (ldap) Callback phase initiated.

When I...

gitlab-rake gitlab:ldap:check RAILS_ENV=production

... I see the an extract of 100 users "allowed to log in". And these users are effectively those I'm expecting.

I tried Oliver's solution and modified function in /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ldap/person.rb as follow :

def self.disabled_via_active_directory?(dn, adapter=nil)
  return false
  adapter ||= Gitlab::LDAP::Adapter.new
  adapter.dn_matches_filter?(dn, AD_USER_DISABLED)
end

...but didn't work.

When I try to log in GitLab's web interface with the bind dn user I use in gitlab.rb file, I'm able to do so. All other users get the "Acess Denied" message, even if they are listed with the check command. I do not understand why GitLab deny access althought they are found in the LDAP directory (if not, I would have an "Invalid Credentials" message).

I do not connect an Active Directory, so (uid='uid') in gitlab.rb.

I use a DNS redirect to a public static IP serving my GitLab install to have a friendly FQDN.

This is my "uname -a" on a ubuntu server 14.04 fresh install : Linux ubuntu 3.13.0-37-generic #64 (closed)-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Does somebody have a clue on this issue ? I would be obliged...

Qoya

EDIT: after a dive in the code I found a very ugly but working solution. Edit the 'allowed?' function in /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ldap/person.rb:

def allowed?(user)
   if Gitlab::LDAP::Person.find_by_dn(user.extern_uid, adapter)
      !Gitlab::LDAP::Person.disabled_via_active_directory?(user.extern_uid, adapter)
   else
      true #Originally set to false
   end
   rescue
      false
end

I'm not so into ruby but if I understand correctly the ruby files in this ldap folder, the connection is authorized only if the user trying to log in is the DN of the user used in the config file /etc/gitlab/gitlab.rb. If not, gitlab just creates a new user.

Unfortunately, I have the same problem with a clean install of 7.4.2 and none of the fixes mentioned here works for me. I have LDAP working fine with ownCloud, DokuWiki and Redmine. But it has been two days that I'm scratching my head and it won't work with GitLab giving me the error "Access denied for your LDAP account.".

The (very) quick fix in my EDIT works if the only criteria for accessing your GitLab is that user must be in the LDAP. The function I short-circuited occurs after the "is-in-the-LDAP" check and concerns further verifications that I personally don't use. If your user schema has no "email" attribute and LDAP is read only, GitLab creates a temporary e-mail that logged users have to change before doing anything else in the profile settings, like add an SSH key... You have to log in as an admin and modify the default given emails to whatever else so they can add SSH keys. This issue is quite annoying, and I'm sure the fix isn't hard to implements but I'm not comfortable with ruby. Maybe I'll learn enough to fix it myself in a few weeks...

Unfortunately, your fix won't work for me on 7.4.2. If I leave user_filter untouched as an empty string it works with my LDAP accounts and logins just fine. If I set a filter it gives me The Access Denied error. I need this since I do not want any user on my LDAP server to be able to login to GitLab. What I'm wondering about is how this issue remained unfixed after a long time.

Do you use an active directory service ? If not you can also short-circuit the active_directory_disabled? function (like Oliver's said) and see if it helps.

Four months later and still exactly the same issue on a freshly installed GitLab 7.7.2 (revision bd982900) and Active Directory. No filter in use.
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production reveals no errors in "Checking LDAP" and shows the first 100 accounts; inside GitLab the accounts are created on first "LDAP Login" (which can be checked afterward with a standard login as root); LDAP uid's are shown in "Admin area - Users", but trying to login with such an account shows "Access denied for your LDAP account.".
Any clues after all this time?

Hi

I add the same issue.

Warning, back up the lines you remove first !!

Check your database, in indentities, you may have two authentication services 'ldap' and 'ldapmain'. When you tried once to connect, then remove the line with 'ldap' and it should work.

Please tell us if works.

Has anyone solved this?

I did and give the answer....

Another fix (with code) for the bitwise-filter and W2k3 LDAP can be found here: https://gitlab.com/gitlab-org/gitlab-ce/issues/1089

I solved it differently. My user_filter was all wrong. But thanks.

I've had this problem after upgrading from a 5.x through to 7.14. I work for a large educational institution, and need to use a central LDAP system I have no admin access to in order to authenticate users. The settings I have in my config/gitlab.yml match the original working install with new settings added, and queries performed through ldapsearch with the host, port, base, etc work as expected:

ldap: enabled: true servers: main: label: 'University' host: 'ldap.university.domain' port: '389' uid: 'uid' method: 'tls' #bind_dn: '_the_full_dn_of_the_user_you_will_bind_with' #password: '_the_password_of_the_bind_user' active_directory: false allow_username_or_email_login: false block_auto_created_users: false base: 'ou=uni,o=##,c=##' # ## indicates censoring

Having gone through all the responses, the closest solution I could find was the one proposed by @Qoya earlier. A clue was that gitlab was correctly authenticating users - incorrect credentials were being rejected, correct credentials resulted in users being created - but they were immediately returned to the sign in page with "Access denied for your LDAP account".

After digging, if I make allowed?() in lib/gitlab/ldap/access.rb always return true, everything works as it used to: user credential authentication is performed correctly, valid users are let in, etc. The problem seems to be that Gitlab::LDAP::Person.find_by_dn() is returning false for me, even when user.ldap_identity.extern_uid contains a value that I can successfully search for using ldapsearch. I haven't managed to pull the entire process apart yet (ruby is not my best language by a long way), but I'm guessing the problem I've been experiencing, and possibly others, is somewhere inside the implementation of Gitlab::LDAP::Adapter.users(), and its invocation of ldap_search when field is dn

I'm closing this issue for now because it's very old and several possible solutions have been provided.
If this is still an issue with the current version of gitlab, please reopen it :)

Status changed to closed

mentioned in issue #4282 (moved)

mentioned in commit 1fc2bc52

mentioned in merge request !14785

Access denied for your LDAP account

Designs

Child items ...

Activity

Admin message

Admin message

Access denied for your LDAP account

Activity