RDP sign-in fails: Password must be changed before first sign-in
A new account with an initial password, and the Remote Desktop connection terminates with “You must change your password before logging on the first time.” The cause is Network Level Authentication, which does not support password changes. The password can still be changed: through another Windows session, from your own PC, using PowerShell, or through RD Web Access.
I recently encountered the situation again with a newly configured account in a customer environment: The initial password is correct, but the Remote Desktop connection is still terminated immediately. The Windows client mstsc displays the following message:
You must change your password before logging on the first time.
Please update your password or contact your system administrator
or technical support.
Other RDP clients and connection managers indicate the same condition in their own wording, for example, “The user password must be changed before logging on for the first time.” For an expired password, the message is “This user account’s password has expired. The password must change in order to logon.” The cause and solution are the same in both cases.
In short: The password cannot be changed through the RDP connection in this situation. It must be changed beforehand by another means, and in most cases, a network connection to a Domain Controller is sufficient.
Cause: NLA authenticates before the session is established
The account has the User must change password at next logon option set in Active Directory (technically: pwdLastSet = 0). This is not a problem at a workstation in the domain: The sign-in screen recognizes the condition and immediately asks for the new password.
With RDP, this step is missing as soon as Network Level Authentication (NLA) is enabled. NLA authenticates the user through CredSSP before a session with a sign-in screen is created on the target system. Authentication with a password that must be changed fails, and no password-change dialog is provided at this point. The client terminates the connection and displays only the message. NLA is the default in current Windows versions and is enforced by Group Policy in hardened environments.
Options for users
There are four ways to change the password without using the affected RDP connection. Which one is suitable depends on what can be reached from the user’s own workstation.
| Option | Requirement |
|---|---|
| 1. Password portal or service desk | provided by the operator |
| 2. Existing Windows session in the domain | access with another account or to another system |
| 3. Password dialog on your own PC | Domain Controller reachable, for example through VPN |
4. PowerShell with NetUserChangePassword | TCP 445 to the Domain Controller reachable |
Option 1: Password portal or service desk
In larger environments, there is usually a designated route for external staff: a self-service portal, a password feature in the VPN or Citrix portal, or a PAM system. If none is available, the service desk can remove the flag or set a password without requiring it to be changed (see the section for administrators).
Option 2: Existing Windows session in the domain
If a session already exists on a system in the domain, such as on a jump host or with a second account, the password can be changed there. In an RDP session, Ctrl+Alt+End opens the security screen of the remote system (Ctrl+Alt+Del would be processed on the local PC). Under Change a password, the username field can be edited: Enter the affected account there in the form DOMAIN\benutzer, followed by the initial password and the new password twice.
Option 3: Password dialog on your own PC
The same dialog also works on a PC that is not a member of the domain, provided it can reach a Domain Controller, for example through a VPN connection. Press Ctrl+Alt+Del, choose Change a password, and replace the prefilled local username with DOMAIN\benutzer. The PC must be able to resolve the domain name through DNS; without the DNS servers of the target environment, Windows cannot find a Domain Controller.
Option 4: PowerShell with NetUserChangePassword
The Windows API NetUserChangePassword changes a password directly on a Domain Controller. It verifies the previous password during the change itself and does not require prior sign-in. It therefore also works when the password has expired or must be changed, including from a PC outside the domain. The script imports the function through P/Invoke and prompts for both passwords without displaying them:
$api = Add-Type -Namespace Win32 -Name NetApi32 -PassThru -MemberDefinition @'
[DllImport("netapi32.dll", CharSet = CharSet.Unicode)]
public static extern uint NetUserChangePassword(
string domainname, string username,
string oldpassword, string newpassword);
'@
$dc = 'dc01.example.com'
$user = 'm.muster'
$alt = Read-Host -AsSecureString 'Bisheriges Kennwort'
$neu = Read-Host -AsSecureString 'Neues Kennwort'
$klartext = { param($s) [System.Net.NetworkCredential]::new('', $s).Password }
$rc = $api::NetUserChangePassword(
$dc, $user, (& $klartext $alt), (& $klartext $neu))
if ($rc -eq 0) { 'Kennwort geändert' } else { "Fehler $rc" }
A return value of 0 indicates success. The most common error codes are:
| Code | Meaning |
|---|---|
| 5 | Access denied, for example because the Domain Controller does not allow the call without authentication |
| 86 | The previous password is incorrect |
| 2221 | The username was not found |
| 2245 | The new password does not meet the password policy (length, complexity, history, minimum age) |
| 2351 | The specified server name is invalid |
The call uses SMB and requires TCP port 445 to the Domain Controller. In heavily segmented networks, this port is often blocked from client networks or VPNs; in that case, option 1 remains.
Set-ADAccountPassword from the Active Directory module does not help the affected user in this situation: The cmdlet requires an authenticated connection to Active Directory Web Services, and that very sign-in is not possible with the affected account. It is the tool for the administrator.
Disable NLA in the client: only without enforced NLA
It is often recommended to disable CredSSP in the .rdp file:
enablecredsspsupport:i:0
The client then connects without NLA and receives the classic sign-in screen of the target system, where the password can be changed. This works only if the target system accepts connections without NLA. If Allow connections only from computers running Remote Desktop with Network Level Authentication is enabled there, it rejects the connection. This is the default in current Windows Server versions.
Options for administrators
On the administration side, the problem can be prevented or resolved:
- Remove the flag:
Set-ADUser -Identity m.muster -ChangePasswordAtLogon $falseremoves the requirement to change the password. The user can sign in with the initial password and change it during the session usingCtrl+Alt+End. The initial password remains valid until then and must therefore be transmitted through a secure channel. - Reset the password:
Set-ADAccountPassword -Identity m.muster -Resetsets a new password. Then check whether the flag is still set. - RD Web Access: If the role is available, it can offer password changes for expired passwords. In IIS Manager, under Sites → Default Web Site → RDWeb → Pages, set the value
PasswordChangeEnabledtotruein Application Settings. The password-change page is located at/RDWeb/Pages/en-US/password.aspx. - Accounts for RDP-only access: For users who work exclusively through RDP (external service providers, administrators on jump hosts), the requirement to change the password at first sign-in cannot be fulfilled without one of the methods above. The process for the first password change should therefore be part of onboarding.
Disabling NLA on the target system also resolves the symptom, but removes a layer of protection: Without NLA, every client on the network can reach the sign-in screen and thus the RDP service before authenticating. Microsoft advises against this.
Comments
Comments are loaded from GitHub / Giscus.