I'm troubleshooting two Windows 11 25H2 test machines that behave differently when connecting to an RDP host. After authenticating to the client, Machine B connects to the remote host without asking for credentials again, but Machine A displays another remote login prompt every time. Both systems are domain joined, and neither currently has credentials saved in Credential Manager. They are also virtualized with virtualization-based security disabled.
The main known difference is that Machine A has the Microsoft Security Baseline applied, while Machine B does not. I compared the relevant Group Policy and registry settings but haven't found the setting responsible. The "Always prompt for password upon connection" policy was enabled on Machine A, and setting `HKLMSOFTWAREPoliciesMicrosoftWindows NTTerminal ServicesfPromptForPassword` to `0` and rebooting did not resolve the prompt.
What other policies or authentication differences should I check to determine why credentials are delegated successfully from Machine B but not Machine A?
3 Answers
The security baseline may be enforcing the behavior, but the Terminal Services prompt setting is only one part of the process. Generate an effective policy report with `gpresult /h report.html` on both clients and compare the results, especially under Computer Configuration → Administrative Templates → System → Credentials Delegation. That section contains policies controlling whether the RDP client can delegate or use default credentials.
Also compare the patch level, connection method, target name, DNS resolution, and network path. Kerberos delegation can fail if one machine connects using a name that doesn’t map correctly to the target’s SPNs, or if the connection goes through an RD Gateway. If Kerberos cannot be used, the client may fall back to NTLM and prompt again.
Use the effective policy and event logs to isolate whether the issue is a client policy restriction or a Kerberos problem. On each machine, compare `gpresult` output for the Microsoft Security Baseline and the entire Credentials Delegation policy area rather than just checking the settings manually. Also verify that both clients are fully patched and launch the connection the same way—directly with `mstsc.exe`, through an `.rdp` file, RDWeb, or an RD Gateway.
If the policies match but the behavior differs, check the target name, DNS, SPNs, clock synchronization, and authentication events. Credential Guard or another security-baseline control could also restrict delegation, although it is less likely if virtualization-based security is definitely disabled.
Check whether the two clients are actually negotiating the same authentication method. Confirm that both are connecting to the same hostname or FQDN rather than one using an IP address or alias, then inspect the Kerberos and NTLM events in the relevant security logs. A mismatched SPN, DNS issue, time skew, or different route through an RD Gateway can prevent Kerberos from working even when the machines appear to have identical policies.
The Credentials Delegation policies are a better place to focus than Credential Manager. Storing a generic credential might bypass the prompt, but it weakens the security model and can expose credentials if the target identity is spoofed, so it should not be treated as the normal fix.
Both systems are domain joined, and neither has saved credentials. Virtualization-based security is disabled on both. I’m comparing the effective policies and connection details next to determine why only the baseline-protected client fails to pass through the credentials.
The password-prompt policy was set to `1` on Machine A. Changing it to `0` and rebooting left it at `0`, but the RDP prompt still appears, so I’m now investigating credential delegation and the authentication protocol.