symfony: LDAP Form Authentication dn_string substitution broken?

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	???
RFC?	no
Symfony version	3.4
Due to deprecation warnings I replaced stuff in security/firewalls, security/providers.
Actually the substitutuion of ‘{username}’ in dn_string of the firewalls doesn’t seem to have any effect anymore.

https://symfony.com/doc/3.4/security/ldap.html suggests the following:

# app/config/security.yml
security:
    # ...

    firewalls:
        main:
            # ...
            form_login_ldap:
                # ...
                service: Symfony\Component\Ldap\Ldap
                dn_string: 'uid={username},dc=example,dc=com'

if I place

dn_string: 'CN={username},OU=Users,DC=my,DC=domain,DC=de'

{username} won’t be replaced.

see the Exception:

LdapException
HTTP 500 Internal Server Error
Could not complete search with dn "CN={username},OU=Users,DC=my,DC=domain,DC=de", query "(&(memberof:1.2.840.113556.1.4.1941:=CN=MyGroup,OU=Groups,DC=my,DC=domain,DC=de))" and filters "*".

Looking at the code there is something different happening to dn_string then to query_string.

https://github.com/symfony/symfony/blob/3.4/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Security/Factory/FormLoginLdapFactory.php#L37

For now I’m fine with removing CN={username}, from the config, but either it’s a bug/issue or a wrong documentation.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15 (12 by maintainers)

Commits related to this issue

minor #11454 [Ldap] minor: better query string docs (Simperfit) This PR was submitted for the master branch but it was merged into the 3.4 branch instead (closes #11454). Discussion ---------- [Lda... — committed to symfony/symfony-docs by javiereguiluz 5 years ago

Most upvoted comments

and maybe a PR on better validation of the config too

lsmith77 on Mar 19, 2018

would be great if the result of this discussion would be a PR on the docs

lsmith77 on Mar 19, 2018

@Pocketstealer You forgot to add the dn_string in your configuration, which is required.

How this works:

If you only provide dn_string, the {username} placeholder is replaced by the actual username provided by the user in the form or http basic prompt. No prior search will be performed before binding the LDAP username.
If you provide both dn_string and query_string:
- the authentication provider will perform an anonymous search using:
  - dn_string as its base DN
  - query_string as the actual query
- the {username} placeholder will only be replaced in query_string there, meaning that you should not use {username} in the dn_string, and you must override that value (its default value is actually {username} so of course, that won’t work.
- the search performed will return the actual DN of the user, which will then be used for bind.

In any case, I do agree that this feature is not perfect by any means, is poorly documented (actually, it is still not documented). But you are always free to contribute (to either the docs or the component itself) and solve it in a more elegant way 😃

csarrazi on Mar 16, 2018