Require LDAP check everytime the user login into the system

[tfernandez]

Hello guys,

First thanks for all the work you have made with this bundle, it is saving me a lot of work and your effort is awesome.

I have several symfony2 applications working with the ldap integration and I find a serious problem. If I remove an user from the LDAP database the user can still access without problems to all the symfony2 applications because the user has been created in the fos_user system, and it is neccesary remove it manually from all the applications.

Is there a way to require a ldap check everytime the user is trying to login in the application? maybe implement some config options to let the developer decide if the ldap check should be done in every login, or even in a "cookie/session" login if the user checked the remember me checkbox?

Thanks

[Maks3w]

Have you checked if fred_ldap: ~ is present in your firewall config?

In theory the user can't log in because there is no way to check the password since the user not longer exists in LDAP.

[tfernandez]

Ok, you have scaried me thinking in a critical security hole in my applications hehe, fortunately I'm safe :).

Yes that line is in the firewall config.

You are totally right, I was not deleting the user but changing his group, when I actually delete the user he cannot login anymore :) however a problem persists and is related with the fredldap filters, an ldap existing user can always login into the symfony application if he has been authenticated succesfully once even if you have change his group after that first login. I will write an example:

Firstly I set the fredldap filter to "(ou=family)"

    fr3d_ldap:
     filter: (ou=family)" at config.yml

Now the cases:

1

• I create a ldap user without a group or in a wrong group
• The user tries to login
• He cannot login
• All is OK

2

• I change the user group to "family"
• The user tries to login
• He gets login succesfully
• All is OK

3

• I change the previous user from group "family" to group "enemies"
• The user tries to login
• The user gets login succesfully
• Wrong! (Even clearing symfony2 app cache and restarting apache just in case was a caching problem)

4

• I remove the user from the symfony2 application database "user" table (FOSUserBundle) (but still exists in the ldap database in the group "enemies")
• The user tries to login
• The user cannot login
• ¿OK?

I think if the user is in the symfony2 app database (the user logged in once succesfully) the ldap filters are not being applied in the ldap query to authenticate the user.

If the user does not exists in the symfony2 app database all works properly but if the user group is changed after login for first time the filters have not effect. (presumably)

What could be happening?

Thanks for your time!

[Maks3w]

Try turning on

  bindRequiresDn:      true

In the driver section in the config

That should to do a new search for the entity

[tfernandez]

Ok, I've tested it and the problem is still there :(, also I cleared the cache after add the bindRequiresDn in the config.yml

[Maks3w]

Ok. Well, your use case is a bit adhoc. The best option is configure your LDAP for avoid user binding if the user is in certain groups.

Does not have sense to have a central point for manage accounts but later relay in each application for to do the security checks.

Anyway, If your only option is change the behavior of the bundle feel free to send a contribution with your patch. The most important code that you should touch is here https://github.com/Maks3w/FR3DLdapBundle/blob/2.0.x/Security/Authentication/LdapAuthenticationProvider.php

[tfernandez]

So do you think the ldap filter option in the fr3dldap bundle is useless? I have all the user centralized in the ldap and the permissions (or groups) are modified in the ldap to grant access to different applications depending on the ldap group, and sometimes I want drop the access to one application to some user only changing the ldap permissions and handle it with the fr3dldapbundle filter option, I think that makes sense and many companies do it. Maybe I didn't explain it rightly.

So the right way is have a consistent filters implementation in the bundle. But I understand you have no time to all the needs, so maybe I try to contribute :)

Thank you very much for your time, it is very appreciatted

[athanasius-kircher]

I have ran into the same problem and dived into the code. As Maks3w explained there is an option to work around it by using: bindRequiresDn: true, but that need some more settings to force the bundle to grep the account data again (I do not exactly proofed that with the FOS User bundle, but it should be the same problem as in my situation).

1. Do not store the DN in your user db or let the DN getter in the user return an empty string. Otherwise for existing users ZendLdapDriver::bind will fetch the data from the user object directly
2. Use the driver config accountFilterFormat additionally to the user filter config and add the group filtering here again (can look something like (&(uid=%s)(ou=family))), because only this filter is applied in this bind situation
3. Set bindRequiresDn: true as mentioned before.

Alternative Idea Maybe I will propose an implementation for this general refactoring:

• the problem I see, is that the LdapAuthenticationProvider uses the central user provider config (here often a chain_provider)
• let the LdapAuthenticationProvider only use LdapUserProvider so it will always load its users from ldap again
• move the logic for fetching already persisted accounts to the hydrator, maybe by injecting the DB User provider(or whatever one uses) in the hydrator