MAB Authz Condition Matching Options

[Mike.Cifelli]

Currently I am in the process of configuring the default mab authz rule to use CWA with a guest portal for hosts that plug into my SDA fabric that dont match any other rules.

Current issue I am facing:
We utilize NAM/eap-chaining to authenticate computer + user via eap-fast(eap-tls) with certs/cac cards. I have several policies setup that have different results depending on the eapchaining result. Everything works great and as planned, except when a user simply locks their host prior to going home. Per requirements we re-authenticate every 60 minutes. If users reboot their host prior to heading out the eapchaining result is machine pass with user fail. For the users that simply lock their box, NAM eventually looks for user CAC, and 8021x process fails so they fallback to mab.

I have attempted setting up authz conditions that are based on eapchaining result EQUALS no-chaining. This seems to work during testing for a short period of time before the endpoint abandons session and fallsback to mab.

I am looking for suggestions on how I can keep the default rule redirecting unknown hosts to the portal, and also figure out a solution for the users who may simply lock their host when leaving for the day that fallback to mab. This will need to be a rule above the default obviously.

Thanks in advance!

[howon]

Is the goal to prevent EAP-Chaining machines from falling back to CWA? Two options I can think of:

- Use longer reauth timer or none at all

- Use AD profiling to profile domain joined machines to endpoint group and create a rule to provide limited access above the default rule for CWA

[Mike.Cifelli]

Is the goal to prevent EAP-Chaining machines from falling back to CWA? Two options I can think of:
The goal would be for endpoints/users that previously authenticated via eap-chaining to not fallback to mab if user cert is not present when computer locked and re-auth kicks in. The issue I am facing is that whenever a computer is locked/unlocked but no user cert is present eap-fast inner method wants user cert first (which obv fails) and 8021x process terminates and falls to mab. You would think that machine cert would pass, user fail, and I could drive policy based on that result. Fortunately that works on reboot, or complete user session logoff. It is only when user session is still active and missing cert on re-auth that I face the fallback problem.

- Use longer reauth timer or none at all
I have to use 60 min re-auth per requirements so unfortunately this is not an option.

- Use AD profiling to profile domain joined machines to endpoint group and create a rule to provide limited access above the default rule for CWA
Can you provide examples of this scenario?

[paul]

Mike,

Assuming you are collecting DHCP attributes from the devices and have the AD profiler enabled you should see an attribute under the endpoint that says "AD-Host-Exists".  You can set a profiling condition of AD-Host-Exists=true and call it Hostname_Exists_In_AD and then use this in your MAB rules.

[Mike.Cifelli]

I am working on testing this as we speak. I see that the default AD check is set to 1 day. Any experience on tweaking the scan? Also, is CoA necessary? The only thing I can currently think of is for devices that get profiled as "unknown"? If a host has not been profiled but is determined that it is a part of AD and the proper AD join point it should automatically go to that endpoint group. OR do I need to do a CoA so that it will re-auth and hit the mab authz policy that maps to the internal group upon classification?

[paul]

You should have CoA Reauth set globally for reprofile or you can set it on the profile you build.  The device should change from Unknown to the new profile you built if the AD host exists data is there.  If you don't see that field then you may not be collecting DHCP information.  The AD profiler works by collecting DHCP hostname and checking it against AD.

[Mike.Cifelli]

So I setup CoA reauth on the profile I built. I see several AD attributes in live log details. However, I do not see AD-Hosts-Exists. DHCP profiler is enabled. A lot of the endpoints that authenticate via 8021x or mab are already profiled (i.e.-Windows 10 Workstation, Hp-Device, etc.). The new profile is set to add hosts to a new endpoint group based on AD-Join-Point & AD-Host-Exists. How will this affect the already profiled devices? How do I get the already profiled devices added to the new profiled group based on the new policy and keep them profiled as for example a Win10 Workstation? I have the two conditions mentioned above certainty factor set to 15 on both with a minimum of 30. My new policy at the moment is not working as expected & configured. Appreciate the assistance in advance.

[paul]

Whenever you build a custom profile it should supersede the Cisco defaults.  They way you do that is make your MCFs higher.  Make yours in the 100+ range.  If you want to still track OS type you can create subprofiles underneath for Windows 10, Windows 7 etc, but once you create your own the Cisco defaults won't be used for anything matching your profile.

If you don't see AD Host Exists in AD make sure you got DHCP hostname for the endpoint.  Look at the bottom in the attributes of the endpoint for DHCP data.

[Mike.Cifelli]

So in the live logs I see:
AD-Host-Resolved-Identities
AD-Host-Candidate-Identities
AD-Host-Join-Point
AD-Host-Resolved-DNs
AD-Host-DNS-Domain
AD-Groups-Names
AD-Groups-Names
AD-Host-NetBios-Name

I do not see the AD-Host-Exists. TAC mentioned that I have to have an IP helper pointing to both of my PSNs in order for that probe to work as expected so I can then see the attribute. Can you provide more detail on the OS types via subprofiles please. Thanks

[paul]

TAC always says that and you should chuckle at them when they do.  You only need IP helper forwarding to ISE if you aren't doing IOS device sensor to collect DHCP data.  If your switches support IOS device sensor you should be using that to get DHCP data to ISE.  DHCP hostname data is required for the AD profiler to work correctly.

[Mike.Cifelli]

I will respond to my case and mention that. Now that you mention the device sensor I actually saw that configured in a labminutes video as well. So currently on my test switch I have the following:
device-sensor filter-list dhcp list iseDHCP
option name host-name
option name parameter-request-list
option name class-identifier
device-sensor filter-spec dhcp include list iseDHCP
device-sensor notify all-changes

Strange that I am getting some AD attributes as noted in a previous post, but not getting what I want. TAC did mention to enable DNS probe as well so I did. Still no dice.

[paul · Accepted solution]

DNS probe used to work for AD profiler, but that has been broken since 2.4.  The only way to get AD profiler info is to get DHCP data for the endpoint into ISE.

Make sure you have device sensor accounting enabled as well.  Depending on your version of code the commands will be different.

It could be this:

device-sensor notify all-changes

It could be this:

access-session accounting attributes filter-list list Def_Acct_List
 protocol cdp
 protocol lldp
 protocol dhcp
 protocol http
access-session accounting attributes filter-spec list Def_Acct_List

Or this:

access-session attributes filter-list list Def_Acct_List
cdp
lldp
dhcp
http
access-session attributes filter-list list Def_Auth_List
vlan-id
access-session accounting attributes filter-spec include list Def_Acct_List
access-session authentication attributes filter-spec include list Def_Auth_List

[Mike.Cifelli]

Test switch (cat 9300) is running Fuji 16.09.02.

You mentioned this: If you don't see AD Host Exists in AD make sure you got DHCP hostname for the endpoint. Look at the bottom in the attributes of the endpoint for DHCP data.

I do not see DHCP data either near the bottom of attributes in live logs. However, under context visibility I see 14 AD attributes and two DHCP attributes when looking at an endpoint.

AD Attributes seen:
AD-Groups-Names
AD-Host-Candidate-Identities
AD-Host-DNS-Domain
AD-Host-Join-Point
AD-Host-NetBios-Name
AD-Host-Resolved-DNs
AD-Host-Resolved-Identities
AD-Last-Fetch-Time
AD-User-Candidate-Identities
AD-User-DNS-Domain
AD-User-Join-Point
AD-User-NetBios-Name
AD-User-Resolved-DNs
AD-User-Resolved-Identities

DHCP Attributes seen:
dhcp-class-identifier
dhcp-parameter-request-list
host-name

Based on what I am seeing there I believe that the device sensor is working as expected & configured. Still not sure why I do not see AD-Host-Exists. I am running ISE 2.3p5. Are there any known bugs?

[Mike.Cifelli]

So I just realized that I am actually seeing AD-Hosts-Exists on my SDA hosts where I have the proper device-sensor stuff configured. The few endpoints that I was checking are non-SDA hosts on gear that is not configured to support the AD attribute stuff. I apologize for the inconvenience.

So let's say I enable this new profile with a 100-150 MCF to then dump MACs into a L2 group. This profile deployment will cause everyone to be re-profiled, but the non-SDA hosts will still get profiled as the current profile that they are since they will not match the AD-Hosts_Exist check since I do not have the proper switch configs deployed, correct? If so, then I should be able to slowly tweak the pre-defined Cisco profiles (i.e- Win10, Win Workstation, etc.) to be a sub profile under the new one I deploy, correct?

[paul]

Once you see AD Host Exists in AD you will see:

AD-Operating-System

Windows 7 Professional

Write sub profiles based on that.  Forget the Cisco default profiles.  Build your own.