Description of problem:
Our base issue is an inability to log in with LDAP users, provided by a Microsoft AD.  When they attempt to log in, they are greeted with "Invalid username/password", however the logs show we hit this condition 
with an empty matching_groups set:

module Authenticator
  class Base
- - - - - 8< - - - - -
    def authorize(taskid, username, *args)
      audit = {:event => "authorize", :userid => username}
      decrypt_ldap_password(config) if MiqLdap.using_ldap?

      run_task(taskid, "Authorizing") do |task|
        begin
          identity = find_external_identity(username, *args)

          unless identity
            msg = "Authentication failed for userid #{username}, unable to find user object in #{self.class.proper_name}"
            _log.warn(msg)
            AuditEvent.failure(audit.merge(:message => msg))
            task.error(msg)
            task.state_finished
            return nil
          end

          matching_groups = match_groups(groups_for(identity))
          userid, user = find_or_initialize_user(identity, username)
          update_user_attributes(user, userid, identity)
          user.miq_groups = matching_groups

          if matching_groups.empty?
            msg = "Authentication failed for userid #{user.userid}, unable to match user's group membership to an EVM role"
- - - - - 8< - - - - -

Reviewing the logs and the appliance, and adding our own debugging, we found that our matching_groups set from match_groups() was due to an empty set being returned by groups_for for the identity provided.  In match_groups, since we are supplied an empty set, we bail early in the method:

    def match_groups(external_group_names)
      return [] if external_group_names.empty?
- - - - - 8< - - - - -

However, in the groups_for method, we return an empty set every time, which causes us to fall through to matching_groups.empty? in the base authorize method, causing the error/exception.

module Authenticator
  class Ldap < Base
- - - - - 8< - - - - -
    def groups_for(obj)
      authentication = config.dup
      authentication[:group_memberships_max_depth] ||= DEFAULT_GROUP_MEMBERSHIPS_MAX_DEPTH

      if authentication.key?(:user_proxies) && !authentication[:user_proxies].blank? && authentication.key?(:get_direct_groups) && authentication[:get_direct_groups] == false
        _log.info("Skipping getting group memberships directly assigned to user bacause it has been disabled in the configuration")
        groups = []
      else
        groups = ldap.get_memberships(obj, authentication[:group_memberships_max_depth])
      end

      if authentication.key?(:user_proxies)
        if (sid = MiqLdap.get_attr(obj, :objectsid))
          authentication[:user_proxies].each do |auth|
            begin
              groups += user_proxy_membership(auth, MiqLdap.sid_to_s(sid))
            rescue Exception => err
              _log.warn("#{err.message} (from Authenticator#user_proxy_membership)")
            end
          end
        else
          _log.warn("User Object has no objectSID")
        end
      end

      groups.uniq
    end

In the above, we have no user_proxies and by default get_direct_groups is false, so we start by assigning groups as an empty set.  Since we have no user_proxies, we skip user_proxy_membership and the group set remains blank.  Unless we set get_direct_groups to true under the authentication section of the advanced settings, which causes get_memberships on the ldap object to run, we will always return an empty set unless user_proxies are also in place.

With the end goal of having as fast and efficient, as well as working, LDAP logins being possible, a few questions:

- What is the purpose of get_direct_groups in this context?
- In order for authorization to function when doing group lookups, when get_direct_groups is set to false, do we always expect there to be a user_proxies setting?
- Is the solution to this to ensure get_direct_groups is set to true so appropriate LDAP lookups can be performed for each login?
- Is there some other thing I am missing concerning how we validate groups so that we do not get an empty set when validating a user's authorization?

Version-Release number of selected component (if applicable):
5.9.2.4

How reproducible:
Every time, while get_direct_groups is false.  Works when get_direct_groups is true.

Steps to Reproduce:
1. In their environment, connect AD to CFME environment.
2. Accept defaults and map groups to EVM roles appropriately
3. Be unable to log in

Actual results:
Users are unable to log in unless get_direct_groups is set.

Expected results:
Logins should match users to groups as expected under the correct default conditions, if what we are utilizing is correct and nothing special.

Additional info:
We have validated the groups returned by the AD by basic tests such as ldapsearch from the appliance.