### Summary If LDAP is used as the authentication method, an `ldap_blocked` user will be unblocked on sign-in if the user is valid in LDAP. However, when a non-LDAP authentication method is configured alongside LDAP (such as Azure AD) and the user becomes `ldap_blocked` we do not recheck the LDAP user status on sign-in. ## Scenario User becomes `ldap_blocked` by either `LdapSyncWorker` (once daily) or the default 1-hour `sync_time`. This can happen either due to transient communication issues with LDAP, or maybe the user actually was disabled/removed from LDAP for a period of time. When signing in via another method, if the user is `ldap_blocked` we should proactively check with LDAP to see if the user is now active. If yes, unblock the user and allow sign-in. ## Problem This Solves In [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/18421), if the LDAP server is flaky or cannot be reached, users are immediately blocked, even when another authentication method is configured and status is maintained there. This was causing users to be unable to login, and a manual sync initiated by the customer had to take place in order to reset the users back to "active".