Policy Set with Multiple Authz Conditions

[cjdiener16]

Hello,

My company recently bought ISE and I'm having a hard time creating the User portion of the Authorization Profile. 

Our idea is to have a User Authz Policy and a Machine Authz Policy (for PCs that don't have users logged in). We have ISE integrated with AD and I have the user groups associated. I also have the Domain Computers group pulled in for the machine authz. We will have multiple user groups pulled in that will need to be identified from. No user is in more than one of these groups. As you'll see below, we would like to make sure that users logging into a computer is in our AD, but also that the computer that they're on is in our AD. At this point, I have a catch all permit so as to not impede on production.

My problem is, users are being identified in the correct groups and all, but they are hitting the permit all at the bottom. Am I not able to have a user and computer authz in the same policy?

I figured I would make 2 Authz Policies

1. User Policy

--Wired_802.1X; and

--xxx-ExternalGroups EQUALS xxxxx/Users/Domain Computers; and

----xxx-ExternalGroups EQUALS xxxxx/Groups/xxx - Users; or

----xxx-ExternalGroups EQUALS xxxxx/Groups/xxx - Users;

2. Machine Policy

--Wired_802.1X; and

--xxx-ExternalGroups EQUALS xxxxx/Users/Domain Computers;

~~~~~~~~~

Permit All

[Damien Miller · Accepted solution]

You are trying to combine user and machine authentication, but a user won't be part of "domain computers". In turn, your first user policy requires something like eap-chaining or eap-teap to accomplish so you can authenticate both during the same flow.

EAP-TEAP is brand new as part of Win 10 2004 update, but EAP-Chaining is part of the AnyConnect NAM module. Both these work to accomplish what you would be after....Authenticate both the machine and the user. With the standard native supplicants in Windows/Mac/Linux, you can authenticate the machine or the user, but not both at once.

There is also the possibility to do this with something called Machine Access Restrictions, but I like to avoid it.

[cjdiener16]

Thanks Damien, but I think I found a way around this. I found an attribute from the RADIUS logs for an authenticated user. Also, I'm still pretty new to all of the terminology, just making sure you know that I'm talking about Authorization Policies, not Authentication Policies. That being said, let me know if this makes sense:

1. User Policy

--Wired_802.1X; and

--AD-Host-JoinPoint EQUALS domain.local; and

----xxx-ExternalGroups EQUALS xxxxx/Groups/xxx - Users; or

----xxx-ExternalGroups EQUALS xxxxx/Groups/xxx - Users;

It seems to be working correctly, but I need to make sure that it's looking for the host, not the user.

[Colby LeMaire]

Join point is just the AD domain.  Computers and users are just objects within the domain.  So you are matching on that rule because the user is in one of those groups within that same domain.  "AD-Host" does not mean the computer that the user is on.

[Colby LeMaire]

This is not possible with the way Windows operates unless you are using EAP-Chaining which requires the Anyconnect NAM.  Just recently, Windows 10 and ISE 2.7 patch 2 started supporting TEAP which gives you the same capabilities as EAP-Chaining.  Just not widely deployed just yet.

When using the native supplicant, Windows machines are in one of two states:  machine state or user state.  If a user is logged in, it is in user state and will send the user's credentials.  If the user logs out, the computer is in machine state and will send the computer credentials.  It cannot send both together without EAP-Chaining or TEAP.  So that is why you will never get an authentication to match both the computer group and the user group.

[cjdiener16]

So technically speaking, if I used machine/user as you stated above, and I brought in a personal laptop, plugged it in, manually set all of the dot1x stuff on my NIC, then I would be authenticated?

Thank you for all of the help!!

[Colby LeMaire · Accepted solution]

That is correct!  Machine Access Restrictions (MAR) was an attempt to try to solve this problem years ago but it has its own challenges since it relies on a cache of MAC addresses that have successfully had a machine authentication.  But the cache has a lifetime that is configurable.  So you had issues when someone never logged out of their machine or if they were already logged in before attempting to connect to the network.  Not to mention that rogue users could just spoof the MAC address of a good machine that did authenticate just fine.

If you have no need to differentiate network access based on who the user is, then just stick with machine/computer authentication only.  The computer connecting is more important than the user in terms of security.  A corporate machine should be managed and have patches up to date along with endpoint protection with updated signatures/policies.  When it comes to the user, just let Active Directory and server resources do their job of controlling access based on the user.  There are few good examples of having certain users on specific VLANs or having specific dACL's based on who the user is.

If you absolutely need to authenticate the user for network access, then you need EAP-Chaining or TEAP to be absolutely sure that the machine the user is using is a corporate-managed device.  I have seen others try to get around this but there is no safe way.  For example, posture checking and looking for a specific registry entry or file.  Not 100% secure since your IT folks that are aware of the checks can bypass them to get their own personal devices on if they want to.

[cjdiener16]

This all makes perfect sense and is exactly what I was looking for when I posted this thread!

Could I still use ISE for an identity source for FirePower then, since the Authorization would just be machine based? I would still be able to identify where users are logged in, just doesn't affect what they can get to, correct?

[Colby LeMaire]

You can use Passive Identity on ISE to pull the user information and then share that information with Firepower using PxGrid.  Then you would be able to apply policy to user traffic based on who the user is.  I have a client doing this same thing today.