Domain User Password Set through RDP

Question

Domain User Password Set through RDP

Himanshu Dwivedi 100

Hello,

I have an Active Directory domain environment with a Primary Domain Controller (PDC), a Secondary Domain Controller (SDC), and multiple client machines joined to the domain.

I have created several domain user accounts and configured them with the "User must change password at next logon" option. I have also configured a Remote Desktop Services (RDP) policy that allows all domain users to access client machines remotely.

However, when users attempt to log in via RDP for the first time, they receive an error message stating:

Please contact your administrator."

It appears that the RDP session is not prompting users to change their password, which is preventing them from logging in.

My requirement is for users to be able to change their own passwords through the Remote Desktop login process when logging in for the first time. I do not want to manually reset or change passwords from Active Directory on their behalf.

Could you please advise how to configure the environment so that users are prompted to change their password during an RDP login and can complete the password change themselves?

Thank you.

James Gamble 165 Reputation points

2026-09-16T18:39:14.61+00:00

Hola Himanshu,

What you're seeing is expected when Network Level Authentication (NLA) is enabled.

With NLA, the user has to authenticate before the full RDP session is created. Suppose the account is set to "User must change password at next logon." That can cause a problem because the password-change prompt normally appears after interactive logon begins. In other words, the user is being asked to change the password before RDP has created the part of the session that can display that prompt.

A quick way to confirm this is to temporarily disable NLA on one test machine and try the same first logon again. If the user is then prompted to change the password, you've confirmed the cause.

Microsoft documents NLA behavior here.

I wouldn't recommend leaving NLA disabled as the long-term fix, since it provides an important layer of protection for RDP. The better approach is usually to have the user change the temporary password through another supported method before their first RDP connection.

If this is direct RDP to domain-joined client machines, there isn't a separate Active Directory setting that forces the password-change dialog to appear before NLA completes.

Thanks,

James
Himanshu Dwivedi 100 Reputation points

2026-09-16T18:44:29.55+00:00

NLA is already disabled, still not working
James Gamble 165 Reputation points

2026-09-16T18:59:28.4333333+00:00
Hola Himanshu,

Thanks, that rules out the first thing I would normally check.

If NLA is already disabled and the user still isn't being prompted to change the password, I wouldn't keep chasing the NLA setting. The issue is more likely in how the RDP logon is handling the forced password-change state.

Microsoft documents that accounts marked "User must change password at next logon" are put into a special password-expired state. During an interactive console logon, Winlogon can hand the user over to the password-change workflow. RDP doesn't always handle that first-logon transition cleanly, even with NLA disabled.

Microsoft has documented a related behavior where the password-change operation uses RPC over named pipes/SMB during this flow.

At this point, I would check two things for one affected client.

First, verify that the RDP session is actually reaching the target machine and that the failure isn't occurring earlier in the credential provider path.

Second, test whether the user can change the password outside of RDP, for example, from another domain-joined machine with: Ctrl+Alt+Del > Change a password

If that works, then AD itself is fine, and the problem is specific to the first-logon RDP workflow.

One other test that's worth doing is connecting with an .rdp file that disables CredSSP:

enablecredsspsupport:i:0

That forces the connection to use the older RDP security path rather than pre-authenticating via CredSSP. I wouldn't treat that as the final security configuration, but it's a good diagnostic because it tells us whether CredSSP is the piece preventing the password-change UI from appearing.

If you can post the exact error message the user sees when NLA is disabled, that would help narrow this down further. The wording matters here because Windows uses different messages depending on whether the failure is coming from CredSSP, Winlogon, or the password-change RPC call.

Thanks,

James

1 answer

Your answer

James Gamble 165 Reputation points

2026-09-16T18:39:14.61+00:00

Hola Himanshu,

What you're seeing is expected when Network Level Authentication (NLA) is enabled.

With NLA, the user has to authenticate before the full RDP session is created. Suppose the account is set to "User must change password at next logon." That can cause a problem because the password-change prompt normally appears after interactive logon begins. In other words, the user is being asked to change the password before RDP has created the part of the session that can display that prompt.

A quick way to confirm this is to temporarily disable NLA on one test machine and try the same first logon again. If the user is then prompted to change the password, you've confirmed the cause.

Microsoft documents NLA behavior here.

I wouldn't recommend leaving NLA disabled as the long-term fix, since it provides an important layer of protection for RDP. The better approach is usually to have the user change the temporary password through another supported method before their first RDP connection.

If this is direct RDP to domain-joined client machines, there isn't a separate Active Directory setting that forces the password-change dialog to appear before NLA completes.

Thanks,

James
Himanshu Dwivedi 100 Reputation points

2026-09-16T18:44:29.55+00:00

NLA is already disabled, still not working

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing the detailed information and update.

Since NLA has already been ruled out, I would recommend verifying both the server-side RDP configuration and the client-side connection settings. Disabling NLA on the destination computer does not necessarily prevent the RDP client from negotiating CredSSP.

As a test, save the connection as an .rdp file, open it with Notepad, and add the following line: enablecredsspsupport:i:0

Then reconnect using that file. This forces the connection to bypass CredSSP and may allow Windows to present the interactive password-change workflow during sign-in.

If the password-change prompt appears but the password update fails, please review the permissions on the following registry key on the target computer: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc

The password-change process can use RPC over Named Pipes/SMB, and Winlogon may perform this operation by using an anonymous token. As a result, the ANONYMOUS LOGON security principal must have Read access to this registry key. If the key does not exist, create it before assigning the required permission.

In a domain environment, it is generally recommended to deploy this permission through Group Policy Registry Security rather than configuring it manually on individual machines. Also note that Group Policy may recreate the key with default permissions, so managing the setting through policy helps ensure it remains consistent.

After applying the change, run: gpupdate /force

Then, test again with a newly created account configured with User must change password at next logon.

For security reasons, I would not recommend leaving CredSSP or NLA disabled as a permanent solution. A recommended approach is to keep NLA enabled and provide users with a supported method to change their temporary password before their first RDP session, such as from a domain-joined workstation or through an approved self-service password reset solution.

References: Password change for expired password failing - Windows Server | Microsoft Learn

Enable Remote Desktop on your PC | Microsoft Learn

If you find this information helpful, please click Accept Answer.

Thank you for using Microsoft Q&A.