Repeated logins inserting duplicate records about fr3dldapbundle HOT 25 CLOSED

Check the order of your user provider chain. It's necessary to have FOSUserBundle before FR3DLdapBundle

from fr3dldapbundle.

I've changed the order back to that, but then I get bad credentials after the first successful login. I'm guessing it's because there's now a row in my users table with no password entry.

from fr3dldapbundle.

Is it fr3d_ldap: ~ present in your firewall?

from fr3dldapbundle.

Yes. Here's the firewall section for my application.

    firewalls:
        main:
            pattern:    ^/
            fr3d_ldap:  ~
            form_login:
                provider: chain_provider
#                always_use_default_target_path: true
#                default_target_path: /profile
            logout:
                path: /logout
                invalidate_session: true
            anonymous:  true
            remember_me:
                key:      %secret%
                path:     /
                domain:   ~ # Defaults to the current domain from $_SERVER
                secure:   true
                httponly: true

from fr3dldapbundle.

Try to remove the old user and start from a clean state again.

from fr3dldapbundle.

I've done that several times. I've even gone as far as deleting the database and recreating it via Doctrine. It always has the same result where the first authentication works and the second one fails.

from fr3dldapbundle.

Have you disabled password encodig?

encoders:
      AcmeBundle\Acme\User\LdapUser: plaintext

from fr3dldapbundle.

I had the following encoders section:

    encoders:
        FOS\UserBundle\Model\UserInterface: sha512

I tried replacing it with my user entity and plaintext, but it didn't work. I tried removing it entirely, but that also didn't work (it produced a 'No encoder has been configured for account "MyTools\MyBundle\Entity\User"' error).

from fr3dldapbundle.

Well, we'll need to debug your issue.

What version of this budle are you using?

Look for this file FR3DLdapBundle/Security/Authentication/LdapAuthenticationProvider.php

Debug $user, this is for check if the user is found in the LDAP directory.

$user = $this->userProvider->loadUserByUsername($username);

If ok, then we will debug if the credentials bind are ok. Add var_dumps on each bind method (there are two)

$this->ldapManager->bind($user, $presentedPassword)

Take special attention for the value of the first parameter and second. The second, the password, must be exactly as you typed in the login form.

from fr3dldapbundle.

I'm using the 2.0.x branch and I'm running on Symfony 2.2.

'I stuck a var_dump() call in there immediately after the loadUserByUsername. It returns my User entity I created and its data is pre-populated correctly.

I then stuck additional var_dump() calls with the three exceptions in the checkAuthentication() function (for thoroughness). The second bind is failing, indicating that the presented password is invalid. I then dumped the presented password and it is correct. That did make me wonder something, however. My password is a rather long, complex string with a variety of punctuation including a quotation mark. To eliminate that as a potential variable, I temporarily changed my password to something a lot simpler and shorter. The issue persisted, so it does not appear to be character based.

Just in case it will help, here's a slightly edited version of my User entity (removing non-relevant code and comments):

<?php

namespace MyTools\MyBundle\Entity;

use FR3D\LdapBundle\Model\LdapUserInterface;
use FOS\UserBundle\Entity\User as BaseUser;
use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity(repositoryClass="MyTools\MyBundle\Entity\Repository\UserRepository")
 * @ORM\Entity
 * @ORM\Table(name="users")
 */
class User extends BaseUser implements LdapUserInterface
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer", name="user_id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * Ldap Object Distinguished Name
     * @var string $dn
     */
    protected $dn;

    public function __construct()
    {
        parent::__construct();
        // your own logic
    }

    /**
     * Get id
     *
     * @return integer 
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * {@inheritDoc}
     */
    public function getDn() 
    {
        return $this->dn;  
    }


    /**
     * {@inheritDoc}
     */
    public function setDn($dn) 
    {
        $this->dn = $dn;
    }
}

from fr3dldapbundle.

Is the same username in all that binds? Try to turn false the following setting

fr3d_ldap:
  driver:
    bindRequiredDn:       false

from fr3dldapbundle.

I apologize, but I'm afraid I don't understand the first question.

When I try and enable the bindRequiredDn property, I get an error: InvalidConfigurationException: Unrecognized options "bindRequiredDn" under "fr3d_ldap.driver"

from fr3dldapbundle.

Sorry, the config key is bindRequiresDn

What I was asking is if username is the same in both binds?

from fr3dldapbundle.

Setting the bindRequiresDn to false causes the initial login to fail as well as all subsequent.

For your question, I traced the login code to the ZendLdapDriver's bind() function and captured the $bind_rdn variable for both a successful login and a failure. On the successful login, it is using the full DN. On the failed logins, it is not using a DN and is, instead, using just my username. I also output the $user->getDn() call and verified it's returning an empty string. I did some additional tracing after that, but I'm not sure how much is useful to you, so I'll leave it out to avoid clutter. Please let me know if you have any suggestions on where to check next.

from fr3dldapbundle.

The second time is this call? $this->ldapManager->bind($currentUser, $currentUser->getPassword())

If true. What's the value of $token->getCredentials() in that line?

from fr3dldapbundle.

I did some rough testing and it appears that $token->getCredentials() contains my valid password in both a successful and failed login attempt. I did my testing in the checkAuthentication() function again.

from fr3dldapbundle.

Ok. The problem is that LDAP passwords are not saved against the DB so the User entity password is empty

@beittenc Do you want send a patch against to master branch fixing the issue? Replacing $currentUser->getPassword() with $token->getCredentials()

from fr3dldapbundle.

Just to make sure I'm following, are you suggesting I change the following in LdapAuthenticationProvider?

if (!$this->ldapManager->bind($currentUser, $currentUser->getPassword())) {

Change that to:

if (!$this->ldapManager->bind($currentUser, $token->getCredentials())) {

If so, that change doesn't work. In the cases where the failure occurs, the $currentUser variable is a string and not an instance of UserInterface, so that bind code above is never triggered.

from fr3dldapbundle.

I had a few minutes to do some more experimentation today and it seems to come down to the DN not getting populated properly when the user comes back into the system. I modified my User entity so that the DN would be persisted to the database. Once I did this, repeated logins started working for me. I hadn't done this previously because it wasn't indicated that I needed to do this in the docs and it seems counterintuitive to me since LDAP is supposed to be my system of record in this case, not my bundle. Does this help in determining the cause?

from fr3dldapbundle.

In 2.0 branch UserLdapInterface is optional and only is useful for avoid to do two searchs of the username (one for the user provider and one more for authenticataion)

I didn't tested so much the cases which SF2 decide revalidate the user. Also I think that this part has been modified since SF2.

If you remove the UserLdapInterface from your UserEntity works?

In theory this lines should detect the case which getDn is empty https://github.com/Maks3w/FR3DLdapBundle/blob/2.0.x/Driver/ZendLdapDriver.php#L66

Can you paste a var_dump of your getDn return?

from fr3dldapbundle.

Removing the LdapUserInterface from the class has no effect.

If I remove persistence of the DN to the database, the getDn() call returns nothing. When an existing user is retrieved, the setDn() function is never called as far as I can tell.

from fr3dldapbundle.

I'm encountering the same issue. 2.0.x branch, similar config, and persisting the dn solved the problem. Is there anything I can do to help debug?

from fr3dldapbundle.

I modified my path in order to make it generic

    /*********************************
     * LOUSY PATCH
     * 
     * The line 
     *           $user = $this->userManager->createUser();
     * is the only one from the original code
     *  
     ***********************************/
    global $kernel;
    $user = $kernel->getContainer()->get('doctrine.orm.entity_manager')->getRepository('ApplicationSonataUserBundle:User')
            ->findOneByUsername($criteria[$this->ldapAttributes[0]]);
    if ($user === null) {
        $user = $this->userManager->createUser();
    }
    /*         * ***************************************
     * END **********
     *************************************/

from fr3dldapbundle.

Looks @mogoman found how to solve this #31 (comment)

fixed this by adding the following lines to the config under the driver section

bindRequiresDn: true

from fr3dldapbundle.

Since opening this, I've changed companies and am no longer working on a project that needs this module. If you're satisfied that #31 solves this, then we can close this.

from fr3dldapbundle.