Machine Authentication and User Authentication

“My organization wants to authenticate the machine AND the user.” 

That quote is something that I am hearing all the time from customers and implementers all over the world!  

Sometimes it gets quite funny.  In June of 2015 I was presenting at the Cisco Live conference and one of the session attendees asks me “when is Cisco going to provide EAP Chaining for MAC OS“!  My response was designed to elicit participation & garner more attention from audience members, which was to scream at the participant “Cisco doesn’t write MAC OS!!!!”  I immediately apologized for using him as a guinea pig & explained that I was just trying to make an entertaining point.  He laughed right along with the rest of the room & I got away without offending him 🙂  

The point is that many organizations and engineers do not understand the actual process of authenticating the machine AND the user when it comes to 802.1X, nor what it means – because we as an industry have been very spoiled by Microsoft’s innovation.  

So, what is a machine authentication anyways?

So that we are not splitting hairs during this blog post, let’s get this out of the way now:  truthfully and logically, a Machine or Computer Authentication is what is occurring any time a supplicant is authenticating to the network with a stored credential.  

If an iPad has a certificate stored on it, and that certificate is used for network authentication, what is it really proving?  It’s proving that MACHINE had a credential stored in it, right?  

Microsoft, however, took that to a completely different level!  I know, you mention Microsoft and Security in the same sentence, and many will laugh.  However, if you get past that initial knee-jerk reaction & dive deep into things they have done to enhance security, you realize Microsoft takes security very seriously; at least that is my opinion from observing them for 20+ years. 

Enough of that ramble – let’s get back to what they did to enhance security as it relates to network authentication.  

~2000, the world welcomes the arrival of a shiny new baby boy named “IEEE 802.1X”.  

So back around the year 2000, we standardized on a network access protocol called 802.1X, which was going to usher in a new era of network security.  Never again would a computer enter a network without knowing WHO was using that computer.  So let’s think about this:

In my own weird way, Figure 1 is meant to illustrate a Windows Computer connecting to an 802.1X enabled network.  Since 802.1x was designed to authenticate the USER, the machine is still sitting there waiting for an interactive user to press CTL-ALT-DEL and log in.  

Aaron Woland

Since there is no interactive user, there would be no “Identity” to send into the network for authentication & now this machine is sitting there without any ability to reach Active Directory for Group Policy (GPO) updates, or other important endpoint management tasks.  

This is Where Microsoft Does Something Very Cool

When a Windows desktop machine joins Active Directory, there is a computer account that gets created and a unique password is negotiated between the machine and AD.  Figure 2 shows a screen shot from Active Directory Users and Computers showing the domain joined computer accounts.  

Aaron Woland

This computer account can now be used to identify the machine, even when no user is logged in, which can be used to provide the machine access to the network.  This is what we commonly call a “machine auth”.  The access could naturally be customized and specific for a machine-only to access the things that the machine may need access to (such as AD), and not provide full network access, that’s entirely up to you & how you design the authorization result for the machine-auth. 

Figure 3 is a poor attempt to illustrate a limited access provided to a computer account, so the computer can get it’s management updates from AD, users are able to login to computers with AD credentials, even if they’ve never been logged into that desktop before, etc. 

Aaron Woland

What About When a User Logs In?  

The computer is on the network, and able to communicate.  What happens when a user sits down & presses CTL-ALT-DEL and logs into the laptop.  Most of the time, the Windows device will send a new “start” message into the network to initiate a new network login, this time using the User-Credentials.  

Note: While it is possible to configure the user session to continue leveraging the machine credential, it is not possible to configure windows to leverage the user credential when the user is not logged in.  That is (of course) unless you are using a very intelligent supplicant like Cisco AnyConnect or “Juni-Pulse-Funk” Oddessy, etc.  

Windows is a multi-user operating system.  This is important to note, because each user will have their own credential store on the same computer.  This means that employee1 will have his/her certificates and other credentials in a totally different location than employee2 & each user will not have access to anyone’s credentials except their own.  This concept is very different from the Android and iOS devices of today, which are mostly single-user devices.  

Figure 4 is my ridiculous attempt to illustrate the concept of the computer and each user having separate credential stores.

Aaron Woland

When the user logs into the Windows machine, the “state” changes & uses their credentials.  There is an option to keep the machine state for the network authentication, but there is no option in native Windows for the user state to extend beyond logoff, or to validate both the machine and the user credentials.  

To try and illustrate this concept, Figure 5 shows the credential used for the network authentication when there is no interactive user logged in.  Figure 6 shows the credential for the network authentication when Employee2 is logged into the Windows system.

Aaron Woland

Aaron Woland

Let’s ReGroup and Level-Set

“Let me explain..  No there is too much, let me sum-up” – Mandy Patinkin, The Princess Bride

At this point, we’ve covered that computer authentications are possible because Microsoft creates a computer-account in Active Directory which both the PC and AD are aware of, thereby allowing the computer to have it’s own identity for network access purposes (among other things).

When a user logs in, the context of the system on the network changes, and a new EAP authentication occurs, thereby changing the authentication on the port to a user-based authentication  

EAP authentications were always (and technically still are) designed to cary a single credential per EAP transaction.  The only standard EAP type that can handle the dual identity “chaining” is TEAP (RFC 7170); which as of July 2015 – no vendor has published an implementation yet.  Cisco can do EAP-Chaining today with EAP-FASTv2, but that is not a standard, TEAP is.

Ok, are we all on the same page now?  Great.  If not, please start at the beginning again & meet me back here.

What about non-Windows systems?

To be frank and honest, the rest of the world has not caught up to Microsoft with other systems just yet.  Microsoft and their Active Directory was and is doing something that no other can really compete with just yet.  They have a desktop OS and a directory system that are incredibly tightly integrated, leveraging strong authentication and authorization that is separate for users and computers.  In the Enterprise Endpoint Management / MDM space we can only dream of such tight integration – it’s like the Holy Grail.  

“But I have created an object for my MAC computer in Active Directory, isn’t that the same thing”?  Actually, No.  It’s not the same thing because the desktop OS is still not aware of the different credentials.  The computer itself does not have it’s own context. To be fair, there are System-Level credentials available, and there User-Level credentials available; but they are mutually exclusive entities.  

You do Have Options

This Blog is getting very long winded, so for more detail on the options I am covering here, see pretty much any of my recorded Cisco Live sessions from the last few years. They are available for free here:  https://tinyurl.com/nh5phaw

Option 1: By using a certificate on either your non-Windows / non-AD-Integrated computer, tablet or phone: you are authenticating a trusted credential that has been stored in the computer – thereby having that first credential (Machine-Auth) of sorts. Option 2: From there, you can use what we call CWA Chaining with Cisco ISE, which is the ability to use the 802.1X credential AND a Web Authentication credential that was typed by an interactive user.

Option 3: There is also the ability to use Machine Access Restrictions (MAR) with windows systems that ARE part of the domain.

Option 4: Don’t forget about EAP-Chaining with Windows devices and the Cisco AnyConnect Supplicant using EAP-FASTv2.

Lastly:  don’t forget to tell your Vendor of Choice (Apple, Linux Distro, Google Android, etc.) that your organization needs TEAP support (RFC7170)..

I hope this was helpful & not TOO long winded.

-Aaron