[BUG] Issue with ldap authentication when using salt-api

[duncanupton]

Description In both 3006.8 and 3006.9 when trying to use ldap authentication for salt-api there is an error we get related to python-ldap module even though python-ldap is installed. The error is in the /var/log/salt/master file.

2024-08-27 08:08:57,417 [salt.loaded.int.auth.ldap:341 ][ERROR ][326502] LDAP authentication requires python-ldap module

Setup additional settings in salt-master: rest_cherrypy: port: 8080 ssl_crt: /etc/pki/tls/certs/localhost.crt ssl_key: /etc/pki/tls/certs/localhost.key

external_auth: ldap: root: - '*' added these settings in ldap.conf in /etc/salt/master.d auth.ldap.server: localhost

Port to connect via

auth.ldap.port: 389

Use TLS when connecting

auth.ldap.tls: False

Use STARTTLS when connecting

auth.ldap.starttls: False

LDAP scope level, almost always 2

auth.ldap.scope: 2

Server specified in URI format

auth.ldap.uri: '' # Overrides .ldap.server, .ldap.port, .ldap.tls above

Verify server's TLS certificate

auth.ldap.no_verify: False

Bind to LDAP anonymously to determine group membership

Active Directory does not allow anonymous binds without special configuration

In addition, if auth.ldap.anonymous is True, empty bind passwords are not permitted.

auth.ldap.anonymous: False

FOR TESTING ONLY, this is a VERY insecure setting.

If this is True, the LDAP bind password will be ignored and

access will be determined by group membership alone with

the group memberships being retrieved via anonymous bind

auth.ldap.auth_by_group_membership_only: False

Require authenticating user to be part of this Organizational Unit

This can be blank if your LDAP schema does not use this kind of OU

auth.ldap.groupou: 'Groups'

Object Class for groups. An LDAP search will be done to find all groups of this

class to which the authenticating user belongs.

auth.ldap.groupclass: 'posixGroup'

Unique ID attribute name for the user

auth.ldap.accountattributename: 'memberUid'

These are only for Active Directory

auth.ldap.activedirectory: False auth.ldap.persontype: 'person'

auth.ldap.minion_stripdomains: []

Redhat Identity Policy Audit

auth.ldap.freeipa: False

I then started salt-master and salt-api I did not configure a ldap server to communicate with as the issue appears to be loading the python-ldap module. That said a customer I am working with on this issue did have an ldap server that was properly configured and they are also getting the error.

Please be as specific as possible and give set-up details.

• [x ] on-prem machine
• [ ] VM (Virtualbox, KVM, etc. please specify)
• [ ] VM running on a cloud service, please be explicit and add details
• [ ] container (Kubernetes, Docker, containerd, etc. please specify)
• [ ] or a combination, please be explicit
• [ ] jails if it is FreeBSD
• [ ] classic packaging
• [ x] onedir packaging
• [ ] used bootstrap to install

Steps to Reproduce the behavior (Include debug logs if possible and relevant)

Run a command such as curl -sSk https://:8080/login -H 'Accept: application/x-yaml' -d username= -d password= -d eauth=ldap

Expected behavior A clear and concise description of what you expected to happen. ldap auth should be used by salt-api calls and we should not get this error message.

Screenshots If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report

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

salt-call pip.list local: ---------- CherryPy: 18.10.0 Jinja2: 3.1.4 MarkupSafe: 2.1.2 PyJWT: 2.9.0 PyYAML: 6.0.1 SSEAPE: 8.16.1.3 certifi: 2024.7.4 cffi: 1.14.6 charset-normalizer: 3.2.0 cheroot: 8.5.2 contextvars: 2.4 croniter: 2.0.5 cryptography: 42.0.5 distro: 1.5.0 idna: 3.7 immutables: 0.15 importlib-metadata: 6.0.0 jaraco.classes: 3.2.1 jaraco.collections: 3.4.0 jaraco.functools: 2.0 jaraco.text: 3.5.1 jmespath: 1.0.1 lief: 0.15.1 looseversion: 1.0.2 more-itertools: 5.0.0 msgpack: 1.0.2 packaging: 22.0 pika: 1.3.2 pip: 23.3.2 portend: 2.4 psutil: 5.8.0 pyOpenSSL: 24.0.0 pyasn1: 0.6.0 pyasn1_modules: 0.4.0 pycparser: 2.21 pycryptodomex: 3.19.1 python-dateutil: 2.8.1 python-gnupg: 0.4.8 python-ldap: 3.4.4 pytz: 2022.1 pyzmq: 23.2.0 relenv: salt-master --versions Salt Version: Salt: 3006.9

Python Version: Python: 3.10.14 (main, Jun 26 2024, 11:44:37) [GCC 11.2.0]

Dependency Versions: cffi: 1.14.6 cherrypy: 18.10.0 cryptography: 42.0.5 dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.4 libgit2: Not Installed looseversion: 1.0.2 M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed packaging: 22.0 pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.19.1 pygit2: Not Installed python-gnupg: 0.4.8 PyYAML: 6.0.1 PyZMQ: 23.2.0 relenv: 0.17.0 smmap: Not Installed timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.4

Salt Extensions: SSEAPE: 8.16.1.3

System Versions: dist: centos 9 locale: utf-8 machine: x86_64 release: 5.14.0-496.el9.x86_64 system: Linux

My customer is also running 3006.8 but I do not have their versions report (can get it though if needed)

PASTE HERE

Additional context Add any other context about the problem here.