ldap.managed does not handle operational attributes

[fpicot]

Description of Issue

It doesn't seem possible to handle operational attributes through ldap.managed. This makes impossible to managed things like the schema or the ACIs.

Setup

test.sls

ldap_aci:
  ldap.managed:
    - connect_spec:
        url: ldap://127.0.0.1:389/
        bind:
          method: simple
          dn: <bind dn>
          password: <password> 
    - entries:
      - ou=test_ou,dc=customers,dc=contoso,dc=com:
        - add:
            aci:
              - (target="ldap:///ou=test_ou,dc=customers,dc=contoso,dc=com")(targetattr=*)(version 3.0; acl "Test ACI"; allow (all) userdn="ldap:///dc=customers,dc=contoso,dc=com??sub?(ou=admins)";)

Steps to Reproduce Issue

First run :

          ID: ldap_aci
    Function: ldap.managed
      Result: True
     Comment: Successfully updated LDAP entries
     Started: 10:35:51.097713
    Duration: 14.805 ms
     Changes:
              ----------
              ou=test_ou,dc=customers,dc=contoso,dc=com:
                  ----------
                  new:
                      ----------
                      aci:
                          - (target="ldap:///ou=test_ou,dc=customers,dc=contoso,dc=com")(targetattr=*)(version 3.0; acl "Test ACI"; allow (all) userdn="ldap:///dc=customers,dc=contoso,dc=com??sub?(ou=admins)";)
                  old:
                      ----------

Second run, test=True

          ID: ldap_aci
    Function: ldap.managed
      Result: None
     Comment: Would change LDAP entries
     Started: 10:36:45.861559
    Duration: 7.419 ms
     Changes:
              ----------
              ou=test_ou,dc=customers,dc=contoso,dc=com:
                  ----------
                  new:
                      ----------
                      aci:
                          - (target="ldap:///ou=test_ou,dc=customers,dc=contoso,dc=com")(targetattr=*)(version 3.0; acl "Test ACI"; allow (all) userdn="ldap:///dc=customers,dc=contoso,dc=com??sub?(ou=admins)";)
                  old:
                      ----------

Second run, test=False

    Function: ldap.managed
      Result: False
     Comment: failed to modify entry ou=test_ou,dc=customers,dc=contoso,dc=com(exception in ldap backend: TYPE_OR_VALUE_EXISTS({'desc': 'Type or value exists'},))
     Started: 10:36:01.201478
    Duration: 22.851 ms
     Changes:

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 2018.3.4

Dependency Versions:
           cffi: 1.6.0
       cherrypy: Not Installed
       dateutil: 1.5
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Nov  1 2018, 03:12:47)
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.3.1
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 3.2.5

System Versions:
           dist: oracle 7.6
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-862.11.6.el7.x86_64
         system: Linux
        version: Oracle Linux Server 7.6

[fpicot]

This should be fairly easy to fix by conditionally passing "attrlist=[b'+']" to ldap3.search.
The condition would a new state parameter "operational_attrs", defaulting to false.
I'll submit a PR later today

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[stale]

Thank you for updating this issue. It is no longer marked as stale.