authentication issue between tow windows server 2025 (SMB /RDP)

Question

authentication issue between tow windows server 2025 (SMB /RDP)

Mohamed Atef Abdrabou Elessawy 25

when i try to access share/RDP from one server to another , the server keep asking me about user an password (authentication loop) , however the user and password are correct , same issue for domain and local user , no firewall between them .

Nathan C. Arnold 0 Reputation points

2026-02-05T18:41:12.9033333+00:00

Please post an update. Were you able to resolve this issue?

3 answers

Your answer

Nathan C. Arnold 0 Reputation points

2026-02-05T18:41:12.9033333+00:00

Please post an update. Were you able to resolve this issue?

Answer 1

I am not sure if anyone is still having issues with this, but I found this event ID in the event log which prompted me to do some searching, event id 6167 there is a partial mismatch in the machine id.

This leads you to articles talking about clone VMs and not making sure that a full sysprep is being done. Make sure you have a local admin password set on the affected machines before doing so.

Here is the command I ran - sysprep.exe /generalize /oobe /mode:vm /shutdown

Once completed I powered back on the VM and logged in as the local admin. Rejoined it to the domain and continued to configure my servers.

Hope this helps someone who is having a similar issue that I was.

Chris

Answer 2

Jason Nguyen Tran 24,550 Independent Advisor

Hi Mohamed Atef Abdrabou Elessawy,

Just checking in, were you able to get the issue resolved? If so, it would be great if you could mark the answer as Accepted so others in the community can benefit from your experience. Thank you!

0 comments

Answer 3

Jason Nguyen Tran 24,550 Independent Advisor

Hi Mohamed Atef Abdrabou Elessawy,

An authentication loop when accessing shares or RDP, even with correct credentials, usually points to a Kerberos or NTLM authentication problem rather than a firewall or password mismatch. Common causes include mismatched DNS resolution, duplicate SPNs (Service Principal Names), or time synchronization issues between the servers. Verify that both servers can resolve each other’s names correctly and that their clocks are synchronized within five minutes, as Kerberos is sensitive to time drift.

For RDP, ensure that the Network Level Authentication (NLA) setting is consistent across both servers. For file shares, check whether the target server is enforcing NTLM restrictions or requires Kerberos only. Running klist purge and then reconnecting can also help clear cached tickets. If the issue persists, reviewing the Event Viewer > Security logs on the target server will provide more detail on which authentication method is failing.

I hope this helps clarify the situation. If you find this answer useful, please hit “Accept Answer” so I know your issue is resolved 😊. Thank you!

Jason.

Mohamed Atef Abdrabou Elessawy 25 Reputation points

2026-01-19T14:57:37.98+00:00

hi Jason
unfortunately the issue not solved , even after trying all these steps
Jason Nguyen Tran 24,550 Reputation points Independent Advisor

2026-01-19T15:17:17.2066667+00:00

Hi

Thank you for letting me know the issue persists even after the initial troubleshooting steps. Since the standard checks (DNS resolution, time sync, NLA, NTLM settings, and credential cache clearing) did not resolve the authentication loop, the next step is to look deeper into security policies and channel bindings introduced in Windows Server 2025. In particular, SMB and RDP now enforce stricter Credential Guard and Extended Protection for Authentication (EPA) settings, which can cause repeated credential prompts if the servers are not aligned.

I recommend verifying whether Credential Guard or EPA is enabled on one server but not the other, and ensuring both are configured consistently. Additionally, check if Kerberos delegation is required for your scenario and confirm that the Service Principal Names (SPNs) are correctly registered. Running setspn -L <servername> can help identify duplicate or missing SPNs. If the loop continues, enabling Netlogon and Kerberos logging will provide more detailed traces of the failed authentication attempts.

If this is impacting production, a temporary workaround is to force NTLM authentication by adjusting the Local Security Policy > Network security: LAN Manager authentication level, though I recommend this only for testing to confirm the root cause.

I hope these next steps help you move closer to a resolution. And don't forget to “Accept Answer” so I know your concern is resolved.

Jason.