Continuously need to user other user to login

Question

Continuously need to user other user to login

Peter Alexandris 45

I have several users at our organization that after signing back in after locking the screen when they attempt to login they get incorrect user or password but when they select other user and login they have no issues. This is on an org domain and it is EVERY single time they try to sign it, it requires to sign in as other. Has anyone seen an issue like this or know where to even find a solution?

0 comments

Answer accepted by question author

2 additional answers

Your answer

Answer 1

Jason Nguyen Tran 14,440 Independent Advisor

Hello Peter Alexandris,

What you’re describing usually points to how Windows is caching credentials during the lock/unlock process in a domain environment. In many cases, the cached session tries to reuse the last token but fails, which is why the unlock attempt shows “incorrect user or password,” even though the credentials themselves are fine.

One practical step is to check whether the affected machines are properly syncing with the domain controllers and that Kerberos tickets are being refreshed correctly. If the trust relationship between the workstation and the domain is unstable, this behavior can appear every time. Another area to review is Group Policy, sometimes policies around interactive logon or credential delegation can interfere with the unlock process. Rejoining one of the affected machines to the domain is a good test to confirm if the trust is the root cause.

Since this is happening consistently across multiple users, I’d also recommend checking the event logs on both the client and domain controller side for authentication errors around the time of the failed unlock. That will give you a clearer picture of whether it’s a local cache issue or a domain replication problem. In short, the accounts themselves are fine, but the cached session is failing, so focusing on domain trust and policy settings should help resolve it.

I hope the response provided some helpful insight. If it clarified the issue for you, please consider marking it as Accept Answer so others can benefit too. Thank you!

Jason.

Peter Alexandris 45 Reputation points

2026-02-27T16:25:28.7433333+00:00

how do I check if kerberos tickets are refreshed correctly?
Jason Nguyen Tran 14,440 Reputation points Independent Advisor

2026-02-27T16:32:09.8966667+00:00

To check whether Kerberos tickets are being refreshed correctly, you’ll want to look at both the client side and the domain controller side. On a client machine, you can open a Command Prompt and run klist—this will show you the currently cached Kerberos tickets, their expiration times, and whether they are renewing as expected. If you see tickets that are expired or not refreshing, that’s a sign the workstation isn’t properly communicating with the domain controller.

Another useful test is to run klist purge to clear cached tickets, then lock/unlock the machine and run klist again to confirm a fresh ticket is issued. On the domain controller, you can check the Security logs for Kerberos authentication events (Event IDs 4768 and 4769 are the most relevant). These will tell you if the DC is issuing tickets when the client requests them. Also, make sure the workstation and domain controller clocks are in sync, Kerberos is very sensitive to time drift, and even a few minutes of difference can cause tickets to fail.

You can try these steps and let me know if you need further information. Don't forget to accept the answer if you issue has been resolved.
Ľuboš Nikolíni 0 Reputation points

2026-04-07T19:00:24.82+00:00

We have been facing exactly same issue as Peter on Entra ID Joined PCs.
Peter Alexandris 45 Reputation points

2026-04-07T20:23:42.3+00:00

Thanks the issue had resolved itself

Answer 2

Jason Nguyen Tran 14,440 Independent Advisor

Hello Peter Alexandris,

I’m following up to check whether the issue has been resolved.

If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

0 comments

Answer 3

This behavior typically indicates a sign-in/authentication problem tied to the cached credentials or the way Windows is handling domain authentication after the device is locked, rather than a true bad password.

Use the following steps to narrow down and resolve it:

Confirm the account is healthy in AD
- Verify the affected users’ domain accounts are not locked out, expired, or restricted by logon hours.
- If needed, reset the user’s password once and test again.
- See guidance under “Make sure that the account isn't locked out, expired, or used outside designated logon hours” in the federated sign-in article.
Restart devices and domain controllers
- Restart one of the affected client devices and test again.
- If the issue is widespread and recent (for example, after an update), restart all domain controllers. A similar sign-in issue in a domain environment was resolved by restarting all DCs.
Test with another account on the same device
- On an affected PC, sign in with a different domain user.
- Lock/unlock and see if the same “incorrect user or password” appears.
- If only specific users are affected, focus on those AD accounts; if all users on that device are affected, focus on the device and its trust to the domain.
Check for sign-in problems at the OS level
- If users intermittently cannot sign in at all, try a full restart of the device, as this can clear temporary sign-in issues.
- If problems persist, boot one affected device into Safe Mode with Networking and test sign-in. If Safe Mode works reliably, a driver, security product, or GPO may be interfering with normal logon.
Verify domain trust and cached credentials
- On an affected device, ensure it is still joined to the correct domain and can reach a domain controller (network connectivity, DNS, etc.).
- If the device repeatedly fails normal logon but “Other user” works every time, consider removing the machine from the domain and rejoining it (plan this carefully, as it affects all domain profiles on that PC).
Check for repeated sign-in attempts and lockouts
- If users are retrying many times, Microsoft Entra multifactor authentication or security policies may temporarily block sign-in after multiple attempts. In hybrid scenarios, review sign-in logs and ensure MFA or conditional access is not misconfigured.

If the issue continues after these steps, collect event logs from affected machines and domain controllers (Security and System logs around the time of the failed unlock) and review for Kerberos or authentication errors, then escalate through support with those details.

References:

Share via

Continuously need to user other user to login

2 additional answers

Your answer