8

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.

User properties window

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:

Error has occurred

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?

NReilingh
  • 472
  • 3
  • 9
  • 24
  • 3
    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 02: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 02: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 03: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 03:20

3 Answers3

9

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.

http://support.microsoft.com/kb/2648402 says:

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.

Community
  • 1
Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 1
    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 01:02
  • FYI, I ran into the same issue where the only computers I could RDP to in the domain required NLA and my new account had "must change password at next login" checked. I was able to change my password by downloading MIT Kerberos for Windows and using that from my workstation to get a Kerberos ticket which prompted me to change my password. This is the thread where I found out that AD requires you to use Kerberos to change initial password which pointed me to the eventual solution: http://www.perlmonks.com/?node_id=752162 – David Archer May 05 '17 at 00:05
0

PLEASE, who knows anything about the farm, absolutely:

  1. Doesn't work with policy: network level authentication - disabled, restarting the desktop id service.

  2. Doesn't work with tsconfig.msc on ALL machines in the farm setting protocol: RDP instead of NLA (negotiation), restart desktop account service.

Doesn't work when unchecked: only connect when client is running on network authentication..., set on ALL farm machines, restart desktop services.

ANYWHERE on the connection GATEWAY-BROKER-TEMINAL is a bug with the involvement of the protocol NLA or something else, but LOGON when using a farm gateway (the role of the gateway + broker + Web RD on one machine) - NO! I.e. once you check the box: user must change password at next login, you no longer get logon and therefore cannot change user password!!!

Who knows where to dig in the GATEWAY-BROKER-TEMINAL bundle, somewhere in the innards of the protocol, somewhere in the policies or somewhere else?

AlexPebody
  • 1
  • 1
  • If you have a new question, please ask it by clicking the [Ask Question](https://serverfault.com/questions/ask) button. Include a link to this question if it helps provide context. - [From Review](/review/late-answers/502425) – Paul Nov 11 '21 at 16:54
0

In short! Here's the solution!

  1. Make an account that will not be in any group of the domain, or rather make the group empty and put it the main user, removing even from the group domain users.

  2. We add this user to the remote desktop group on the farm gateway only.

  3. Then we write in ANY client properties of this user together with login, password, domain, ONLY in the gateway section.

  4. In the same connection settings write the PC (usually the 1st PC in the farm), which needs to connect.

Everything. Profit. Thank you all. The solution was found by the collective mind of my team, for which she and I, including a BIG THANK YOU!

AlexPebody
  • 1
  • 1