02-28-2019 12:44 PM
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!
Solved! Go to Solution.
03-19-2019 09:04 AM
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
03-13-2019 03:02 PM
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
03-14-2019 05:26 AM
03-14-2019 05:52 AM
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.
03-14-2019 06:49 AM
03-14-2019 06:59 AM
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.
03-14-2019 08:49 AM
03-14-2019 11:47 AM
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.
03-19-2019 08:04 AM
03-19-2019 08:43 AM
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.
03-19-2019 08:54 AM
03-19-2019 09:04 AM
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
03-19-2019 09:33 AM
03-19-2019 09:47 AM
03-19-2019 10:59 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide