Thanks for this. We have multiple LDAP implementations described in the wiki 
(https://wiki.roundup-tracker.org). It would be great to have one supported way
to do this. Also on our wish list is oauth/openid login (issue2551239).

A few questions:

  does ldap3 work with python2? It's ok if it doesn't but makes integration
     a little tricky.

  if it becomes a standard part of the trackers, init() should do nothing
     (leaving default login in place) unless the LDAP uri is configured.
     This way it can just hang out and do nothing by default.

  it looks like you only support the User and Admin role? IIUC the User role is added
      if the user is a member of a group listed in `user_groups` and similarly
      Admin role for admin_groups. Do you have ideas on handling more roles?

  it doesn't look like it falls back to native (db) based auth if ldap fails
     (server down, network issue). Am I correct?

  have you thought about authenticating API access (REST, XML-RPC) against LDAP?

The wiki LDAP (https://wiki.roundup-tracker.org/?
action=fullsearch&context=180&value=LDAP&titlesearch=Titles) implementations fall back
to local db auth (or use it first and check ldap on failure). They also
sync the password to the local db so API access and local db auth work.
The advisability of storing the password in the local db is another question.

Your suggestion forces me to consider if we need to register a stack of
validate_user possibilities. At this point we have 6 or more validators/tests that
hook into the login authentication chain:

  native db
  LDAP
  Oauth (someday 8-)
  TOTP/HOTP
  Allow login with email
  Captcha
  HIBP password validation (not verification)

Only native db is supported at this time for API access, but supporting LDAP
would be good as well. The rest make no sense for an API call. Sounds like it's time
to start looking at PAM again for design ideas.