GP for CredSSP vulnerability not working as documented

We're trying to implement the new GP settings to mitigate the CredSSP vulnerability (CVE-2018-0886) in Windows RDP.

I have two servers set up - one patched and one is in a test farm and has not been patched since January.  I have manipulated GP to set the policy to all three settings - "Vulnerable", "Mitigated", and "Force Updated Clients".  When connecting from an older thin client or from the unpatched server to the patched server, the RDP connection behaves as expected.  That is it connects unless the GP is set to Force Updated Clients".

But when I try to connect from the patched server to the unpatched server using RDP it always works.  The documentation looks to me like a client set to either "Mitigated" or "Force Updated Clients" should not connect.  I have the same behavior on a Windows 10 Pro Workstation.  The GP for it is set to "Force Updated Clients", but I can still connect to any server whether it's updated or not.

Has anyone else tried this.  Any explanation or ideas?
gflorenAsked:
Who is Participating?
 
McKnifeCommented:
Did the test and it performs as expected.
The client is a patched win10 with the policy set to "Force Updated Clients" and
1 connects to an unpatched win10 (16299.248) and gets
Cap12 ...while when NLA is turned off at the target,
cap2.pngit can connect, since CredSSP is not used, then, and
3 When the target is patched (16299.371) , I can connect without problems in any case, no matter if the policy is set at the target and no matter if NLA is on or off at the target.

Please make sure to talk about target and source and not necessarily client and server, to make things easier discussing this.
Also double check NLA settings, which are only important at the server side.
2
 
McKnifeCommented:
Yes, I have tried and I have an explanation that will most certainly apply.
CredSSP is only being used, if on the RDP server side, the default settings for RDP are applied, which are: require network level authentication ("NLA"). NLA uses CredSSP. if NLA is not required, CredSSP is not even used and the RDP connection may proceed in any way.
0
 
gflorenAuthor Commented:
That would make sense.  I'll check it out on my W10 workstation when I am in that office tomorrow and post an update.
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
gflorenAuthor Commented:
I tried this on a an unpatched 2012 server (which as I understand uses credssp) and I have enablecredssp set to true in my RDP file on my fully patched W10 workstation.  I was still able to connect even though my client is set to "Force Updated Clients".

I have not found any client that seems to care if a server is patched or not.  Servers behave as expected and reject connections to unpatched clients if Oracle Mitigation is set to "Force Updated Clients".
0
 
McKnifeCommented:
Will try to reproduce tomorrow.
0
 
gflorenAuthor Commented:
Ok.  That's pretty clear.  I did not have require NLA set on in the system properties of the target machine.  I'll make that change and then retest tomorrow when I'm at an office with a workstation to use as a source.   Thanks.
0
 
gflorenAuthor Commented:
And yes... after forcing the target to accept only NLA,  it works as expected.  Thank you.
0
 
McKnifeCommented:
Ok. You can close the question now as it is answered.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.