We have seen a few questions like this where something changes about the LDAP server and ALM cannot get to the LDAP server or cannot login to it, and therefore cannot authenticate ALM users.

See this previous post about how to revert to the original QC-Authentication behavior (temporarily) while you "fix" the LDAP issue.

Keep in mind:  You will need to have a QC User that is also a "Site Admin" user, AND you need to know their password that was used with QC Authentication.  At ALM install-time, the installing person specified an "admin" user and password.  This may have been documented somewhere and you just have not been using that user since enabling LDAP.  Also, if you just happened to have a site admin user or two that happen to have the SAME LDAP userID as QC-Authentication user, they may be able to remember/use their old password that was used BEFORE enabling LDAP-authentication.

https://eyeontesting.com/answers/all-users-are-receiving-cannot-authenticate-errors-after-long-weekend/#gsc.tab=0

TIP:  If you DO end up getting in to Site Admin with QC-authentication and "fix" the LDAP settings, make SURE to use a separate IE tab/instance to test login behavior.  If you leave your QC-auth Site Admin open, it will still work -- even though there might be an issue with the LDAP settings, allowing you to go back easily and fix them.

This is great, but nobody remembers the old QC-auth password.

Can you help?

There is a discussion about blanking out a user password for use with QC-Authentication here:

https://eyeontesting.com/answers/all-users-are-getting-an-error-message-when-trying-to-login-to-alm-failed-to-login/#gsc.tab=0

From the database end you can able to change the LDAP authentication to Local authentication. Afterwards you can able to login with your Local Credentials.