cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3238
Views
20
Helpful
4
Replies

ISE 802.1X Computer Authentication and Local Admin

Alex Pfeil
Level 7
Level 7

We are deploying wired 802.1x and had a conversation on if a computer authenticates to the network, but a user has not logged into the network.  Would the helpdesk be able to connect to the computer as a local administrator? Has anybody ran into this while deploying 802.1x.  Do we need to have a computer authentication ACL, and a user authentication ACL? What is the best practice?

 

Thanks in advance!

2 Accepted Solutions

Accepted Solutions

Damien Miller
VIP Alumni
VIP Alumni
I hope others respond to this as well as there are multiple ways to address this. How you handle it usually comes down to security policy requirements. Part of it comes down to your authentication policy and how you handle endpoints failing authentication. If you stay in monitor mode and dont ever plan on migrating past that, then it doesn't matter much.
One possible way to prevent most corporate machines from being locked out of the network is creating a MAB policy that catches corporate machines failing dot1x. You can profile machines as domain joined and when they fail dot1x, catch them with a MAB policy that provides basic network access either with a DACL or SGT.
If you use a machine auth supplicant configuration, the endpoint should authenticate before any user has logged in. Local admin account will always be able to log in at the computer, but they should also be able to log in via RDP or other tool. Machine auth provides the pre user log in authentication to the network. If the machine is failing dot1x/machine auth, then you can still log in locally, but remote support connections need to be addressed with something like the above domain machine MAB policy or poking a hole in an ACL.

View solution in original post

Mike.Cifelli
VIP Alumni
VIP Alumni
I want to add some info because I have ran into this myself. I assume if you are authenticating both users and machines via 8021x then you are using eap-fast. In my opinion you should absolutely have separate dacls/sgts depending on what you are using in your environment that provide different types of access. In your policy build out you can push policy by utilizing the eapchainingresult condition. Using this will allow you to deploy different dacls/sgts. Types of chaining results equal: computer pass+user fail; user pass+machine fail; user+machine pass; Using Damien's idea with mab will absolutely work as well.

HTH!

View solution in original post

4 Replies 4

Damien Miller
VIP Alumni
VIP Alumni
I hope others respond to this as well as there are multiple ways to address this. How you handle it usually comes down to security policy requirements. Part of it comes down to your authentication policy and how you handle endpoints failing authentication. If you stay in monitor mode and dont ever plan on migrating past that, then it doesn't matter much.
One possible way to prevent most corporate machines from being locked out of the network is creating a MAB policy that catches corporate machines failing dot1x. You can profile machines as domain joined and when they fail dot1x, catch them with a MAB policy that provides basic network access either with a DACL or SGT.
If you use a machine auth supplicant configuration, the endpoint should authenticate before any user has logged in. Local admin account will always be able to log in at the computer, but they should also be able to log in via RDP or other tool. Machine auth provides the pre user log in authentication to the network. If the machine is failing dot1x/machine auth, then you can still log in locally, but remote support connections need to be addressed with something like the above domain machine MAB policy or poking a hole in an ACL.

Mike.Cifelli
VIP Alumni
VIP Alumni
I want to add some info because I have ran into this myself. I assume if you are authenticating both users and machines via 8021x then you are using eap-fast. In my opinion you should absolutely have separate dacls/sgts depending on what you are using in your environment that provide different types of access. In your policy build out you can push policy by utilizing the eapchainingresult condition. Using this will allow you to deploy different dacls/sgts. Types of chaining results equal: computer pass+user fail; user pass+machine fail; user+machine pass; Using Damien's idea with mab will absolutely work as well.

HTH!

Thank you for the EAP chaining examples.

Just to add my 2 cents.  I usually avoid EAP chaining because it forces you to install NAM and it is proprietary method. 

 

As Damien said you first have to ask what are the goals for authenticating computers/users.  Most customers simply want to answer the question "Are the devices connecting corporate device?".  If that is the main question then PEAP Computer answers that question and you have no issues with user logins (local or AD). 

 

If the customer requires user based polices I will usually move them to EAP-TLS.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: