The following ldapsearch command works, flawlessly.
ldapsearch -LLL -s sub -P 3 -D "CN=,OU=IT,OU=Non-Users,OU=Users,OU=UserAccount,DC=,DC=com" -H ldaps://.com: -w '' -v -b 'OU=Users,OU=UserAccount,DC=,DC=com' '(&(objectClass=person)(sAMAccountName=))'
But, regardless, of how much I double-check the values are typed correctly, this, configured in gitlab.yml, does not.
ldap:
enabled: true
host: '.com'
port:
uid: 'sAMAccountName'
method: 'ssl'
bind_dn: 'CN=,OU=IT,OU=Non-Users,OU=Users,OU=UserAccount,DC=,DC=com'
password: ''
allow_username_or_email_login: true
base: 'OU=Users,OU=UserAccount,DC=,DC=com'
user_filter: ''
group_base: ''
Yes, the BindDN is at a different location than the other users, but it is south of it, so the query base is valid.
All attempts throw this error on the screen:
Could not authorize you from LDAP because "Invalid credentials"
production.log indicates the following:
Started GET "/users/sign_in" for 127.0.0.1 at 2014-07-18 08:13:17 -0400
Processing by Devise::SessionsController#new as HTML
Completed 200 OK in 21ms (Views: 12.8ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2014-07-18 08:13:25 -0400
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"", "username"=>"", "password"=>"[FILTERED]"}
Redirected to http:///users/sign_in
Completed 302 Found in 3ms (ActiveRecord: 0.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2014-07-18 08:13:56 -0400
Processing by Devise::SessionsController#new as HTML
Completed 200 OK in 10ms (Views: 5.9ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2014-07-18 08:20:03 -0400
The LDAP in question is Active Directory, and while I don't have access to the server natively in order to query the logs, the "badPwdCount" is incremented for each attempt at a web login, and I don't understand how, or why.
I know the perils of end users and their insistence that they're typing their usernames and passwords in correctly, but I've checked, triple-checked, octuple-checked that there aren't any typos in my declarations, and I can't find any other incident with this same error combination. I know that the syntax here is correct.
What could possibly be the problem?
Here is my working AD settings for LDAP.
#########################################
ldap:
enabled: true
host: '16.184.18.88'
port: 636
uid: 'sAMAccountName' #userPrincipalName
method: 'ssl' # "tls" or "ssl" or "plain"
bind_dn: 'CN=Gitlab Git,CN=Users,DC=mydomain,DC=net'
password: 'My_Password'
allow_username_or_email_login: false
base: 'CN=Users,DC=mydomain,DC=net'
user_filter: '(memberOf=CN=Developers,OU=GitLabHQ,DC=mydomain,DC=net)'
group_base: 'OU=GitLabHQ,DC=mydomain,DC=net'
admin_group: GitLabAdmins
########################################
We had the similar issue, though our settings were all correct as we were getting the user search results by setting up the similar LDAP configuration on different tools like Jenkins, SonarQube; etc.
We resolved the issue by setting the value of DefaultForceNoPage to true in the ldap.rb file located at (the path may vary for different versions of gitlab):
/opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/net-ldap-0.16.0/lib/net/ldap.rb
^^^^^^^
which is false by default. So, once you have set the value to true, restart the GitLab server using:
gitlab-ctl reconfigure
You can also check if you are getting the results of the users of your organization by:
gitlab-rake gitlab:ldap:check
Note: Most common issues users face while logging into the application using their mail id's, you should put:
uid: 'mail'
I too have got "invalid credentials" error while trying to configure LDAP in gitlab. The error is absolutely due to the format of ldap query. And gitlab appln looks for a specific format to bind the user to AD.
Here is my working configuration
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: 'LDAP'
host: '<LDAP hostname>'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'CN=<user name>,OU=<ou1>,OU=<ou2>,...,DC=example,DC=com'
password: 'My_Password'
active_directory: true
allow_username_or_email_login: true
block_auto_created_users: false
base: 'DC=example,DC=com'
If you are not sure of bind_dn. Use a AD query tool that provides you the complete bind dn of the user.
Related
My LDAP configuration located at /etc/gitlab/gitlab.rb is as follows:
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: '10.3.32.11'
port: 389
uid: 'sAMAccountName'
bind_dn: 'CN=svc gitlab,CN=Users,DC=VPN,DC=Local'
password: 'PASSWORD'
encryption: 'plain' # "start_tls" or "simple_tls" or "plain"
verify_certificates: false
active_directory: true
allow_username_or_email_login: true
lowercase_usernames: true
block_auto_created_users: false
base: 'ou=vpnusers,dc=vpn,dc=local'
user_filter: '(&(objectCategory=user)(memberOf=CN=appGitLab,ou=vpnusers,dc=vpn,dc=local))'
EOS
I have ran a gitlab-ctl reconfigure and gitlab-ctl restart aftewr these configuration changes.
EDIT:
my production.log output is as follows:
Completed 200 OK in 3ms (Views: 0.4ms | ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
Started POST "/users/auth/ldapmain/callback" for 10.88.0.189 at 2018-08-21 12:57:56 -0500
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"aaron.west", "password"=>"[FILTERED]"}
Redirected to http://10.3.18.80/users/sign_in
Completed 302 Found in 279ms (ActiveRecord: 1.8ms | Elasticsearch: 0.0ms)
Started GET "/users/sign_in" for 10.88.0.189 at 2018-08-21 12:57:56 -0500
Processing by SessionsController#new as HTML
Completed 200 OK in 35ms (Views: 18.9ms | ActiveRecord: 2.4ms | Elasticsearch: 0.0ms)
Started GET "/-/metrics" for 127.0.0.1 at 2018-08-21 12:57:58 -0500
Processing by MetricsController#index as HTML
Completed 200 OK in 3ms (Views: 0.4ms | ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
Started GET "/-/metrics" for 127.0.0.1 at 2018-08-21 12:58:13 -0500
Processing by MetricsController#index as HTML
Any idea why I keep seeing Could not authorize you from LDAP because "Invalid credentials" upon LDAP login?
There is a task you can check if your LDAP configuration is okay and get some samples of possible LDAP users: LDAP Rake Tasks
The LDAP check Rake task will test the bind_dn and password credentials (if configured) and will list a sample of LDAP users. This task is also executed as part of the gitlab:check task, but can run independently using the command below.
Omnibus Installation
sudo gitlab-rake gitlab:ldap:check
Source Installation
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
By default, the task will return a sample of 100 LDAP users. Change this limit by passing a number to the check task:
rake gitlab:ldap:check[50]
We have GitLab Community Edition 9.1.3 (2e4e522) on our Linux server. We use AD logins because of our corp. policy.
Configuration file /etc/gitlab/gitlab.rb
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: 'LDAP'
host: '{HOST}'
port: 389
uid: 'sAMAccountName'
method: 'plain'
bind_dn: 'CN=SVCJAVACZ,OU=FUNCTIONAL,OU=Users,OU=CZ,OU=MCC,DC=r3,DC=madm,DC=net'
password: '{PASSWORD}'
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: 'DC=r3,DC=madm,DC=net'
user_filter: ''
attributes:
username: ['uid', 'userid', 'sAMAccountName']
email: ['mail', 'email', 'userPrincipalName']
name: 'cn'
first_name: 'givenName'
last_name: 'sn'
EOS
My LDAP login is working correctly. Colleagues I work with are able to login as well without any problems. But few days ago one of the users tried to login to GitLab application using LDAP and was not successful (3 times - always 302). It seems that from that time he gets periodically blocked in our network (even on VPN).
As written in GitLab LDAP troubleshooting I opened the application.log but it was empty and info from production.log to this state is:
Started POST "/users/auth/ldapmain/callback" for {IP} at 2017-05-28 15:51:55 +0200
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"{TOKEN}", "username"=>"{USERNAME}", "password"=>"[FILTERED]", "remember_me"=>"1"}
Redirected to {ADDRESS}/users/sign_in
Completed 302 Found in 25ms (ActiveRecord: 2.7ms)
From file unicorn_stdout.log:
I, [2017-05-28T15:51:55.388593 #14907] INFO -- omniauth: (ldapmain) Callback phase initiated.
E, [2017-05-28T15:51:55.569159 #14907] ERROR -- omniauth: (ldapmain) Authentication failure! invalid_credentials encountered.
From command mentioned in GitLab Maintenance of Tasks sudo gitlab-rake gitlab:env:info:
System information
System: Ubuntu 16.04
Current User: git
Using RVM: no
Ruby Version: 2.3.3p222
Gem Version: 2.6.6
Bundler Version:1.13.7
Rake Version: 10.5.0
Redis Version: 3.2.5
Git Version: 2.11.1
Sidekiq Version:4.2.7
GitLab information
Version: 9.1.3
Revision: 2e4e522
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: http://{URL}
HTTP Clone URL: http://{URL}/some-group/some-project.git
SSH Clone URL: git#{URL}:some-group/some-project.git
Using LDAP: yes
Using Omniauth: no
GitLab Shell
Version: 5.0.2
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
In there in GitLab any cache that would periodically send blocking command for users that have tried to login but failed (and therefore get blocked ever since)?
Or any suggestions in what to look into now? Any ideas?
We are trying to integrate our local Gitlab CE installation (omnibus, version 8.12) with our LDAP server. Unfortunately, after several changes to the following configuration, we have not been able to figure out the right config.
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: 'LDAP'
host: '******.******.***'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'uid=******,ou=******,o=Applications,o=******,c=******'
password: '**********'
timeout: 10
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: 'o=******'
user_filter: ''
attributes:
username: ['uid', 'userid', 'sAMAccountName']
email: ['mailExterno', 'mail', 'email', 'userPrincipalName']
name: 'cn'
first_name: 'givenName'
last_name: 'sn'
## EE only
group_base: ''
admin_group: ''
sync_ssh_keys: false
EOS
Executing the LDAP check displays zero users:
[root#myserver mydir]# gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain
Checking LDAP ... Finished
We have dozens of users in our LDAP server and many applications (such as Redmine, Jenkins, Svn....) integrated with it without problems...
Any ideas on what are we doing wrong with Gitlab?
Help would be very much appreciated.
Finally we found the solution. I'm posting the answer here just in case someone else reading this and facing similar issues might find it useful.
The LDAP server I was connecting to was not an Active Directory, so the configuration changes I needed to do where:
#...
uid: 'uid'
#...
active_directory: false
#...
A very important aspect to take into account is that, in order to apply the changes, restarting gitlab is not enough, we should execute reconfigure:
sudo gitlab-ctl reconfigure
I run a Kolab service on a separate VM from GitLab and have set multiple domains there.
I cannot configure GitLab to search the login user in several (all) domains on the same Kolab Groupware server, i.e. ou=People,dc=mydomain1,dc=com and ou=People,dc=mydomain2,dc=com.
I have tried with setting only 'ou=People', putting wildcards, using LDAP search operator (|(ou=...,dc=..)(ou...)) and many other things, but without luck.
This is the current configuration that works with one domain (which is also the main, parent domain of the Kolab configuration):
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: 'LDAP'
host: 'my.host.com'
port: 389
uid: 'mail'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'uid=kolab-service,ou=Special Users,dc=mydomain1,dc=com'
password: 'mypassword'
active_directory: false
allow_username_or_email_login: false
block_auto_created_users: false
base: 'ou=People,dc=mydomain1,dc=com'
user_filter: ''
Is there any way to set the 'base' parameter so I could login with users from multiple domains (but on the same LDAP server)?
I'm currently trying to implement Devise with LDAP Authentication on RAILS3. I've got it setup and it appears to connect and try to auth, but appears to fail. I don't seem to get any sort of real error messages to work with so its very difficult to take it any further.
Log of login session:
Started POST "/users/sign_in" for 192.168.160.1 at Tue Dec 06 05:20:16 +0000 2011
Processing by Devise::SessionsController#create as HTML
Parameters: {"commit"=>"Sign in", "authenticity_token"=>"G2tEq9gPpJiN0RhanTd8HMWno62F+1oLWbU4xdX78bg=", "utf8"=>"\342\234\223", "user"=>{"remember_me"=>"0", "password"=>"[FILTERED]", "login"=>"richmond#email.com"}}
User Load (0.1ms) SELECT `users`.* FROM `users` WHERE `users`.`login` = 'richmond#email.com' LIMIT 1
LDAP: LDAP dn lookup: mail=richmond#email.com
LDAP: LDAP search for login: mail=richmond#email.com
LDAP: Authorizing user mail=richmond#email.com,ou=groupxx,o=company.com
LDAP: LDAP dn lookup: mail=richmond#email.com
LDAP: LDAP search for login: mail=richmond#email.com
Completed 401 Unauthorized in 7147ms
Processing by Devise::SessionsController#new as HTML
Parameters: {"commit"=>"Sign in", "authenticity_token"=>"G2tEq9gPpJiN0RhanTd8HMWno62F+1oLWbU4xdX78bg=", "utf8"=>"\342\234\223", "user"=>{"remember_me"=>"0", "password"=>"[FILTERED]", "login"=>"richmond#email.com"}}
Rendered devise/shared/_links.erb (0.1ms)
Rendered devise/sessions/new.html.erb within layouts/application (5.0ms)
Completed 200 OK in 23ms (Views: 21.4ms | ActiveRecord: 0.0ms)
Started GET "/assets/defaults.js" for 192.168.160.1 at Tue Dec 06 05:20:23 +0000 2011
Served asset /defaults.js - 404 Not Found (3ms)
ActionController::RoutingError (No route matches [GET] "/assets/defaults.js"):
Rendered /usr/local/lib/ruby/gems/1.8/gems/actionpack-3.1.0/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (0.5ms)
ldap config:
development:
host: ldap.company.com
port: 636
attribute: mail
base: ou=groupxx,o=company.com
#admin_user: cn=admin,dc=test,dc=com
#admin_password: admin_password
ssl: true
# <<: *AUTHORIZATIONS
I don't have access to the LDAP server so I cannot confirm anything from that end. The main issue I have is that I cannot get any error messages out of the login process - Is it not able to find the user? Does it find the user but fail login? Why does it do 2 LDAP searches?
same issue here. Did a ldapsearch, which works however. Company is running an ActiveDirectory server here:
ldapsearch -Z -h ldap.company.com -p 389 -s sub -D
"cn=somebody,ou=my_ou,dc=ldap,dc=company,dc=com" -W -b
"dc=ldap,dc=company,dc=com" "(&(cn=somebody))" mail
Solution:
I have found the solution: In config/initializers/devise.rb I missed to activate config.ldap_use_admin_to_bind = true. Only with this flag, devise_ldap_authenticatable really uses the BindDN (i.e. admin_user, admin_password which both have to be uncommented) defined at config/ldap.yml.
I found out the problem I had was that the LDAP server my company (IBM) uses was using a different protocol standard to the ones officially supported by NET-LDAP.
You simply need to change the PagedResults Control Type to a slightly different standard:
#PagedResults = "1.2.840.113556.1.4.319" # Microsoft evil from RFC 2696
PagedResults = "2.16.840.1.113730.3.4.2" # IBM Bluepages compatible ControlType
Full code change details here.
I forked it and fixed it over here on GitHub.
I did encounter the same problem on my ActiveDirectory. I tried using the bind user but it didn´t help either. I changed devise according to screencast 210 to use the username field. Here´s my ldap.yml
development:
host: dcburda0
port: 636
attribute: cn
base: OU=Organisation,DC=mydomain,DC=com
admin_user: CN=username,OU=Support Center Muenchen,OU=name GmbH,OU=Organisation,DC=mydomain,DC=com
admin_password: password
ssl: true