The above question and the reply thread below was originally posted in the Community Help Track. On Fri May 24 03:20 UTC 2019, a member of the HCC moderation staff moved it to the Security track. The Community Help Track is intended for questions about using the HCC site itself.
Bill Brooks, Community Moderator Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.
@jingyong zou you should not use AUTH_LDAP_APPEND_DOMAIN unless your users are authenticating using the fully qualified principal name as in "email@example.com" instead of simply "username". If you use uid or samAccountName as AUTH_LDAP_UID_FIELD (as is the case with OpenLDAP, IPA or AD) then this is not needed,
Also check the values for the parameters AUTH_USER_REGISTRATION=True and AUTH_USER_REGISTRATION_ROLE which should be set to a valid role in Superset (Public, Gamma, Alpha o Admin).
Another not very documented parameter which may be important depending on your LDAP setup is AUTH_LDAP_USERNAME_FORMAT, check this also.
With the previous advises in mind, check carefully the following documentation articles and you may be able to find your appropiate options combination to make LDAP work with Superset:
A tcpdump capture in your Superset server + wireshark analysis may be also of much help to debug what is your current Superset config sending to the LDAP server. In my case this was the "final step" to fit all the pieces.
Ditto on the need. I filled in all the fields in Ambari (in a Kerberized cluster) and no luck. Is there supposed to be any logging somewhere other than /var/log/superset/superset.log to show either issues or attempts to login?
Turning on debug mode showed a little bit of additional information and eventually got me to look at the code and added a few debug lines of my own to /usr/hdp/current/superset/lib/python3.6/site-packages/flask_appbuilder/security/manager.py in _search_ldap to show the filter_str and username being passed to the LDAP search. I saw the filter_str was set to userPrinicipalNamefirstname.lastname@example.org, so I got rid of the @our.domain adding AUTH_LDAP_APPEND_DOMAIN, but that still didn't work. I finally remembered that Ranger used sSAMAcountName as an AD search name,so I changed add AUTH_LDAP_UID_FIELD as sAMAccountName and poof, LDAP logins work. Note: Ambari settings aren't saved where the command line version can find them until I saved and restarted superset in Ambari, then stopped it again so I could run it interactively to see the debug logging.
I'm busy and lazy, so I didn't start removing other settings to see what I needed or didn't need, so here are the settings that worked for me. Our cluster is Kerberized and uses self signed certificates.
How would you check logs related to ldap , In mine all docker-container like superset_app , superset-worker showing no error, but i can't be able to log from normal user either or ldap one My configured things