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?
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)?
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.
I'm currently trying to setup Gitlab 6.7 as a fresh install as well as upgrading from version 6.6. While doing so I ran into the following error:
When logging in with an LDAP account, which is not in Gitlab yet, the login fails with the message containing the words
Could not authorize you from LDAP because: "Validation failed username only letters, digits & '_' '-' '.' allowed. Letter should be first".
Hence the upgraded version still works with existing accounts.
After having a look at the code in GitHub I suspect that the root cause is that the generation of the Gitlab username changed.
To me it looks like before it was the first part of the email address (everything up to #) and now it seems to be the uid, but in my case the uid is an email address containing an # character.
As I do not have any other value in LDAP with uniquely identifies a user, I am required to use the uid/mail.
Anyone has a hint how to proceed here?
Thanks
LDAP:
objectClass person
givenName Jane
sn Doe
cn Jane Doe
uid jane.doe#example.com
mail jane.doe#example.com
Gitlab.yml 6.6:
ldap:
enabled: true
host: 'ldaphost.example.com'
base: 'o=example.com'
port: 636
uid: 'uid'
method: 'ssl' # "tls" or "ssl" or "plain"
#bind_dn: ''
#password: '_the_password_of_the_bind_user'
# 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
Gitlab.yml 6.7:
ldap:
enabled: true
host: 'ldaphost.example.com'
port: 636
uid: 'uid'
method: 'ssl' # "tls" or "ssl" or "plain"
#bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
#password: '_the_password_of_the_bind_user'
# 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: 'o=example.com'
# Filter LDAP users
#
# Format: RFC 4515
# Ex. (employeeType=developer)
#
user_filter: ''
I have a Symfony 2 app using the basic in_memory authentication (as described in the security documentation). The login works fine in our development environment(s). But on the staging server, the basic authentication doesn't seem to provide a proper token -as seen in the hereby provided logfile-; thus we keep on getting the login popup again and again.
Our security configuration:
security:
firewalls:
secured_area:
pattern: ^/
anonymous: ~
http_basic:
realm: "Secured Demo Area"
access_control:
- { path: ^/admin, roles: [ROLE_ADMIN]}
providers:
in_memory:
users:
admin: { password: admin, roles: 'ROLE_ADMIN' }
encoders:
Symfony\Component\Security\Core\User\User: plaintext
This is the log output from the (successful) development environment login:
[2011-07-21 13:49:48] security.DEBUG: Read SecurityContext from the session [] []
[2011-07-21 13:49:48] security.DEBUG: Reloading user from user provider. [] []
[2011-07-21 13:49:48] security.DEBUG: Username "root" was reloaded from user provider. [] []
And this is the log output from the staging environment login:
[2011-07-21 13:53:08] security.INFO: Populated SecurityContext with an anonymous Token [] []
[2011-07-21 13:53:08] security.DEBUG: Access denied (user is not fully authenticated); redirecting to authentication entry point [] []
[2011-07-21 13:53:08] security.DEBUG: Calling Authentication entry point [] []
Thanks in advance for the help.
Your dev environment is probably running PHP as mod_php while your staging server is probably running it as FastCGI. By default, the PHP_AUTH_USER and PHP_AUTH_PW server variables are not filled in this context when you authenticate via HTTP basic, and these are what Symfony is using to create the Security context and validate your password.
If you're running this as FCGI on Apache you can fix this. One is to force FastCGI to pass the Authorization header, which it normally suppresses. Add this to the Apache site definition next to the other FastCGI configuration options:
FcgidPassHeader Authorization
For other applications you may also need to mess around to a greater degree (as described here) but for Symfony just passing the header should be sufficient.