Introduction
Using the Windows credentials of a user/machine to connect to the network has been a popular approach to user-based network access for a long time. When you are able to put a name to who is connecting to the network and what they are doing, users may think twice before they visit that not work-related website during work hours. Users can also be tied to different AD Groups, which we can leverage to make policy decisions.
Network Authentication Basics
There are essentially two ways to authenticate your users/machines when they are connecting to your network: either using their AD-credentials (this method is called PEAP-MSCHAPv2, which means a username and password is used) or using certificates issued by your AD Certificate Authority (this method is called PEAP-EAP-TLS or EAP-TLS).
Using certificates is always recommended because it is considered more secure, but not everyone has taken the steps to set up an AD Certificate Authority in their organization. There are also some use-cases where certificates might not be the best method of authentication. For example, computers that are shared between different users in Windows 10 has a pretty big drawback in that the user has to be connected to an open (not locked down) wired network the first time a new user logs into the machine in order talk communicate to the AD and get the user certificate downloaded to the machine. This is unfortunate, because as soon as the new user logs into the machine Windows will attempt to perform the user authentication for the network access, and at this point, the certificate has not yet been downloaded to the machine. This will make Windows 10 simply kill the network connection because it has no user certificate to present to your switch/WLC running 802.1X.
Credential Guard and Network Authentication
Starting with Windows 10 Enterprise, Microsoft has introduced a new fancy feature called Credential Guard.
We are not going to go deep in-depth on how Credential Guard works but the basics are that laptops/desktops (note: NOT available on virtual machines) running Windows 10 Enterprise can protect the users' and machines' credentials by placing them in the so-called Isolated Local Security Authority. This is to protect the credentials from being exposed to all the bad stuff that could get on a computer.
Not even Windows' own network profile settings (applies to both wired and wireless connections, which can be configured manually or distributed via GPO) can access these credentials now. In Windows 7/8/8.1, we could leverage the credentials to create a Single Sign-On experience by having the network login take place directly after the user logs into their computer. Windows would take the credentials used to log into the computer/AD and then send them to the switch/WLC which in turn talks to ISE/ACS/other Radius servers, which could look up the user in Active Directory to determine what kind of authorization should be granted (based on group membership, attributes and so on). This was the case both for user or machine authentication (which also can be used together).
But now, due to Microsoft upping the security in Windows 10, the old way of solving user-based network access no longer works. While Credential Guard can be disabled, it is highly recommended not to do so. Credentials can cause big damage in the wrong hands, they are certainly worth the best protection possible. The user can of course manually get network access by clicking on the SSID in the wireless network list, but they would have to type in their username and password again. Every time :(
Windows 7 / 8 / 8.1 scenario
This is how Windows 7 handles the Single Sign-On experience for network access. Windows 8 and 8.1 work in similar ways.
Windows 10 Enterprise (without Credential Card) scenario
This is how Windows 10 Enterprise (without Credential Guard) handles the Single Sign-On experience for network access.
Windows 10 Enterprise (with Credential Card) scenario
This is how Windows 10 Enterprise (with Credential Guard) disables the Single Sign-On experience for network access.
As you can't see, we are not given the option of automatically using the Windows logon credentials for the network access when Credentials Guard is activated.
Solution?
However...
Microsoft states that "Credential Guard uses virtualization-based security to isolate secrets (credentials) so that only privileged system software can access them.". What counts as privileged system software?
I'll tell you at least one piece of software that falls into this category: Cisco AnyConnect! Yes, we can use the Cisco AnyConnect Network Access Manager (NAM) to bring back the seamless user experience for connecting to the corporate network.
Cisco AnyConnect NAM is very flexible when it comes to configuring the authentication method used to access the network, far more so than the built-in Windows network settings. There is also the possibility to have different authentication methods for the user and machine authentication: for example, you could use certificate-based authentication for the machine authentication and AD credentials for the user authentication or vice versa if your implementation requires the use of both for maximum security.