ping @csarrazi - this is one that I won't be able to right, without great trouble as I don't have any real LDAP experience. Are you able to add a document in the new 2 weeks?

You know that there is https://packagist.org/packages/org_heigl/zendldapbundle ? Is there really the need for another LDAP-Implementation?

@heiglandreas The LdapBundle you are mentioning does basically nothing, and does not expose all LDAP options. The goal here is to have a working basic LDAP implementation, which is used by the SecurityBundle for authenticating a user against a LDAP server.

@weaverryan Could do, but first, I need to finalize symfony/symfony#15994, as the Ldap API will actually change a lot before the final release.

@csarrazi I'm fully aware, that it does nothing except allowing a user to use Zend\Ldap inside symfony. As far as I know, there are some 3rd-party LDAP-Authentication bundles around but the last time I looked, there wasn't a full-featured LDAP-implementation. That's why I created that bundle.

So when I understand you right the new LDAP-component will have all the features necessary to authenticate a user but not necessary all features needed for full LDAP-usage?

In the long term, it will have all features for full LDAP usage.
However, for 2.8 / 3.0, only the binding and querying part will be ready. Updating, creating or removing LDAP entries will be for at least 3.1, depending on whether other people can help with this or not.

And provided we have users who actually want this feature.

Just out of interest: Wouldn't it be easier to combine forces on one LDAP-AL and use that in different frameworks instead of splitting the contributors over different implementations? I'm maintaining Zend\Ldap and currently I'm the only one doing any actual work on it. And as it's a part that is not that widely used or understood splitting the contributor-base to such an AL is IMO removing power from every single project. Wouldn't having one AL implemented by the different frameworks be a more powerfull solution?

@heiglandreas This would have been great. However, the main reason why I did not use Zend\Ldap is because of the error handler's after effects, as mentioned on zendframework/zendframework#7497.

Indeed, during my tests, Zend\Ldap used to break the Symfony error handler, which is not registered back after Zend\StdLib\ErrorHandler::start(E_WARNING). This causes issues for error logging, which made it impossible to understand what happened under the hood when using the Zend\Ldap due to not having error logs anymore.

If these issues are fixed at a later time, I would be glad to provide a bridge for using Zend\Ldap in Symfony, instead of the Ldap component. The reason why the component provides an interface is to be able to hook (if needed) a userland PHP implementation of LDAP, or a third-party component, like Zend\Ldap.

For the record, at first this component wasn't even supposed to exist. The implementation is very simple, and is intended to be kept simple.

Then let's join forces @csarrazi ;)

I'll dig into that issue with the error handler and check whether there is a way to get rid of the Zend\StdLib\ErrorHandler for Zend\Ldap.

Please don't get me wrong: Even though I'm maintaining Zend\Ldap I do not think it's the perfect AbstractionLayer. But it's there and with the contributor-base for LDAP being rather sparse I think it makes sense to try to keep one AbstractionLayer stable and current instead of creating multiple ones that after a brief intense period will rust away...

Ping @fabpot

When I wrote FR3DLdapBundle started using the PHP builting LDAP functions but I've found for to deal with the whole universe of LDAP vendors (Microsoft, Linux, ...) an abstraction layer is needed.

Then I thought I could maintain to versions and allow the developer to customize when use builtin functions or Zend\Ldap, finally I've found maintain the builtin functions is a waste of time.

I think it's possible to work in a single implementation and fix any issues.

Disclaimer: While I'm related to zendframework organization my experience with SF2 LDAP integration (FR3DLdapBundle) is previous to my relation with zend-ldap.

@csarrazi Most people open issues against my bundle asking why it's not possible use the credentials provided in the user form as credentials for perform LDAP search (search_dn , search_password)

I've to close those issues because input credentials are not available at the user provider time. Do you think this could be possible in a future SF version?

Nice to have LDAP built into the symfony core 👍

Worth a look is also the django.Ldap Extension which works quite well:
https://pythonhosted.org/django-auth-ldap/

It should be possible to port the abstraction layer @Maks3w mentions from python to PHP. At least OpenLDAP compard to ActiveDirectory seem to have diverged schemas from W2008 Server onwards.

Also a "nice to have" would be union searches, like search more than one base path:
https://pythonhosted.org/django-auth-ldap/authentication.html#search-unions

@Maks3w @heiglandreas Great discussion! :)

What we can do for now: For Symfony 2.8 / 3.0, let's keep the LDAP component as is (I mean with the current interface).

I'll try to see whether I can refactor the current PR to create a bridge from the current code, to keep compatibility with the current implementation.

Release 2.8 / 3.0 should not be delayed because of this.

By the way, @heiglandreas, you could also take a look at https://github.com/symfony/polyfill-php56, for simplifying your Dn::escape and AbstractFilter::escape polyfills, which implement PHP5.6's ldap_escape.

@csarrazi Thanks for pointing that one out! I'll first want to get the changes for the ErrorHandling in.

And I'm absolutely with you to not delay a scheduled release due to a possible different implementation. Though knowing where to go might enable everyone to tweak new code into a certain direction to make the transition easier when it comes to it.

When is the release after 3.0 scheduled?

The release after 3.0 would be scheduled around march 2016, which makes it a reasonable target.

ping @csarrazi

@weaverryan the documentation cannot be done until some decision is taken on PR symfony/symfony#15994

FYI, the component is now marked as internal (see symfony/symfony#16735).

Is this bundle still not ready to get some documentation?

First, it is not a bundle. Second, yes, it is mature enough (only the master branch). I am currently working on this.

@xabbuh I think this should not be in the 2.8 milestone, but rather in the 3.1.

@csarrazi Excuse my ignorance. It is a component, right?

No problem, @Dragnucs! 😃
A component it is, indeed!

@csarrazi One more stupid question. How should I configure the app.ldap service when I use class: Symfony\Component\Ldap\Ldap. I can't figure out how to give it the interface it asks for.

Which version of Symfony are you using? 2.8/3.0? Or 3.1/master?

I am using Symfony 3.0.3 and Symfony\Ldap dev-master

app.ldap:
        class: Symfony\Component\Ldap\Ldap
        factory: ['Symfony\Component\Ldap\Ldap', 'create']
        arguments:
            - 'ext_ldap'
            - host: 'host.mydomain.com'

In short, you should use Ldap::create($adapterName, $config) to create your Ldap instance.

However, if you are using Symfony 3.0, you should instead use the LdapClient, which is backward-compatible with Symfony 3.0 / 2.8.

In that case, you should use new LdapClient($host) to instanciate the class.

app.ldap:
        class: Symfony\Component\Ldap\LdapClient
        arguments: ['host.mydomain.com']

Using the Ldap class just generates more errors for me. I'll just stick with the LdapClient for the moment until the full doc is available. Thank you.

As mentioned, if using Symfony 2.8 or 3.0, you should use LdapClient, and not Ldap. Note that when upgrading to Symfony 3.1, you will have to upgrade use the Ldap class instead.

@csarrazi Please would you mind prompting a way to use Ldap component with custom User class. What I need is to authenticate users in LDAP, but load their roles and some attributes from other source (e.g. database).
Is it possible to use Ldap component this way?
AFAIK, LdapUserProvider.php is hardcoded to use:

public function supportsClass($class)
    {
        return $class === 'Symfony\Component\Security\Core\User\User';
    }

Oh, I think I have found the answer: I should use Ldap component only as authenticator and create custom user provider to fetch user data from DB.

@trofimchouk Exactly!

Basically, all you need to do is use the form_login_ldap or http_basic_ldap authentication provider, with a user provider which fetches user info from another source! :)

Hi,
I was trying to use this new LDAP component, as I realized that in the old 2.8 had the issue of not detecting when LDAP might return an array of each attribute and in the new one look like it was fixed.
Probably I'm doing some mistake on the configurations, but I've found the same issue on the LdapUserProvider, the method loadUser is still supplying an array as password to the User constructor, causing Ldap to fail to authenticate the user (as a null password is given on binding). As well as on the refreshUser method clearly a null is being provided as a password instead of calling $user->getPassword().

I have done a quick (and a little bit ugly fix) on my own fork to confirm this was the issue and indeed after ensuring that a password is always provided it worked.

So, can you confirm if this is a bug or I missed to tune some setting? If it is a bug I can make a pull request.

Thanks.

This indeed looks like a bug. Could you file an issue on symfony/symfony?

I found this after submitting #6795 but I can separate my question if it is confusing to the general discussion here.

The LDAP documentation doesn't answer the main question of data safety. Unless I'm missing something, which if I am my apologies.

Basically, my question is on the safety implemented in the component. The Doctrine chapter does a good job of explaining and providing references to parameterized queries and how SQL injection is handled. Where is the responsibility for protecting against, or at least mitigating, LDAP injection attacks? Is that solely on the developer or does the component provide some of that functionality? Can that be made more clear in the documentation?

After reading all this, I am a little confused as to whether I should be using Ldap or LdapClient in Symfony 3.2.3. My goal is to use the form_login_ldap and the ldap user provider if possible. I am using Microsoft AD. If not, I will implement my own user provider. I'm pretty new to Symfony.

You should be using Ldap rather than LdapClient. While both will work, only the Ldap class will be supported onwards, and will add new features.

Closing it as "fixed". The basic docs are online (https://symfony.com/doc/current/components/ldap.html) and the better docs are pending to be merged (#6982).