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

McKnife used Ask the Experts™
Hi experts.

We run a 2008 R2 remote desktop server. We require NLA (network level authentication)
My goal is to understand the following technical detail:
http://en.wikipedia.org/wiki/Network_Level_Authentication says:
"Not possible to log on and change password when "User must change password at next logon" is enabled on the user account"

While I can reproduce this unwanted effect myself, I don't understand it. Can anyone wiser give details on what exactly NLA changes so that this pw-change prior to logon is made technically inpossible?

Background: we would like to use RDP-SSO. That however requires NLA. And NLA "destroys" the ability to setup new users with the attribute "User must change password at next logon" if those users are only able to logon via RDP - they are simply rejected with the error "An authentication error has occurred. The local security authority cannot be contacted".
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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.
Distinguished Expert 2018



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.
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

Distinguished Expert 2018


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.
I've been looking into the issue a little, have you looked at these pages yet?




As far as I can tell there is no 'technical' reason as to why this can't be done.
Distinguished Expert 2018


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.
Distinguished Expert 2018


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!
Distinguished Expert 2018


" 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.
Top Expert 2014
My experience with those patches is that they have no effect on a server where you're trying to remote into using Remote Desktop for Administration.  Even for a full RD Session Host, you have to have the RD Web Access role, and then you enable a web page so that users can change their password through that.  It doesn't give the ability to change the password in the same manner as when you didn't require NLA.
The client patch only changes the dialog box wording.

This thread mentions the misunderstanding

A couple instruction pages for enabling the web page.

I don't quite understand why MS hasn't put something in to allow this scenario and still use NLA, but apparently it is "by design".
In some ways I kind of understand the timing:
 - NLA requires authentication before the connection happens.  If the password is expired or set to "must change at next logon", authentication can't happen (it won't accept the old password), and so the connection never completes.  There seems to be some difference between an expired password and "must change at next logon" (based on some non-scientific observations about being able to log in to different systems through different methods when one or the other condition is true), but I don't know what it is.  When looking at user properties with PowerShell, both conditions result in a property of PasswordExpired set to True.  If I understood this difference better, perhaps I would understand more completely the problem with NLA.
Distinguished Expert 2018


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 ;)
Top Expert 2014

While not helping with the password change problem, here's a link that helps to describe how NLA (along with CredSSP) works:

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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial