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}'
I am using Spring Cloud Config Server to serve configuration for my client apps. To facilitate secrets configuration I am using HashiCorp Vault as a back end. For the remainder of the configuration I am using a GIT repo. So I have configured the config server in composite mode. See my config server bootstrap.yml below:-
server:
port: 8888
spring:
profiles:
active: local, git, vault
application:
name: my-domain-configuration-server
cloud:
config:
server:
git:
uri: https://mygit/my-domain-configuration
order: 1
vault:
order: 2
host: vault.mydomain.com
port: 8200
scheme: https
backend: mymount/generic
This is all working as expected. However, the token I am using is secured with a Vault auth policy. See below:-
{
"rules": "path "mymount/generic/myapp-app,local" {
policy = "read"
}
path "mymount/generic/myapp-app,local/*" {
policy = "read"
}
path "mymount/generic/myapp-app" {
policy = "read"
}
path "mymount/generic/myapp-app/*" {
policy = "read"
}
path "mymount/generic/application,local" {
policy = "read"
}
path "mymount/generic/application,local/*" {
policy = "read"
}
path "mymount/generic/application" {
policy = "read"
}
path "mymount/generic/application/*" {
policy = "read"
}"
}
My issue is that I am not storing secrets in all these scopes. I need to specify all these paths just so I can authorize the token to read one secret from mymount/generic/myapp-app,local. If I do not authorize all the other paths the VaultEnvironmentRepository.read() method returns a 403 HTTP status code (Forbidden) and throws a VaultException. This results in complete failure to retrieve any configuration for the app, including GIT based configuration. This is very limiting as client apps may have multiple Spring profiles that have nothing to do with retrieving configuration items. The issue is that config server will attempt to retrieve configuration for all the active profiles provided by the client.
Is there a way to enable fault tolerance or lenience on the config server, so that VaultEnvironmentRepository does not abort and returns any configuration that it is actually authorized to return?
Do you absolutely need the local profile? Would you not be able to get by with just the 'vault' and 'git' profiles in Config Server and use the 'default' profile in each Spring Boot application?
If you use the above suggestion then the only two paths you'd need in your rules (.hcl) file are:
path "mymount/generic/application" {
capabilities = ["read", "list"]
}
and
path "mymount/generic/myapp-app" {
capabilities = ["read", "list"]
}
This assumes that you're writing configuration to
vault write mymount/generic/myapp-app
and not
vault write mymount/generic/myapp-app,local
or similar.
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)
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.