Windows 10: Is Credential Guard useful for Windows 10 laptops that do not use domain/NTLM or Kerberos?

Client does not have any Windows domain. All laptops are basically standalone. No network sharing, everyone is remote, and everything hosted in the cloud. They are working on creating a baseline and using the DISA Windows 10 STIG as a reference. Based on what I've read, Credential Guard is great for domain-joined systems and I understand that reasoning. I do not see that it applies to standalone computers but was wondering if Credential Guard and Virtual Based Security settings are recommended even for standalone computer or not. Thoughts? References to links for supporting arguments ar

:)

 

Credential Guard lab companion

Source: Credential Guard lab companion Datacenter and Private Cloud Security Blog


See also:

• Enable or Disable Credential Guard in Windows 10 Windows 10 Security System Tutorials
• Verify if Credential Guard is Enabled or Disabled in Windows 10 Windows 10 Security System Tutorials

 

Windows 10 1703 - unable to connect via Remote Desktop Gateway - Force to use Kerberos for authentication

Hello,

After update my Windows 10 to creators update (1703), it's not possible to connect a server in RDP with Remote Desktop Gateway (RDG).

Before we used Windows 10 1607 and all works good.

Apparently, in this new version, Windows 10 force to use Kerberos authentification to authenticate in RDG.

But RDG doesn't support Kerberos auth, only NTLM.

It's possible to enable NTLM auth with RDG ?

Apparently, it's a change appear in the new version of Windows 10 (1703) with functionnality "Remote Credential Guard"

So it's support only Kerberos Auth and doesn't support Remote Desktop Gateway.

Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Windows 10) - Windows security | Microsoft Docs

"Remote Desktop Gateway is not compatible with Remote Credential Guard."

But apparently, with RDP client and when I try to connect to the Remote Desktop Gateway, it's not the process mstsc it's connect to RDG but it's LSASS with try to Kerberos authentification.

Like it's explain in this article :

http://www.thewindowsclub.com/credential-guard-windows-10

For example, this is a connexion from Windows 8.1 :

RDG_OUT_DATA /remoteDesktopGateway/

HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

User-Agent: MS-RDGateway/1.0

RDG-Connection-Id: {B96140B7-3D9A-4DC0-88BC-7B40C49C1A4D}

RDG-Correlation-Id: {0CC5ACC4-323D-4D50-9A9C-D0FFD9430000}

RDG-User-Id: xxxxxxxxxxxxxxxxxxxx

Host: rdg.mondomaine.fr

Authorization: NTLM xxxxxxxxxxxxxxxxxxxxxxxxxxx==

clientless-mode: 1

X-F5-Client: rdg-http

This is a connexion from Windows 10 creators update (1703) :

First connect to KDC Proxy :

And after to RDG but with auth scheme Negotiate and not NTLM :

RDG_OUT_DATA /remoteDesktopGateway/

HTTP/1.1

Cache-Control: no-cache

Connection: Upgrade

Pragma: no-cache

Upgrade: websocket

Accept: */*

User-Agent: MS-RDGateway/1.0

RDG-Connection-Id: {2FE597B6-00AE-42BC-A47D-A67BE884237D}

RDG-Correlation-Id: {1F76CE0F-C75D-462E-9F15-FFA5951F0000}

RDG-User-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxx==

RDG-Client-Generation: Win32#6.2=5

Sec-WebSocket-Key: 6ekVx9V3iMEKWPlNVsbZ5g==

Sec-WebSocket-Version: 13

Host: rdg.mondomaine.fr

Authorization: Negotiate xxxxxxxxxxxxxxxxxxxxxxxxxxx==

clientless-mode: 1

X-F5-Client: rdg-http

Best regards

 

Raising the windows domain and forest issues?


hi,

I run a domain that was all 2003 r2 servers. I recently upgraded all my domain controllers to windows 2012 r2.
That went off without any problems.. Our trust relationships had no issues also.

My first step was to raise the Domain and Forest levels past 2003 to 2008. This went off without a hitch.
These are the features for raising the levels to 2008:

• Features and benefits include all default Active Directory features, all features from the Windows Server 2003 domain functional level, plus:
• Read-Only Domain Controllers – Allows implementation of domain controllers that only host read-only copy of NTDS database.
• Advanced Encryption Services – (AES 128 and 256) support for the Kerberos protocol.
• Distributed File System Replication (DFSR) – Allows SYSVOL to replicate using DFSR instead of older File Replication Service (FRS). It provides more robust and detailed replication of SYSVOL contents.

Forest Level Windows Server 2008

• Features and benefits include all of the features that are available at the Windows Server 2003 forest functional level, but no additional features. All domains that are subsequently added to the forest will operate at the Windows Server 2008 domain functional level by default.

My next step is to raise the domain and forest to 2008 r2, then 2012, and finally 2012 r2. I have been trying to find out exactly what I could expect from raising the Domain and Forest for each step.

The step involving 2008 r2 seems relatively a non issue. But getting the couple of new features seem very nice

Domain Level Windows Server 2008 R2

• All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus 2 new features

Forest Level Windows Server 2008 R2

• All of the features that are available at the Windows Server 2003 forest functional level, plus the following features:

• Active Directory Recycle Bin, which provides the ability to restore deleted objects in their entirety while AD DS is running. <== New Feature very cool
• All domains subsequently added to the forest will operate at the Windows Server 2008 R2 domain functional level by default.

Here is my big concerns for the next raising of domain and forest to 2012.

Forest Level Windows Server 2012:

• All of the features that are available at the Windows Server 2008 R2 forest functional level, but no additional features.
• All domains subsequently added to the forest will operate at the Windows Server 2012 domain functional level by default.

Domain Level Windows Server 2012 R2: <=====Need to investigate more and why this post

• DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longer:

• Authenticate with NTLM authentication <==============(what issues may arise)
• Use DES or RC4 cipher suites in Kerberos pre-authentication
• Be delegated with unconstrained or constrained delegation
• Renew user tickets (TGTs) beyond the initial 4-hour lifetime

Will this affect my exchange anywhere users with remote access authenticating either clear of NTLM???
and what would/may not to work properly day 1 when I raise the domain and forest to 2012. I cant really find anyone that can answer a straight question.

Has anyone gone through this? what problems did you have, if any , if a lot???

Any thoughts and suggestions will be much appreciated??

thanks


- - - Updated - - -

One more point... I am not sure if I posted this to the correct forum.. So if I was wrong and it should be in a different one..
PLEASE LET ME KNOW