LDAP authentication should try to reconnect instead of comparing passwords

[Seb33300]

How LDAP authentication actually works in Symfony 2.8 (with the new LDAP component):

1. LDAP connection with an "admin" account
2. Check if the username trying to connect exists and get user data
3. If yes, check if password is equal to the "userpassword" of the user previously get
4. If passwords match, it's OK!

How LDAP authentication should work:

1. LDAP connection with an "admin" account
2. Check if the username trying to connect exists
3. If yes, try to connect to LDAP with user credentials.
4. If connection works, it's OK!

The "admin" account may not always have access to the "userpassword" field.
This is the problem I am encountering.

Problem is here:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/User/LdapUserProvider.php
loadUser() method should not assign the $user['userpassword'] but should try to reconnect with entered password then assign entered password if connection works.

See:
http://stackoverflow.com/a/6703425/1489264
http://stackoverflow.com/questions/25519666/is-ldap-binding-account-required-for-user-authenticai

[ChadSikorra]

While it does store the userpassword attribute to the User class, it also connects to LDAP with the supplied credentials via a bind...

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/Provider/LdapBindAuthenticationProvider.php#L71

...which would validate the credentials. So the authentication sequence seems correct. But I think the issue would be that on a refreshUser() call it doesn't set the password on the User object anymore, if it existed, which causes the AbstractToken implementation to set authentication to false thinking that the user has changed (if the password had been set previously anyway)?

At least that's how I'm understanding the flow here. This behavior wouldn't happen in AD, because the userpassword by default would never return anything, so the password would always be null. But I suppose that's going to be implementation specific.

[Seb33300]

There are 2 types of use with this component: as a provider or as a firewall only (http://symfony.com/blog/new-in-symfony-2-8-ldap-component).

The checkAuthentication() (LdapBindAuthenticationProvider.php) seems to be only called when LDAP is configured as a firewall to check if credentials are correct. For that it's ok.

When LDAP is configured as a provider, a first bind is done with an "admin account" (search credentials: search_dn / search_password options) and then if the username which is trying to login is found, a new User is created in the loadUser() (LdapUserProvider.php).

The problem is that the User is created with a null password if the "admin account" used to search the user in the LDAP can't read the userpassword field (in the LDAP).
So instead of trying to read this field, it should try to login. If we can login successfully, it means the password is correct so we can use it to create the User.

[ChadSikorra]

Interesting, I think I understand the situation now. But isn't the User Provider only supposed to be responsible for loading a user? If it starts to do authentication checks via a bind it would also be doing the same job that the Authentication Provider does. I think this was discussed in the original PR for the LDAP component, as it originally did the bind for the user in the User Provider.

[csarrazi]

The user provider should not check authentication via bind. If a password is not provided by the user provider, then the password should be empty.

This is a limitation with how PHP works. The Ldap session is created on each request, and you cannot re-bind on another request without actually storing the user's credentials in a plaintext form.

Thus, re-authenticating as a the user to fetch his information on the next request will only be supported for HTTP-Basic.

You have two ways of working with Ldap :

• The bind authentication method (which is used in form_login_ldap and http_basic_ldap)
• The password comparison method, which is used for all other security authentication providers.

If you use a provider which does not use ldap_bind(), or a stateless provider which sends the credentials in a hashed form (and thus, not decryptable), then you need to make sure that your Ldap server will actually send back the user's password. Also, in this case, you need to create your own password encoder, as Ldap stores the password in a very specific encrypted form, containing:

• The hash algorithm
• The salt
• The encrypted password

For example, in the following userPassword attribute:

userPassword: {SSHA}MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0

SSHA is the hash algorithm.
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0 is the base64-encoded value of the {password}{hash} string.

If you base64-decode the string, then you obtain:

     SHA1 Hash      Salt
--------------------++++
123456789012345678901234

[csarrazi]

TL;DR: @Seb33300 If you want to authenticate your users using bind(), then you should use a Ldap authentication provider (form_login_ldap or http_basic_ldap). Other authentication mechanisms rely on password comparison, which should not be used unless your Ldap server actually returns the password in one of its attributes.

[csarrazi]

Ping @Seb33300. Can we close this issue?

[Seb33300]

I solved my problem by importing all users in my database schema as provider and using LDAP connection as a firewall only.

But I still think that even if LDAP is used as a provider, user password should be check by trying to connect.

[csarrazi]

Nope. Checking the password is the responsibility of the authentication provider, not the user provider.

If you want to check against the Ldap server, you can actually use both the user provider and the authentication provider. But for that, you need to use either form_login_ldap or http_basic_ldap in your firewall section.

Using any other provider will actually try to authenticate using password comparison.