RDP and User Principal Name (UPN) format or the fully qualified domain name (FQDN)

Question

RDP and User Principal Name (UPN) format or the fully qualified domain name (FQDN)

SSE@TUE 160

Hi,

the RDP client by defaults to using the User Principal Name (UPN) format (******@domain.com) or the fully qualified domain name (FQDN) instead of the NetBIOS domain name (DOMAIN\user).

My RDP Client use sometimes the User Principal Name (UPN) format and not the NetBIOS domain name (DOMAIN\user), therefore I cannot connect to the Remote machine, it says wrong password.

Regards

Nick

2 answers

Your answer

Answer 1

Henry Mai 6,505 Independent Advisor

Hello SSE, I am Henry and I want to share my insight about your issue.

I see the issue, where modern RDP clients default to UPN-based Kerberos authentication, which can fail if the server-side configuration is incorrect. The fact that a reboot of the remote machine temporarily fixes it points to a specific root cause.

Please refer to the action plan outlined below:

Part 1: Client-Side Fixes

If you need to connect immediately, you can force the RDP client to use the older NetBIOS/NTLM authentication method.

Force NetBIOS Format: In the RDP client, explicitly enter the username as DOMAIN\username instead of ******@domain.com.
Clear Cached Credentials: On your local computer, go to Credential Manager > Windows Credentials and remove any saved entries for the remote machine.
Edit the .RDP File: For a more permanent workaround, open your saved .rdp file in Notepad and add the following line to the end: enablecredsspsupport:i:0 This forces the client to use a more basic authentication provider that is less prone to Kerberos issues.

Part 2: Server-Side SPN Correction Fixes

To ensure UPN logons work reliably without requiring reboots, you must validate the Service Principal Name (SPN) for the Remote Desktop service in Active Directory.

Check for Missing or Duplicate SPNs: On a Domain Controller (or using RSAT), open an administrative Command Prompt and run the following commands:
- To check for duplicates across the entire forest: setspn -X ( Look for any conflicts related to TERMSRV/YourRemoteMachineName)
- To list the SPNs registered to the remote machine: setspn -l YourRemoteMachineName (You MUST see TERMSRV/YourRemoteMachineName and TERMSRV/YourRemoteMachineName.domain.com in the list.)
Repair the SPN: If the SPNs are missing or incorrect, register them with these commands:
- setspn -A TERMSRV/YourRemoteMachineName YourRemoteMachineName
- setspn -A TERMSRV/YourRemoteMachineName.domain.com YourRemoteMachineName

If this guidance helps, feel free to click “Accept Answer” to let us know we're on the right track.

SSE@TUE 160 Reputation points

2025-09-17T14:19:32.1833333+00:00

Hi Henry,

I have checked all options you recommend me, no error and nor duplicate SPNs,

run the following command

setspn -X

Processing entry 3

found 0 group of duplicate SPNs.

my remote machine is called: evaixtest

run the following command

setspn -l evaixtest

RDP Client has explicit that format DOMAIN\username

any Idea?

I have 3 DCs with Windows Server 2016 and 2019 and 2025.

Is that DCs with different Version the issue?

Regards
Henry Mai 6,505 Reputation points Independent Advisor

2025-09-17T15:19:23.6433333+00:00
Thank you for performing those checks and providing the detailed output.

First, to answer your direct question:

Is that DCs with different Version the issue?

No, having mixed DC versions (2016, 2019, 2025) is a fully supported scenario and is not inherently the problem. However, it can sometimes expose underlying issues, especially with different default settings for security protocols and Kerberos encryption types.

Given that the SPNs are correct, the intermittent nature of the problem (fixed by a reboot of the remote machine) points to one of two highly likely culprits: a broken Secure Channel or a Kerberos-related issue like time skew or token size.

Here is the next set of diagnostic steps to find the root cause.

Solution 1: Test and Repair the Secure Channel

On the remote machine (evaixtest), open PowerShell as an Administrator.

Run the following command to test the secure channel: Test-ComputerSecureChannel

If this command returns False, the channel is broken. To fix it, run the repair command: Test-ComputerSecureChannel -Repair -Credential (Get-Credential) You will be prompted for domain administrator credentials to perform the repair. If this command returns True, the secure channel is now healthy.

Solution 2: Check for Time Synchronization Issues

If the clock on evaixtest is more than 5 minutes out of sync with the domain controller it's trying to authenticate against, all Kerberos (UPN) logons will fail with a "wrong password" error.

On the remote machine (evaixtest), open a Command Prompt as an Administrator.

Run this command to check the time difference with the domain: w32tm /stripchart /computer:yourdomain.com /samples:5 (Replace yourdomain.com with your actual domain name)

Look at the Offset. If it is greater than a few seconds, you have a time sync problem.

To force an immediate resynchronization, run: w32tm /resync /force
SSE@TUE 160 Reputation points

2025-09-17T15:37:26.2633333+00:00

Dear Henry,

Thank you again for replay again. Believe me, I have tested with PW

Test-ComputerSecureChannel=true

ComputerSecureChannel -Repair -Credential (Get-Credential)

The time is in the registry set. And I have checked the time many times, the time is correct and is synced with domain correctly.
Henry Mai 6,505 Reputation points Independent Advisor

2025-09-17T15:58:03.9433333+00:00
Hello, Thank you for the follow-up. Your guess about the new Windows Server 2025 DC is almost correct. The problem is not that your SPNs are wrong, but that the type of encryption used for the Kerberos ticket is likely incompatible between the 2025 DC and the evaixtest machine.

Here is the sequence of events:

Your RDP client requests a connection to evaixtest using your UPN.

evaixtest contacts a Domain Controller to get a Kerberos ticket for you.

Intermittently, it contacts the new 2025 DC.

The 2025 DC issues a ticket using a strong, modern encryption type (like AES256).

The evaixtest server, for some reason, cannot decrypt or validate this newer ticket type, causing the authentication to fail with a "wrong password" error.

When you reboot, the server's Kerberos ticket cache is cleared. It might then happen to contact an older 2016/2019 DC, which provides a ticket with an older, more compatible encryption type (like RC4-HMAC), and the login succeeds.

Not sure you try to enable Modern Encryption Support on the Computer Account. You can refer these steps:

On a Domain Controller, open Active Directory Users and Computers.

In the View menu, make sure "Advanced Features" is checked.

Navigate to the OU containing your evaixtest computer, right-click on it, and select Properties.

Go to the Attribute Editor tab.

Scroll down and find the attribute msDS-SupportedEncryptionTypes.

Click Edit. It is likely set to <not set> or a low number. You need to explicitly enable AES.

Enter the value 24 and click OK.

Technical Detail: This value is a bitmask. 8 enables AES128 and 16 enables AES256. 24 (8 + 16) enables both, which is the recommended setting.

Click Apply and OK.

On the evaixtest machine, either reboot it or run gpupdate /force from an administrative command prompt to apply the change.

Answer 2

SSE@TUE 160

Hi Henry,

Thank you again for your help and replay. I am really sure the DC 2025 is the issue.

But I cannot understand why the DC 2025 cannot work with my existing DC 2016/2019. Do you mean because of AES256?

Now my questions an you

should upgrade all the 2016/2019 DCs to the new DC 2025?
Is that issue after above step resolved?
The DC 2016 holds at the time all FSMOs.

Should I do that on all DCs?

I did go the OU containing my Remote machine "evaixtest" and right-click on it and Properties and go to the Attribute Editor

selected the msDS-SupportedEncryptionTypes

I see the following value

User's image

Is that Ok or should I change it to the value 24? Which value is default by 2025?

Henry Mai 6,505 Reputation points Independent Advisor

2025-09-18T16:08:34.9266667+00:00
Hello, Sorry for late response.

Thank you again for your follow-up and for performing that check. I see that the msDS-SupportedEncryptionTypes value on evaixtest is already 28 proves that my previous theory was incorrect.

The value 28 for msDS-SupportedEncryptionTypes is a bitmask that means 16 (AES256) + 8 (AES128) + 4 (RC4-HMAC). This confirms your evaixtest server is explicitly configured to support both modern AES encryption and the older, more compatible RC4 encryption. This proves the problem is not with the evaixtest server. It is ready and willing to accept any type of Kerberos ticket.

Now, to answer your specific questions:

Should I change the value to 24? No. Changing it from 28 to 24 would remove support for the compatible RC4 encryption, which could actually make the problem worse.

Why can't the 2025 DC work with my 2016/2019 DCs? It can and absolutely should. A mixed-version DC environment is fully supported. The issue is not a fundamental incompatibility, but rather a new, stricter security default that the 2025 DC is enforcing.

Should I upgrade all the 2016/2019 DCs to 2025? No, this is not necessary and is not the solution to this problem.

Should I do this on all DCs? The msDS-SupportedEncryptionTypes attribute is set on computer and user accounts, not on the Domain Controller policies themselves. The settings for the DCs are controlled by their own computer accounts and by Group Policy.

Since evaixtest is correctly configured, our focus now shifts to the Windows Server 2025 DC itself. The problem is that the 2025 DC is likely configured with a new default policy that refuses to issue older, more compatible Kerberos tickets (like RC4), even though the client (evaixtest) says it can accept them.

You will need to check the Group Policy being applied to your new Domain Controller.

On a Domain Controller, open the Group Policy Management console (gpmc.msc).

Find the "Default Domain Controllers Policy" or any other GPO that is applied to the "Domain Controllers" OU. Right-click it and select Edit.

Navigate to the following location: Computer Configuration > Policies > Administrative Templates > System > Kerberos

Look for a policy named "Configure encryption types allowed for Kerberos".

If this policy is configured, ensure that it includes RC4_HMAC_MD5. If it's enabled but RC4 is missing from the list, this is the cause of the problem.

If the policy is "Not Configured," you may need to check the local policy on the 2025 DC itself using secpol.msc to see if there is a stricter local setting.
SSE@TUE 160 Reputation points

2025-09-19T05:40:43.1466667+00:00

Hi Henry,

Thank you again for your reply and Thank you very much for the detailed explanation.

I really appreciate it.

following location: Computer Configuration > Policies > Administrative Templates > System > Kerberos

It does not exist here

Did you means here, it is here "Not Configured,"

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

follow the secpol.msc on the Server 2025
Henry Mai 6,505 Reputation points Independent Advisor

2025-09-19T06:27:54.0933333+00:00
Yes, you're right - the Kerberos encryption policy is located under:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

From your second screenshot, I can see the policy is enabled and shows several encryption types including:

DES_CBC_CRC

DES_CBC_MD5

RC4_HMAC_MD5

AES128_HMAC_SHA1

AES256_HMAC_SHA1

Can you please check which of those encryption types are actually checked/selected in that policy window? From the screenshot, I can see the list but I need to know which ones have checkmarks next to them.

What we're looking for:

RC4_HMAC_MD5 should be checked (this is crucial for backward compatibility)

AES128_HMAC_SHA1 should be checked

AES256_HMAC_SHA1 should be checked

The root cause: If RC4_HMAC_MD5 is unchecked on your 2025 DC, this explains your intermittent RDP failures perfectly. When your client tries to connect using UPN format:

Sometimes it contacts a 2016/2019 DC → gets RC4 ticket → login works

Sometimes it contacts the 2025 DC → can't get RC4 ticket → "wrong password" error

Next steps:

Please confirm which encryption types are currently checked

If RC4_HMAC_MD5 is unchecked, we'll enable it

Run gpupdate /force on the 2025 DC

Test your RDP connection
SSE@TUE 160 Reputation points

2025-09-19T07:44:14.4966667+00:00

Sorry for my screenshot, the policy is not enabled and not defined, on all DCs

if I open the policy, I see the following options
Henry Mai 6,505 Reputation points Independent Advisor

2025-09-19T08:28:11.75+00:00
My apologies, I misinterpreted your screenshot. Knowing that the policy is Not Configured on all DCs explains everything perfectly.

The problem is not a misconfiguration in Group Policy, but a change in the default behavior of the operating system itself.

On Server 2016/2019: When the policy is "Not Configured," the default behavior is permissive. The DC will issue Kerberos tickets using older encryption like RC4_HMAC_MD5 if a client requires it.

On Server 2025: When the policy is "Not Configured," the new default security posture is much stricter. It likely refuses to issue RC4_HMAC_MD5 tickets, even if the client supports them.

You can refer the action plan:

On a Domain Controller, open the Group Policy Management console (gpmc.msc).

Find the "Default Domain Controllers Policy," right-click it, and select Edit.

Navigate to the policy location: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

Find the policy "Network security: Configure encryption types allowed for Kerberos" and double-click it.

Enable and configure the policy:

Check the box for "Define these policy settings."

In the list, check the boxes for all three of the following types:

RC4_HMAC_MD5 (This is for backward compatibility)

AES128_HMAC_SHA1

AES256_HMAC_SHA1

Click Apply and OK.

Close the Group Policy editor. Open an administrative Command Prompt and run gpupdate /force on each Domain Controller, especially the Server 2025 DC, to ensure the new setting applies immediately.
SSE@TUE 160 Reputation points

2025-09-19T10:39:20.5133333+00:00

Ok Henry, I will check it and let you know.

If I understand you correctly, on DCs 2016/2019/2022 is default "Not Configured," and we don't need to do anything. If the DC 2025 is added to the existing DCs with DCs 2016/2019/2022 , we have to configure the policy.

What do you mean with "Default Domain Controllers Policy,?

Do you mean that?

Regards and have a nice weekend
Henry Mai 6,505 Reputation points Independent Advisor

2025-09-21T09:42:48.2366667+00:00
Your understanding is correct:

On your older DCs, "Not Configured" worked fine because their default behavior was permissive.

The new, stricter default behavior of the Server 2025 DC requires you to explicitly configure the policy to ensure compatibility.

Now, regarding your screenshot, the policy you have highlighted, "Default Domain Policy," is NOT the correct one to edit. You can refer this document.

Default Domain Policy: This policy applies to all users and computers across your entire domain. You use it for domain-wide settings like password length and account lockout.

Default Domain Controllers Policy: This policy applies only to the computers in the "Domain Controllers" organizational unit (OU). Since we need to change the behavior of the Domain Controllers themselves, this is the correct policy to modify.

By editing the "Default Domain Controllers Policy," you ensure that this specific Kerberos setting only affects the DCs, which is exactly what we want.

To find the correct policy:

Open Group Policy Management.

In the left pane, expand your Forest, then expand Domains, then expand your domain.

You will see an Organizational Unit (OU) called Domain Controllers.

The "Default Domain Controllers Policy" is linked directly to that OU.

Have a wonderful weekend as well, and please let me know how it goes when you have a chance to apply the change.
SSE@TUE 160 Reputation points

2025-09-22T14:59:09.2866667+00:00

Hi Herny,

You are right, I I overlooked it.Step 4: The "Default Domain Controllers Policy" is not linked to any OU (see screenshot), it is linked to my DC himself

Share via

RDP and User Principal Name (UPN) format or the fully qualified domain name (FQDN)

2 answers

Your answer