Bind failing when domain set as base

[glibdud]

I'm having trouble getting my Plone installation connected to my Active Directory server for authentication. I'm able to set it up successfully if I choose an OU as the "Users/Groups container DN", e.g. "ou=site1,dc=mycompany,dc=com" (SUBTREE scope, which I am using for everything). And I can successfully change the "Groups container DN" to the base domain ("dc=mycompany,dc=com") and it still seems happy. However when I try changing the "Users container DN" to the base domain ("dc=mycompany,dc=com"), I get a bind error:

ERROR: LDAP users; {'desc': 'Operations error', 'info': '000004DC: LdapErr: DSID-0C09072B, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580'}

The credentials are fine, though, as evidenced by the fact that everything else works, and if I fudge them, I get a more customary "invalid credentials" error no matter what I try to do.

I did a quick query via python-ldap from an interactive console and was able to search from the base domain just fine with the same bind credentials, so it doesn't appear to be an issue with our server config or user permissions. I've about reached the extent of my troubleshooting ability here... not sure whether this is specific to pas.plugins.ldap or node.ext.ldap or what.

Versions: pas.plugins.ldap = 1.5.1 node.ext.ldap = 1.0b3 python-ldap = 2.4.28 Plone = 4.2.1.1 Zope = 2.13.16 Python = 2.7.3 OS = SLES11 SP3

[glibdud]

As mentioned, setting Group container DN to the domain does not cause an error in the configuration page. However it does generate an error (same one) when you actually try to load the Users and Groups page. Adding the OU to both the Users and Groups container DNs allows the Users and Groups page to load, and it pulls the LDAP users/groups as expected. However, I need to pull users/groups from multiple top-level OUs.

[alexsielicki]

This is affecting me too. I need to search across all the OUs, but when I omit OU in the "Users container DN" field, the site freezes and nothing works. Any ideas on a workaround? Thanks!

[glibdud]

Well, the ping from the above comment made me dig into this some more. As it turns out, my claim that it was working fine in plone-ldap was false. I have no idea how I got it to work before, but I'm not able to duplicate the success anymore. After a bit more digging, I discovered that this is a well enough known phenomenon that it's in the python-ldap FAQ:

Q: My script bound to MS Active Directory but a a search operation results in an exception ldap.OPERATIONS_ERROR with the diagnostic messages text "In order to perform this operation a successful bind must be completed on the connection.". What's happening here?

A: When searching from the domain level MS AD returns referrals (search continuations) for some objects to indicate to the client where to look for these objects. Client-chasing of referrals is a broken concept since LDAPv3 does not specify which credentials to use when chasing the referral. Windows clients are supposed to simply use their Windows credentials but this does not work in general when chasing referrals received from and pointing to arbitrary LDAP servers. Therefore per default libldap automatically chases the referrals internally with an anonymous access which fails with MS AD. So best thing is to switch this behaviour off:

  l = ldap.initialize('ldap://foobar')
  l.set_option(ldap.OPT_REFERRALS,0)

I verified that the suggested fix works (for me, at least). However, I'm not aware of any way to set python-ldap options in pas.plugins.ldap, so I'm going to leave this issue open in case someone wants to run with it.

(Edit: I don't see any way to set options in node.ext.ldap, either, at first glance. It may need to be addressed there before anything could be done here anyway.)

[rnixx]

@glibdud Thanks for pointing this out. This needs to be handled in node.ext.ldap

[therealdirk]

Hi, I ran into the same issue. Don't blame me, but is it possible to add the workaround in a Plone installation where pas.plugin.ldap/node.ext.ldap was installed via buildout or do I have to build and install a custom version of node.ext.ldap? If I can add the workaround without a custom version of node.ext.ldap, which file do I have to modify?

[rnixx]

@dirk12345ger https://github.com/bluedynamics/node.ext.ldap/issues/30#issuecomment-295102407

Since I'm quite busy ATM it's unlikely that I'll fix this soon, PR's welcome.

[jensens]

close here, follow up at with https://github.com/bluedynamics/node.ext.ldap/issues/30