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

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.

• 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
• 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://<ip addr>:8080/login -H 'Accept: application/x-yaml' -d username=<user name> -d password=<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-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:
        <incomplete copy and paste>

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

Additional context
Add any other context about the problem here.

Start by comparing the Python environment used by salt-master and salt-api with the packages reported by salt-call pip.list, then inspect /var/log/salt/master while reproducing the LDAP login request. Check the LDAP settings in /etc/salt/master.d/ldap.conf and the salt-master configuration. Done means the request no longer reports a missing python-ldap module and LDAP authentication proceeds.