LDAP authentication fails when the domain server response includes SearchResultReference(s)

I’m working on setting up an instance of airflow 2.0.0. Everything has been going smoothly. I have the web app integrated with my company’s Active Directory, users were able to login and were added to the default role upon first login.

Eager to plug into the new group --> role mappings feature (AUTH_ROLES_MAPPING) added in FAB 3.2.0, I upgraded FAB to 3.2.0. After the upgrade, users could no longer login.

I’ve sanitized some of the configuration and the log output below, but I believe it’s still legible.

Environment

Flask-Appbuilder version: 3.20 python-ldap version: 3.3.1 (I’ve also tested against every major version since and including 3.0.0)

relevant env variables:

AIRFLOW__LOGGING__FAB_LOGGING_LEVEL=DEBUG

webserver_config.py:

from flask_appbuilder.security.manager import AUTH_LDAP
import os

basedir = os.path.abspath(os.path.dirname(__file__))

WTF_CSRF_ENABLED = True

AUTH_TYPE = AUTH_LDAP
AUTH_ROLE_ADMIN = 'Admin'
AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = 'Viewer'

AUTH_LDAP_SERVER = '< santized >' 
AUTH_LDAP_SEARCH = '< santized >'

AUTH_LDAP_BIND_USER = '< santized >'
AUTH_LDAP_BIND_PASSWORD = os.getenv('AUTH_LDAP_BIND_PASSWORD')

AUTH_LDAP_UID_FIELD = 'sAMAccountName'
AUTH_LDAP_FIRSTNAME_FIELD = 'givenName'
AUTH_LDAP_LASTTNAME_FIELD = 'sn'
AUTH_LDAP_EMAIL_FIELD = 'mail'

AUTH_ROLES_MAPPING = {
    '< santized >': ["Admin"],
    '< santized >': ["User"],
}
AUTH_ROLES_SYNC_AT_LOGIN = True

AUTH_LDAP_GROUP_FIELD = "memberOf"

PERMANENT_SESSION_LIFETIME = 1800

Describe the expected results

I log into the web app. If this is a first time login, a user is created for me. I’m added to the default role, and the “Admin” and/or “User” roles if I am a member of the corresponding groups.

Describe the actual results

I attempt to login to airflow. I receive a message “Invalid login. Please try again”

In the logs I find the trace clipped below. Note in the line documenting the LDAP search result, there are two items returned. The first is actual entry for my user. The second is a search result reference, being included in the returned list as an tuple with a dn of None and an attributes list containing only the reference URI.

[2021-03-05 18:47:42,706] {manager.py:946} DEBUG - LDAP bind indirect TRY with username: '< AUTH_LDAP_BIND_USER  >'
[2021-03-05 18:47:42,741] {manager.py:952} DEBUG - LDAP bind indirect SUCCESS with username: '< AUTH_LDAP_BIND_USER >
[2021-03-05 18:47:42,741] {manager.py:877} DEBUG - LDAP search for '(sAMAccountName=mittleman)' with fields ['givenName', 'sn', 'mail', 'memberOf'] in scope '< AUTH_LDAP_SEARCH >'
[2021-03-05 18:47:42,743] {manager.py:883} DEBUG - LDAP search returned: [('< sanitized DN >', {'sn': [b'Mittleman'], 'givenName': [b'Dale'], 'memberOf': [< sanitized >], 'mail': [b'< sanitized >']}), (None, ['< sanitized SearchResultReference >'])]
[2021-03-05 18:47:42,743] {manager.py:889} ERROR - LDAP search for '(sAMAccountName=mittleman)' in scope '< AUTH_LDAP_SEARCH >' returned multiple results
[2021-03-05 18:47:42,743] {manager.py:1078} INFO - No LDAP object found for: mittleman

Cause

https://github.com/dpgaspar/Flask-AppBuilder/blob/55b0976e1450295d5a26a06d28c5b992fb0b561e/flask_appbuilder/security/manager.py#L880-L892

Notes

These SearchResultReferences are part of the LDAP standard, and so are not some one-off case specific to my setup.

From what I can tell, there’s no easy way for consumers of the python-ldap library to configure it to ignore these references. That means that it’s up to the consumer (in this case FAB) to be aware of the potential of SearchResultReferences being included in the raw ldap result, filtering them out or otherwise processing the list as needed.

Here’s an example of another python-ldap consumer doing something similar. They chose to discard the reference outright after a similar issue was raised on their repo.

I apologize but I’m not sure how exactly one would reproduce the issue for testing.

[potiuk]

And Airflow 2.0.2 constraints were updated / new images released (for a bit different reason) and they are both using FAB 3.1.1 for now (but we will pick-up FAB 3.2.3 when it is released.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Feel free to reopen it if it’s still relevant to you. Thank you