If one requires NLA, users cannot change their passwords prior to logon - why?

As taken from this article on Technet, network level authentication works as follows:

Network Level Authentication is an authentication method that can be used to enhance RD Session Host server security by requiring that the user be authenticated to the RD Session Host server before a session is created.

When you check the box "User must change password at next logon" you are basically saying that the user has to change their password before they can login, you already know that upon doing so locally a dialog pops up prompting you to change your password and you cannot login until you do so. Because NLA Requires you to be completely authenticated before even attempting to actually open remote desktop, this would have to be where the problem is.

A lack of support on both ends of the remote desktop support to allow that dialog and protocol to be used from the login prompt that appears when attempting to connect via NLA. While I believe that this is a feature that should be added, I do not think that it should be enabled by default for possible security reasons.

Hi.

I have my problems accepting this statement of yours: "Because NLA Requires you to be completely authenticated before even attempting to actually open remote desktop, this would have to be where the problem is" - why am I not completely authenticated at that time? My password is correct (though set to expired), I am completely authenticated. It should let me proceed to the logon screen of the server and request to change the pw immediately there just as it does when NLA is off.

I assume that MS is simply not able to program it smarter born out of laziness... but I might be wrong :)

Let me attempt to restate that a little bit, While you are authenticated, your not really 'trusted' at this point, you aren't allowed to remote into the machine yet, so you can't get to the pop up that forces you to change your password. The mixture of you not being trusted enough to login to the server, and the missing feature of changing your password from the NLA login prompt would be why you're having this issue.

When I said "this would have to be where the problem is." I went on to explain that statement in the following paragraph, I agree that this is something that Microsoft should implement, however I do not believe this should be enabled by default. I am unaware of any options regarding this at the moment.

I had understood, no need to repeat :)
My point: When I enter the correct password, I am already trusted, right? Why shouldn't I be trusted just because my pw is expired or for other reasons required to be changed?

The thought behind NLA is the following: don't let users that are not authenticated to the logon screen. Those unauthenticated users could conduct a DOS attack just by consuming resources this way. That is understood. But I am authenticated. I see no reason for this design so I asked myself if MS sees any reason or if it's simply another technology that is used here that cannot deal with the change-pw-immediately-requirement and I simply don't understand it.

I don't think we should try and discuss it. I was simply looking for a technical reason if any, born out of interest because this "incompatibility" will cause us to change our customers' guidelines. If there's no technical reason but it's just a design decision that can be argued about, then we may close it.

Ahhh :)
So this can be patched away. Let me know if you find a patch for win8 as a client, too. Because I could install the server patch but don't see a client patch for 8. Will try with 7 as a client and report back.

This is about the 3rd time I encounter that MS issues a patch and for some reason it does not work even after installing it (and restarting). Installed 397 at the client and 402 at the server - no change.
:(

I did not really see a whole lot of other options, there were a few little things to check that didn't make any sense, such as checking the time on the Terminal Server versus the Domain controller (which should break authentication in general).

Check to see if you are using the newest available remote desktop client, if there is an update available.

Attempt to use the domain\username while logging in (which shouldn't even be related, but its worth a try)

There are a lot of conflicting arguments on both sides, I do not think this is supported or that there is any intention of supporting it.

Sorry that I could not be of more help!

" I do not think this is supported or that there is any intention of supporting it." - huh? It IS supported, the supported hotfix should incorporate exactly that.

The rest was checked. All ok. When at home, I will check if MS changed the behavior in later TS releases like 2012 R2 together with win 8.1.

CU later.

Thanks to both of you. Conclusion: the patch is not meant for the simple setup but for remote desktop web access. It does indeed even say "not applicable" when we try to install it at the server - I force-installed it using pkgmgr.exe but to no avail - had I read the prerequisites, I would have known. So we simply cannot offer both: single sign on for our internal users (because it requires NLA) and also the possibility to let users with an expired password change it via RDP without using the rdp web access feature. Oh well...never mind. I was just looking for a deeper understanding of what NLA really is - now I would say: not much ;)

While not helping with the password change problem, here's a link that helps to describe how NLA (along with CredSSP) works:
http://technet.microsoft.com/en-us/magazine/hh750380.aspx

I've tried to distill and paraphrase what I think are the most relevant parts.

What Is NLA?

NLA forces the client computer to present user credentials for authentication before the server will create a session for that user. Because of that process, it’s sometimes called “front authentication.” NLA relies on a technology called Credential Security Support Provider (CredSSP) Protocol.

Starting a session—even just presenting a logon screen—requires the server to create many of the processes required to support a session, such as Csrss.exe and Winlogon.exe. Because of this, session creation is expensive and relatively time-consuming.

NLA uses CredSSP to present the user credentials to the server for authentication before creating a session.

How CredSSP Supports NLA

The CredSSP Protocol helps applications securely delegate user credentials from a client to a target server. This protocol first establishes an encrypted channel between the client and the target server using Transport Layer Security (TLS) (as specified in [RFC2246]).

When you connect to an RD Session Host server with an RDC 6.x or later client, you might have noticed you don’t connect directly to the RD Session Host server logon screen to provide your credentials. Instead, a local dialog box pops up to take your credentials on the client. This dialog box is the front end of CredSSP.

When you type your credentials into this dialog box, even if you don’t choose to save them, they go to CredSSP. This then passes the credentials to the RD Session Host server via a secure channel. The RD Session Host server will only begin building a user session once it accepts those credentials.

Here's my conclusion:
When a user has "must change password at next logon" or an expired password, they can't access network resources.  For a user that has this, try accessing OWA or a network share and see the result.  Those actions are attempting a network authentication.  NLA is also a network authentication and so behaves the same way.
This doesn't help with overcoming the problem, but hopefully aids in understanding why it exists.  Further understanding may be gained by examining the normal session logon process and how it works when the user must change their password.