# How is the “change password at next logon” requirement supposed to work with RDP using Network Level Authentication?

We have a Windows server (2008 R2) with the "Remote Desktop Services" feature installed and no Active Directory domain. Remote desktop is set up to "Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)". This means that before the remote screen is displayed, the connection is authenticated in a "Windows Security: Enter your credentials" window.

The only two role services installed on this server is the RD Session Host and Licensing.

When the "User must change password at next logon" checkbox is selected in the properties for a local user on this server, the following displays on a client computer after attempting to connect using the credentials that were last valid:

On some other servers using RDP for admin access (but without the Remote Desktop Services role installed), the behavior is different -- the session begins and the user is given a change password prompt on the remote screen. What do I need to do to replicate this behavior on the Remote Desktop Services server?

• I have disabled password expiration on accounts that use RDP for this exact reason. Also: You can't change your password when connecting via an RD Broker. (Also password expiration does little except annoy users and increases helpdesk tickets, but that's a discussion for another day) – Mark Henderson Jun 13 '14 at 2:56
• I don't think I'm using the connection broker. On the second point, I agree, but in some situations it's required for PCI compliance, and here I just want to force a password change for a user's initial login with whatever default I set for them. – NReilingh Jun 13 '14 at 2:59
• No, you might not be. It's a problem with NLA and the connection broker (even without NLA) – Mark Henderson Jun 13 '14 at 3:06
• Could you try using tsconfig.msc, right-click and edit the properties of the RDP-Tcp connection, change the security layer drop-down menu to 'RDP Security Layer,' and see if that helps? – Ryan Ries Jun 13 '14 at 3:20

I'm going to posit that you can't do this. With NLA (network-level authentication) enforced, a user cannot log in remotely and change his or her password.

You can use tsconfig.msc on the Remote Desktop server, right-click the RDP-Tcp connection and choose Properties, and change the security layer drop-down menu to 'RDP Security Layer,' but then you lose NLA. Unfortunately the two settings are mutually exclusive.

If you must have NLA, then you need to establish an alternate method for users to change expired passwords, such as through Outlook Anywhere, or RDWeb Access, or a physical console of a domain-joined workstation, etc.

This is sort of a catch-22 situation, because by design, NLA will not even allocate the system resources necessary to create a Remote Desktop session for you until after your credentials have been verified to be valid. But you would have to connect to a full session, have a desktop created, LogonUI.exe spawned for you, etc., in order to change your password. But you can't have a session because your password is expired. Allowing this would, I believe, open a hole in NLA where a user could bypass NLA and get a session anyway, even though they don't have a good (i.e. not expired) password.

In the protocol specification for CredSSP, there is no reference to the ability to change the user's password while NLA is running. Therefore, the observed behavior can be considered "by design."

CredSSP is the underlying technology that enables NLA, and it does not support password changes. Therefore, password changes are not enabled in MSTSC. Other RD clients that support NLA should be unable to change the user’s password.

• It probably wasn't clear from my comment, but actually after I changed that setting to RDP security and then changed it back, I am no longer getting the error that I showed in my question. Instead, it is starting a session with the same "you must change your password" screen one would get were they to log on in person. – NReilingh Jun 13 '14 at 18:28
• Ugh, no, I was wrong about that. The "only" box was unchecked and "negotiate" was selected. – NReilingh Jun 16 '14 at 1:02