[BUG] LDAP auth fails and authz group search continues recursively

[dforste]

What is the bug? When people are in some groups in LDAP they get permission denied and authz continues group search until restarted.

How can one reproduce the bug? Steps to reproduce the behavior:

1. Create security config of:

---
_meta:
  type: config
  config_version: 2
config:
  dynamic:
    http:
      anonymous_auth_enabled: false
    authc:
      internal_auth:
        order: 0
        description: HTTP basic authentication using the internal user database
        http_enabled: true
        transport_enabled: true
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal
      ldap_auth:
        order: 1
        description: Authenticate using LDAP
        http_enabled: true
        transport_enabled: true
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - freeipa-1.example.com:389
            - freeipa-2.example.com:389
            - freeipa-3.example.com:389
            bind_dn: uid=svc_opensearch,cn=users,cn=accounts,dc=idm,dc=example,dc=com
            password: ...
            userbase: cn=users,cn=accounts,dc=idm,dc=example,dc=com
            usersearch: "(uid={0})"
            username_attribute: uid
    authz:
      ldap_roles:
        description: Authorize using LDAP
        http_enabled: true
        transport_enabled: true
        authorization_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - freeipa-1.example.com:389
            - freeipa-2.example.com:389
            - freeipa-3.example.com:389
            bind_dn: uid=svc_opensearch,cn=users,cn=accounts,dc=idm,dc=example,dc=com
            password: ...
            userbase: cn=users,cn=accounts,dc=idm,dc=example,dc=com
            usersearch: "(uid={0})"
            username_attribute: uid
            skip_users:
            - admin
            - kibanaserver
            - kibana_server
            - logstash_internal
            - gitlab_manager
            - nrpe
            rolesearch_enabled: true
            rolebase: cn=groups,cn=accounts,dc=idm,dc=example,dc=com
            rolesearch: "(member={0})"
            userroleattribute:
            userrolename: none
            rolename: cn
            resolve_nested_roles: true

2. Attempt to login with a user that is a member of one of a specific group. Some group memberships cause this behavior and others do not. It is unclear what about the group is causing this behavior.

What is the expected behavior? I expect one of two things:

1. User is authenticated without any groups. (This happens when there is an error in authz config.)
2. Wait until group search has been exhausted and allow the user based off found roles.

What is your host/environment?

• OS: RHEL 9/Docker
• Version 3.4.0
• Plugins

Do you have any screenshots? If applicable, add screenshots to help explain your problem.

Do you have any additional context? I also requested help on the forum.

Example Repeating log entry:

DBGTRACE (10): escapedDn cn=bastion,cn=groups,cn=accounts,dc=example,dc=com
result nested attr count for depth 30 : 0
Results for LDAP group search for cn=bastion,cn=groups,cn=accounts,dc=example,dc=com in base convertedOldStyleSettings:
[]

DBGTRACE (10): escapedDn cn=bastion,cn=groups,cn=accounts,dc=example,dc=com
result nested attr count for depth 29 : 0
Results for LDAP group search for cn=bastion,cn=groups,cn=accounts,dc=example,dc=com in base convertedOldStyleSettings:
[]