Gitlab CE : LDAP Authentification with ldapjs - ldap

I am building an LDAP adapter on my company's SSO so people can log-in to gitlab through it.
My LDAP adapther is build with ldapjs and returns the following object :
{ dn: 'cn=test, o=sso',
attributes:
{ cn: 'test',
uid: 'test',
mail: 'test#test.com',
objectclass: 'user'
}
}
I always end-up with Could not authenticate you from Ldapmain because "Invalid credentials".
Is there any other information I could provide to help my problem to be solved ?
Is there an obvious problem in my configuration ?
Where can I get more complete logs to diagnose the problem ?
My test user
Name: test
Username: test
Email: test#test.com
Config
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_SSO'
host: 'localhost'
port: 1389
uid: 'mail'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'cn=root'
password: 'secret'
active_directory: false
allow_username_or_email_login: true
block_auto_created_users: true
base: 'o=sso'
user_filter: ''
EOS
gitlab-rake gitlab:ldap:check RAILS_ENV=production
root#xxx:/var/log/gitlab# gitlab-rake gitlab:ldap:check RAILS_ENV=production
Checking LDAP ...
LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain
DN: cn=test, o=sso mail: test#test.com
Checking LDAP ... Finished
Logs
unicorn_stdout.log
root#xxx:/var/log/gitlab# cat /var/log/gitlab/unicorn/unicorn_stdout.log
I, [2015-11-30T13:42:37.350694 #22372] INFO -- omniauth: (ldapmain) Callback phase initiated.
E, [2015-11-30T13:42:37.392395 #22372] ERROR -- omniauth: (ldapmain) Authentication failure! invalid_credentials encountered.
gitlab-rails/production.log
Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-11-30 14:10:41 +0100
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"test#test.com", "password"=>"[FILTERED]"}
Redirected to http://localhost:8080/users/sign_in
Completed 302 Found in 37ms (ActiveRecord: 3.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-11-30 14:10:41 +0100
Processing by SessionsController#new as HTML
Completed 200 OK in 55ms (Views: 33.2ms | ActiveRecord: 1.3ms)

Related

Symfony 5.3 LDAP new authentication is always not valid credentials

I'm trying a json_login_ldap with the new authenticator manager from Symfony 5.3, it seems it cannot resolve the user password and I get always a 'not valid credentials' error message and can't login.
If I try the comand line ldapsearch with my data it is working correctly. And debuggin in Symfony I can see the ldap user data. So it is failing on the authentication.
my security.yaml is
security:
enable_authenticator_manager: true
password_hashers:
Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'
providers:
my_ldap:
ldap:
service: Symfony\Component\Ldap\Ldap
base_dn: '%env(resolve:BASE_DN)%'
search_dn: '%env(resolve:SEARCH_DN)%'
search_password: '%env(resolve:LDAP_PASSWORD)%'
default_roles: ROLE_USER
uid_key: sAMAccountName
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
main:
provider: my_ldap
stateless: true
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
search_dn: '%env(resolve:SEARCH_DN)%'
search_password: '%env(resolve:LDAP_PASSWORD)%'
dn_string: '%env(resolve:BASE_DN)%'
query_string: 'sAMAccountName={username}'
access_control:
# - { path: ^/admin, roles: ROLE_ADMIN }
# - { path: ^/profile, roles: ROLE_USER }
the .env that declares the variables used in the security.yaml:
BASE_DN=OU=foo,OU=bar,OU=baz,OU=qux,DC=my,DC=example,DC=com
SEARCH_DN=cn=searchuser,ou=foo,ou=bar,ou=baz,ou=qux,dc=my,dc=example,dc=com
LDAP_PASSWORD=ldap_reader_password
and in the services.yaml
services:
_defaults:
autowire: true
autoconfigure: true
Symfony\Component\Ldap\Ldap:
arguments: ['#Symfony\Component\Ldap\Adapter\ExtLdap\Adapter']
tags:
- ldap
Symfony\Component\Ldap\Adapter\ExtLdap\Adapter:
arguments:
- host: my-host # changed
port: 389
options:
protocol_version: 3
referrals: false
I'm sending the data with insomnia to test faster. I'm requesting a POST to http://localhost:8101/api/login with the data:
{
"security": {
"credentials": {
"login": "test.username",
"password": "my_password"
}
}
}
I followed the code to symfony/ldap/Security/LdapUserProvider.php and the loadUserByIdentifier at the end of the function $this->loadUser($identifier, $entry) actually returns a LdapUser object with the ldap user data. But the password is null instead the provided password. So maybe the password is lost somewhere before reaching this point.
In symfony\ldap\Security\LdapAuthenticator.php, the authenticate function returns the Passport object, this object has the PasswordCredentials with the plaintext correct user provided password and resolved: false.
I haven't found json_login_ldap examples in the documentation, but the project is almost empty, and I'm only trying to configure the ldap login, the configuration seems pretty basic. Why is not resolving the user password? Why I can't login? What I'm doing wrong?
Thank you for your help
Edit: The ldapsearch command line is
ldapsearch -x -b "dc=my,cn=example,cn=com" -H ldap://my.example.com -D "cn=searchuser,ou=foo,ou=bar,ou=baz,ou=qux,dc=my,dc=example,dc=com" -W
then asks for the password and answers with the list of ldap users.
With the ldapsearch command:
ldapsearch -x -b "dc=my,cn=example,cn=com" -H ldap://my.example.com -D "cn=searchuser,ou=foo,ou=bar,ou=baz,ou=qux,dc=my,dc=example,dc=com" -W "sAMAccountName=test.username"
and I get the following data:
# Test.Username, foo, bar, baz, qux, my.example.com
dn: CN=Test.Username,OU=foo,OU=bar,OU=baz,OU=qux,DC=my,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: test.username
sn: Username
c: EN
l: Randomcity
title: Assistant - departament
description: 8183-01234 | | EN | PT | Regular/Permanent
postalCode: 04035
physicalDeliveryOfficeName: Fake Street, Randomcity, 04035, EN
telephoneNumber: +34 (555) 123456
givenName: Test
distinguishedName: CN=Test Username,OU=foo,OU=bar,OU=baz,OU=qux,DC=my,DC=example,DC=com
instanceType: 4
whenCreated: 20230213120051.0Z
whenChanged: 20411115070912.0Z
displayName: Test Username
uSNCreated: 151386
memberOf: CN=pim,OU=pam,OU=pum - Groups,DC=my,DC=example,DC=com
uSNChanged: 330517879
co: bar
department: bar | departament
company: example bar U.C.
proxyAddresses: x500:/o=example/ou=Exchange Group (FYDF231234PDLT)/cn=Recipients/cn=Test.Username
streetAddress: Fake Street
employeeType: PT
name: Test Username
objectGUID:: mxAQq12Jjky/4ycKabEPS6==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 123
employeeID: EN00123
badPasswordTime: 123810906564118891
lastLogoff: 0
lastLogon: 123808333912908124
pwdLastSet: 123708200340431193
primaryGroupID: 123
objectSid:: AQUAAAAABCDEAAAxf4pEoe3zO6g0v/wO4kCAA==
accountExpires: 9123472012354775807
logonCount: 309
sAMAccountName: test.username
sAMAccountType: 123306368
sIDHistory:: AQUABCDEAAUVAAAAd4oemO2qe8MmF4j+ZRkBAA==
showInAddressBook: CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=pim,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=my,DC=example,DC=com
showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=pim,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=my,DC=example,DC=com
legacyExchangeDN: /o=pim/ou=External (FYDIBOHF25SPDLT)/cn=Recipients/cn=3f3dc637018b7653b68936ba11ed003d
userPrincipalName: enTUl01#my.example.com
lockoutTime: 0
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=my,DC=example,DC=com
dSCorePropagationData: 20212345670447.0Z
lastLogonTimestamp: 132814364123188798
msDS-SupportedEncryptionTypes: 0
textEncodedORAddress: X400:C=GB;A= ;P=example;O=London;S=Username;G=Test;
mail: Test.Username#example.com
manager: CN=Another Username,OU=foo,OU=bar,OU=baz,OU=qux,DC=my,DC=example,DC=com
msExchOmaAdminWirelessEnable: 4
msExchVersion: 44220981232016
msExchRemoteRecipientType: 4
mailNickname: TestUsername
msExchWhenMailboxCreated: 20130219124128.0Z
msExchMDBRulesQuota: 64
targetAddress: SMTP:TestUsername#fooAccess.mail.onmicrosoft.com
msExchSafeSendersHash:: fz/qCi123Qt86iU8888lolB1c6ddddUdL4Q77W9876rHu34
extensionAttribute1: EN
extensionAttribute11: 2015-May-08 12:05 by Workday
msExchArchiveQuota: 52123800
protocolSettings:: UE9QM8Klol123fCp8KnwqfCp8KytdfCp8Knwqc=
protocolSettings: 1
extensionAttribute12: Employee-PT
msExchMailboxGuid:: IPEaXbO1+0KPwAtZctyhBg==
msExchArchiveWarnQuota: 47112320
msExchPoliciesExcluded: {26491cfc-9e50-4857-861b-0cb8df22b5d7}
extensionAttribute4: bar | Finance
msExchRecipientDisplayType: -2112383642
extensionAttribute5: 255.255.255.255
msExchUMDtmfMap: reversedPhone:1234567890+
msExchUMDtmfMap: emailAddress:1234567890
msExchUMDtmfMap: lastNameFirstName:1234567890
msExchUMDtmfMap: firstNameLastName:1234567890
msExchTextMessagingState: 354021235
msExchTextMessagingState: 16123851
extensionAttribute6: EN001
msExchALObjectVersion: 119
extensionAttribute7: Active
msExchUserAccountControl: 0
msExchUMEnabledFlags2: -1
msExchRecipientTypeDetails: 2147123648
msExchELCMailboxFlags: 2
msExchDisabledArchiveGUID:: R/hxhWWlol123j1bfjZLNg==
When I asked for the ldap data they told me that the uid_key is sAMAccountName. And I think it could be the problem.
I tried to change the security.yaml ldap provider uid_key to mail (uid_key: mail), and the json_login_ldap dn_string to username (dn_string: {username}), and then tryed to login with the email test.username#example.com, but i see the same error.
First, ensure the ldap provider is properly configured. According to your ldapsearch example, it should be (with environment variables resolved) :
providers:
my_ldap:
ldap:
service: Symfony\Component\Ldap\Ldap
base_dn: 'dc=my,cn=example,cn=com'
search_dn: 'cn=searchuser,ou=foo,ou=bar,ou=baz,ou=qux,dc=my,dc=example,dc=com'
search_password: '<searchuser_password>'
default_roles: ROLE_USER
uid_key: sAMAccountName
Then, the important thing to consider for the json login config is that dn_string is used as a user base dn when query_string is set (which is not obvious at all).
query_string:
When this option is used, query_string will search in the DN specified
by dn_string and the DN resulted of the query_string will be used to
authenticate the user with their password.
Also, the example in the documentation shows that search_dn and search_password are both set (again) in the login config.
Following these 2 points, this should work :
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
search_dn: 'cn=searchuser,ou=foo,ou=bar,ou=baz,ou=qux,dc=my,dc=example,dc=com'
search_password: '<searchuser_password>'
dn_string: 'dc=my,cn=example,cn=com'
query_string: 'sAMAccountName={username}'
I think the issue is with this piece of configuration:
main:
provider: my_ldap
stateless: true
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
dn_string: 'uid={username},%env(resolve:BASE_DN)%' <<<< ASSUMPTION
The assumption above is that all of your users are located in one flat list in a container. Looking at your ldapsearch example, you have an LDAP tree that is more hierarchical. It means that your BASE_DN value is not the direct parent of your users, but there are sublevels.
Looking at
uid_key: sAMAccountName
I assume that you are using Active Directory. In that case, try this configuration:
providers:
my_ldap:
ldap:
service: Symfony\Component\Ldap\Ldap
base_dn: '%env(resolve:BASE_DN)%'
search_dn: '%env(resolve:SEARCH_DN)%'
search_password: '%env(resolve:LDAP_PASSWORD)%'
default_roles: ROLE_USER
uid_key: userPrincipalName
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
main:
provider: my_ldap
stateless: true
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
dn_string: '{username}'
(rest will stay the same).
Now you should be able to log in with the UPN of the users, of the format username#domain.
EDIT
You can also configure the LDAP module to search for the users by username, I had forgotten that part. That is the best solution IMHO.
Change the configuration to this:
main:
provider: my_ldap
stateless: true
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
query_string: 'sAMAccountName={username}'
and try to log in with the username you tried in the first place.
See https://symfony.com/doc/current/security/ldap.html#query-string for the reference documentation.
EDIT
What if you use this as the main configuration, and try to log in with the same credentials as you showed in your JSON example?
main:
provider: my_ldap
stateless: true
json_login_ldap:
service: Symfony\Component\Ldap\Ldap
check_path: api_login
username_path: security.credentials.login
password_path: security.credentials.password
dn_string: '%env(resolve:BASE_DN)%'
query_string: 'sAMAccountName={username}'

Could not authenticate you from Ldapmain because "Invalid credentials for user.name"

I use
debian 9
gitlab-ce 11.10.4-ce.0
omnibus install via apt
openldap 2.4.44
ldap configuration
Configured /etc/ldap/ldap.conf :
BASE dc=serverX,dc=lan
URI ldap://serverX.lan
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Configured /etc/gitlab/gitlab.rb :
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS
label: 'Gitlab LDAP'
host: '10.0.0.1'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'cn=admin,ou=users,dc=serverX,dc=lan'
password: 'xxxx'
encryption: 'plain'
active_directory: false
allow_username_or_email_login: true
block_auto_created_users: false
base: 'ou=users,dc=serverX,dc=lan'
EOS
Output of gitlab-rake gitlab:ldap:check is OK :
# gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
Checking LDAP ... Finished
Users created from phpldapadmin :
Searched tons of web ressources, but I can't figure out the way to create LDAP users or use existing ones.
I don't know what is the issue and why I get Invalid credentials for user.name : I edited via phpladmin the Password attribute (md5) and I type the same one in the LDAP Gitlab login page :
Gitlab logs :
==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/users/auth/ldapmain/callback" for 10.0.0.1 at 2019-05-16 07:56:16 +0200
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"user.name", "password"=>"[FILTERED]"}
Redirected to http://domainX.lan/users/sign_in
Completed 302 Found in 411ms (ActiveRecord: 23.1ms)
Started GET "/users/sign_in" for 10.0.0.1 at 2019-05-16 07:56:17 +0200
Processing by SessionsController#new as HTML
Completed 200 OK in 119ms (Views: 104.6ms | ActiveRecord: 7.5ms)
==> /var/log/gitlab/unicorn/unicorn_stdout.log <==
I, [2019-05-16T07:56:16.907169 #3996] INFO -- omniauth: (ldapmain) Callback phase initiated.
E, [2019-05-16T07:56:16.917884 #3996] ERROR -- omniauth: (ldapmain) Authentication failure! invalid_credentials: OmniAuth::Strategies::LDAP::InvalidCredentialsError, Invalid credentials for user.name
The slapcat output with targeted user to login :
dn: uuid=gquenot,ou=users,dc=serverX,dc=lan
cn:: abcdef123456789==
sn: Foo Bar
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
entryUUID: 5133fc-0be-2039-9825-cd7
creatorsName: cn=admin,dc=serverX,dc=lan
createTimestamp: 20190516045340Z
userPassword:: xxxxxxxx
mail: me#example.com
entryCSN: 20190516101837.136599Z#000000#000#000000
modifiersName: cn=admin,dc=serverX,dc=lan
modifyTimestamp: 20190516101837Z
Anyone knows what's wrong ?
Maybe someone can give me a sample ldiff and a working configuration ?
Edit:
slapadd try with this ldiff via slapadd -f file.ldiff :
dn: cn=admin,dc=serverX,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Firstname Lastname
givenName: Gilles
sn: Quenot
uid: gquenot
mail: me#example.com
userPassword: {MD5}xxxxxxxxxxxxxx
Error :
5cdd8fe4 slapcat_so.txt: line 1: unknown directive <dn:> outside backend info and database definitions.
slapadd: bad configuration file!
 Edit2
Fixed with :
ldapadd -x -H ldap://serverX:389 -D 'cn=admin,dc=serverX,dc=lan' -W -f stuff.ldiff
And updated password in phpldapadmin
Your Gitlab configuration targets Active Directory while you are using OpenLDAP to authenticate users, so the first thing to do is fixing the following parameters in /etc/gitlab/gitlab.rb:
uid: 'uid'
active_directory: false
I don't know what is the purpose of attributes in the context of an authentication (edit: attributes are used to synchronize user data from ldap to its Gitlab account, it shouldn't matter for the authentication itself).
Maybe there are other issues like the user's uid not being 'user.name', or the base being too narrow for example (user.name entry may not be under ou=people), if you don't know use the base dn as base search, or check by running a search with/without the 'ou' part :
ldapsearch -H ldap://10.0.0.1:389 -D cn=admin,dc=serverX,dc=lan -W -b ou=people,dc=serverX,dc=lan uid=user.name \*
I'd also check the credentials themselves directly against ldap , ie. not through Gitlab, by performing roughly the same query but using user.name bindings, here we actually tests that he can bind and read its own entry :
ldapsearch -H ldap://10.0.0.1:389 -D <user.name dn> -W -b <user.name dn> -s base \*
Also GitLab documentation insists on the fact that LDAP users must have an email address set, regardless of whether it is used to log in.
A typical ldif file containing user.name entry to be created using ldapadd -f (provided that the ou and dc's mentioned in its distinguished name exists) would look like this :
# user.name entry
dn: uid=user.name,ou=users,dc=serverX,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Firstname Lastname
givenName: Firstname
sn: Lastname
uid: user.name
mail: user.name#domain.com
userPassword: {MD5}<base64EncodedHash>
I don't know though if/how GitLab is aware of the password encryption scheme (seems there is no config for this or I missed it).
You can create a test case entry :
replace the <base64EncodedHash> with {MD5}CY9rzUYh03PK3k6DJie09g== (it represents the password test, if you need I have a script to generate them).
don't forget also to replace the dc's with the real ones in the dn
beware of empty lines and \t in the ldif file as it can break your ldap add/modify operations.
run ldapadd -x -H ldap://10.0.0.1:389 -D cn=admin,dc=serverX,dc=lan -W -f ldifFilename to create the user entry.
running the 1st ldapsearch cmd above, you should see a result for that new entry.
running the second one, binding with the user credentials 'test' and searching for its own entry (hence the -b base parameter pointing to himself to avoid permission issues during search), you should again see the same result.
In gitlab.rb :
gitlab_rails['ldap_servers'] = YAML.load <<-EOS
label: 'Gitlab LDAP'
host: '10.0.0.1'
port: 389
uid: 'uid'
bind_dn: 'cn=admin,ou=users,dc=serverX,dc=lan'
password: 'xxxx'
encryption: 'plain'
active_directory: false
allow_username_or_email_login: false
block_auto_created_users: false
base: 'ou=users,dc=serverX,dc=lan'
If you can bind with this user but not through gitlab ui, that could mean it does not handle the {MD5} authentication scheme.
I was facing the same problem - Invalid credentials even though I was keying in the correct credentials.
This solution worked for me -
My gitlab.rb had to be changed in this manner below. Previously I had not changed the value of 'uid' which was set to 'sAMAccountName', as you can see I commented it
and changed the value to 'uid' itself. So 'uid' => 'uid' is the setting. Prior to doing this setting even when I was running the command -
gitlab-rake gitlab:ldap:check , The output used to show - LDAP authentication... Success
but no list of ldap users were shown.
As soon as I changed the uid value as above, the rake command worked smoothly and showed me the list of all ldap users in the dc. Post this I was able to login also into the application through the UI
Note - Replace all the XXX with your own values.
gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
gitlab_rails['ldap_servers'] = {
'main' => {
'label' => 'LDAP',
'host' => '10.XXX.XX.XX',
'port' => 389,
# 'uid' => 'sAMAccountName',
'uid' => 'uid',#mandatory need to keep the value as 'uid' only
'encryption' => 'plain',
'verify_certificates' => false,
'bind_dn' => 'cn=XXX,dc=XXXX,dc=XXX',
'password' => 'XXX',
'verify_certificates' => false,
# 'tls_options' => {
# 'ca_file' => '',
# 'ssl_version' => '',
# 'ciphers' => '',
# 'cert' => '',
# 'key' => ''
# },
'timeout' => 10,
'active_directory' => false,
'allow_username_or_email_login' => false,
'block_auto_created_users' => false,
'base' => 'dc=XXX,dc=XX',
# 'user_filter' => '',
# 'attributes' => {
# 'username' => ['uid', 'userid', 'sAMAccountName'],
# 'email' => ['mail', 'email', 'userPrincipalName'],
# 'name' => 'cn',
# 'first_name' => 'givenName',
# 'last_name' => 'sn'
# },
'lowercase_usernames' => true,
# EE Only
# 'group_base' => '',
# 'admin_group' => '',
# 'external_groups' => [],
# 'sync_ssh_keys' => false
}
}
I install GitLab using Docker Engine
https://docs.gitlab.com/ee/install/docker.html
LDAP Configuration
https://docs.gitlab.com/ee/administration/auth/ldap/#integrate-ldap-with-gitlab
sudo docker exec -it gitlab nano /etc/gitlab/gitlab.rb
## LDAP Settings
##! Docs: https://docs.gitlab.com/omnibus/settings/ldap.html
##! **Be careful not to break the indentation in the ldap_servers block. It is
##! in yaml format and the spaces must be retained. Using tabs will not work.**
gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
##! **remember to close this block with 'EOS' below**
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'ipa.example.com'
port: 636
uid: 'uid'
bind_dn: 'uid=gitlab,cn=users,cn=accounts,dc=example,dc=com'
password: 'gitlabpassword'
encryption: 'simple_tls' # "start_tls" or "simple_tls" or "plain"
verify_certificates: false
smartcard_auth: false
active_directory: false
allow_username_or_email_login: false
lowercase_usernames: false
block_auto_created_users: false
base: 'cn=users,cn=accounts,dc=example,dc=com'
user_filter: ''
EOS
Save configuration, and than reconfigure GitLab:
sudo docker exec -it gitlab /bin/bash
root#gitlab:/# gitlab-ctl reconfigure
root#gitlab:/# gitlab-ctl restart
Check if LDAP integration works:
root#gitlab:/# gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP: ... Server: ldapmain
not verifying SSL hostname of LDAPS server 'ipa.example.com:636'
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: uid=admin,cn=users,cn=accounts,dc=example,dc=com uid: admin
DN: uid=gitlab,cn=users,cn=accounts,dc=example,dc=com uid: gitlab
Checking LDAP ... Finished

Spinnaker: LDAP authorization setup

hello: when trying to setup authorization using LDAP, i am getting below error, any suggestions:
2017-09-27 21:52:30.931 WARN 1 --- [ main]
c.n.s.f.p.internal.ClouddriverService : [] Cache initialization
failed:
com.netflix.hystrix.exception.HystrixRuntimeException: getAccounts failed and fallback failed.
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:811)
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:785)
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$1.onError(OperatorOnErrorResumeNextViaFunction.java:99)
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:71)
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:71)
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:71)
at com.netflix.hystrix.AbstractCommand$DeprecatedOnFallbackHookApplication$1.onError(AbstractCommand.java:1514)
at com.netflix.hystrix.AbstractCommand$FallbackHookApplication$1.onError(AbstractCommand.java:1404)
at com.netflix.hystrix.HystrixCommand$2.call(HystrixCommand.java:314)
at com.netflix.hystrix.HystrixCommand$2.call(HystrixCommand.java:306)
at rx.Observable$2.call(Observable.java:162)```
here is my ldap config:
auth:
groupMembership:
service: ldap
ldap:
url: ldap://10.10.10.21
managerDn: cn=admn,dc=testlab,dc=corp
managerPassword: adm543
groupSearchBase: ou=groups,dc=testlab,dc=corp
groupSearchFilter: member={0},dc=testlab,dc=corp
groupRoleAttributes: cn
userDnPattern: uid={0},ou=testlab,ou='service accounts'
userSearchBase: dc=testlab,dc=corp
userSearchFilter: ''
userSearchFilter is overwriting userDnPattern. And it looks like you are searching only for users in the service accounts ou.
Try something like this
auth:
groupMembership:
service: ldap
ldap:
# Connection
url: ldap://10.10.10.21
managerDn: cn=admn,dc=testlab,dc=corp
managerPassword: adm543
# Groups
groupSearchBase: ou=groups,dc=testlab,dc=corp
groupSearchFilter: member={0},dc=testlab,dc=corp
groupRoleAttributes: cn
# Users
userSearchBase: uid={0},ou=users,dc=testlab,dc=corp
I managed to make it work like this.
ldap:
roleProviderType: LDAP
url: ldap://##.###.##.###:389
managerDn: CN=myUser,OU=Users_ServicesAdmin,OU=Usuarios_Especiais,DC=myDc,DC=intranet
managerPassword: #####
userSearchFilter: sAMAccountName={0}
userSearchBase: dc=uolcorp,dc=intranet
groupSearchBase: ou=Grupos,ou=Grupos,DC=corp,DC=intranet
groupSearchFilter: member={0}
groupRoleAttributes: cn

Gitlab integreate with LDAP login failed with "Invalid credentials"

I installed "gitlab-ce-7.14.1-ce.0.el6.x86_64.rpm" on Centos.Everything goes normal but when I try to integrate with LDAP runs on my Qnap NAS. It shows error.
My LDAP account is right definitely.
Test LDAP account
ldapwhoami -D "cn=admin,dc=test,dc=net" -w "ldap" -h 192.168.1.10
Response
dn:cn=admin,dc=test,dc=net
When I try to login with LDAP account from gitlab web.
error on GitLab Web login page
Could not authorize you from Ldapmain because "Invalid credentials".
error in production.log
Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-09-02 15:41:59 +0800
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"user", "password"=>"[FILTERED]"}
Redirected to http://192.168.1.81/users/sign_in
Completed 302 Found in 38ms (ActiveRecord: 6.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-09-02 15:41:59 +0800
Processing by SessionsController#new as HTML
Completed 200 OK in 75ms (Views: 36.2ms | ActiveRecord: 5.2ms)
My 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: '192.168.1.10'
port: 389
uid: 'admin'
method: 'plain' # "tls" or "ssl" or "plain"
allow_username_or_email_login: true
bind_dn: 'cn=admin,dc=test,dc=net'
password: 'ldap'
active_directory: false
base: 'ou=people,dc=test,dc=net'
user_filter: ''
EOS
This question is similar to Gitlab: LDAP "Invalid credentials", but credentials are right
but it is different version of Gitlab.
My friends have resolve this issue. Just change
uid: 'admin'
to
uid: 'uid'
Here is full configuration of /etc/gitlab/gitlab.rb
external_url 'http://192.168.1.11'
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: '192.168.1.10'
port: 389
uid: 'uid'
method: 'plain' # "tls" or "ssl" or "plain"
allow_username_or_email_login: true
bind_dn: 'cn=admin,dc=test,dc=net'
password: 'ldap'
active_directory: false
base: 'ou=People,dc=test,dc=net'
user_filter: ''
EOS
Thank you everyone.

Symfony2: login does not work on first try after clearing cookies

When trying to log in, Symfony2 tells me that I provided the wrong credentials. Second try works. Any ideas why this could happen?
To reproduce the behaviour, I have to logout, clear cookies, go to the login page again and log in again.
I am using FOSUserBundle.
config.yml:
framework:
#esi: ~
secret: asdfsadfasdf
#translator: { fallback: en }
charset: UTF-8
router: { resource: "%kernel.root_dir%/config/routing.yml" }
form: true
csrf_protection: true
validation: { enable_annotations: true }
templating: { engines: ['twig'], assets_version: v1.2 } #assets_version: SomeVersionScheme
translator: { fallback: de }
session:
default_locale: de
auto_start: false
lifetime: 1000000
...
security.yml:
security:
encoders:
Symfony\Component\Security\Core\User\User: plaintext
role_hierarchy:
ROLE_ADMIN: ROLE_USER
ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
providers:
fos_userbundle:
id: fos_user.user_manager
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
login:
pattern: ^/login$
security: false
public:
pattern: ^/.*
form_login:
provider: fos_userbundle
check_path: /login_check
remember_me: true
remember_me:
key: aaasfasdfasdfsadfsadf
lifetime: 1296000 #15 days in second
path: /
anonymous: true
logout: true
access_control:
- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY}
- { path: ^/register, roles: IS_AUTHENTICATED_ANONYMOUSLY}
#- { path: ^/_internal, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 }
- { path: ^/events/create, roles: ROLE_USER }
#...
acl:
connection: default
routing.yml:
_imagine:
resource: .
type: imagine
_index:
resource: "#AjadoEventHubBundle/Controller/IndexController.php"
type: annotation
fos_comment_api:
type: rest
resource: "#FOSCommentBundle/Resources/config/routing.yml"
prefix: /api
fos_user_security:
resource: "#FOSUserBundle/Resources/config/routing/security.xml"
...
#FOSUserBundle/Resources/config/routing/security.xml:
<routes xmlns="http://symfony.com/schema/routing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/routing http://symfony.com/schema/routing/routing-1.0.xsd">
<route id="fos_user_security_login" pattern="/login">
<default key="_controller">FOSUserBundle:Security:login</default>
</route>
<route id="fos_user_security_check" pattern="/login_check">
<default key="_controller">FOSUserBundle:Security:check</default>
</route>
<route id="fos_user_security_logout" pattern="/logout">
<default key="_controller">FOSUserBundle:Security:logout</default>
</route>
</routes>
On my opinion, this is expected behaviour as you enabled anonymous authentication :
You request your app url, without being logged => a session cookie is created with your session ID
An anonymous token is created
You clear cookie => no more session id to identify you
Next request, no token is attached to your login request...
I'm not familiar with symfony, however, I have experienced the same problem when the authentication check looked for a valid cookie, but the cookie was being created after the check--thus causing it to pass the second time, never the first.
By default Symfony require that a session must be exist before the submitting of the form
from the docs
# by default, a session must exist before submitting an authentication request
# if false, then Request::hasPreviousSession is not called during authentication
# new in Symfony 2.3
In order to over come this you could set "require_previous_session" (which is by default true) to false in the "security.yml" as under "form_login" like this:
require_previous_session: false
You could read more about it in Symfony docs in the following link
SecurityBundle Configuration ("security")
I had this problem and I solved it following the answer here Symfony 2 “Your session has timed out or you have disabled cookies”.
#AlterPHP was right, you have to login twice because the first time you are getting an error like this:
Authentication request failed. (...) Your session has timed out, or you have disabled cookies.
As you don't have a session started, with this request a new session is created. Next time you try to login, as the session was created, you can login.
You had to set the option require_previous_session: false in your app/config/security.yml file to avoid looking for a previous session:
security:
firewalls:
main:
form_login:
require_previous_session: false