Using Directory top as base, gives a DSID-0C0907C2

[MrMEEE]

Hi

If I define anything but the directory top as a base, the plugin works perfectly.. but when I define the top, I get a:

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0907C2, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580', 'desc': 'Operations error'}

Playbook:
---
- hosts: localhost
  vars_files:
    - ../vaults/credentials.yml
  roles:
  - quinot.lookup_ldap
  vars:
    # Default context
    ldap_lookup_config:
      url: ldap://ad.example.com
      base: dc=example,dc=com
      binddn: CN={{ username }},OU=Exclusive Accounts,DC=example,DC=com
      bindpw: "{{ password }}"
      scope: subtree
    users:
      base: DC=example,DC=com
      key: name
      value:
        - jpegPhoto: skip=True
      filter: "(|(name=u1*)(name=c1*)(&(objectclass=User)))"
  tasks:
  - name: 
    debug: msg="User {{ item }}"
    with_ldap:
      - context: users
      - value:
        - name: encoding=utf-8
      - "{{ lookup('env', 'USER') }}"

Domain names has been replaced..

[MrMEEE]

This seems to be the same issue: https://github.com/collective/pas.plugins.ldap/issues/37

[MrMEEE]

I have tried putting:

lo.set_option(ldap.OPT_REFERRALS,0)

inside

quinot.lookup_ldap/lookup_plugins/ldap.py:174

Seems to change the error: An exception occurred during task execution. To see the full traceback, use -vvv. The error was: AttributeError: 'list' object has no attribute 'get'

Not sure what that means

[MrMEEE]

From the python-ldap docs: Q: My script bound to MS Active Directory but a a search operation results in the 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, the best thing to do is to switch this behaviour off:

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

.. still doesn't solve the second issue