Security

Trying like heck to finalize this service so that non-dot1x devices authenticate via MAC auth through my Cisco switch.  My criteria is very simple...if the Endpoints Database Device Category = AP or Printer or video-conferencing  AND it's status equals Known, allow access via the [Allow Access Profile]. 

I've been able to get my test Aruba AP to connect successfully using the service, HOWEVER, I never flagged the status as "KNOWN".  It's being allowed access, even with a status of "unknown".  Not sure if this has to do with the fingerprinting process in conjuction with the Enforcement Policy's default profile (DACL For Fingerprinting profile was created to allow DHCP for fingerprinting). 

Here are some screenshots of how it's set up:

Service Summary

Enforcement Tab

Enforcement Policy

Enforcement Profile

Profiler Tab

With the device needing to be fingerprinted first, not sure if this is the correct flow, but I'm all ears for suggestions.  And I do realize that it will be a manual process to mark each AP/Printer/Video-Conf as "known".  I'm also not doing any roles or dynamic vlan'ing.  It's a very simple "pass mac auth and use the settings on the switch port".  

Thanks for any help!

Here is my guess:

The "Default" profile is what is triggered when no rules are satisfied.  In the screenshot, your default profile is [ACE] DACL for Fingerprinting.  If that profile allows users to get on, they will get on.  You should make your default profile the Deny Access Profile.  That could get you to the next step.

The reason the device is getting on is due to the Authentication Method you are using: [Allow All MAC AUTH].  This method allows unknown endpoints to connect.

The [Allow All MAC AUTH] method is typically the correct method to use if you want to identify/profile devices before placing them into the correct VLAN.  You have to allow the device on to profile it. 

The workflow allows the device to connect, if the Endpoint Category is not what it needs to be than the default profile is used to place the device into a state on the switch which allows fingerprinting.  Once fingerprinted, the port is bounced, and authentication is reattempted and taken thru your enforcement policy checking for the correct VLAN to place the device in based on Endpoint Category.

Here's the basic flow:

1) The first time a device connects, it's allowed on in a limited state (session timeout is a low value and DHCP is allowed) because it doesn't match any Enforcement policy rules based on Endpoint Category.  The default enforcement profile is used.

2) The device requests an IP address via DHCP.  DHCP packets are sent to CPPM for profiling due to IP Helper statements on the VLAN.

3) CPPM receives the DHCP info and fingerprints the device.  Because the Profiler tab is used in your Service, the system knows if there's any change in the Category/OS Family/Name, bounce the Cisco port.  This all happens magically in the background.  The session timeout value is there just in case the bounce (or Radius CoA) doesn't work.

4) After the port bounce, the device reauthenticates, and regardless of whether the device is marked known or unknown, the device is allowed on.  Based on the new Endpoint Category for the device, the enforcement policy places the device into the approriate VLAN defined in the enforcement profile.

Hope that helps.

Chris

Thanks for the replies Colin and Chris. 

So the rub is...how can a device show up in the endpoints db as fully fingerprinted, but also have a 'deny access' as the default enforcement policy? Would changing the [Allow All MAC AUTH] to just [MAC AUTH] make this easier?

What you likely will need is to set the default profile in your Enforcement Policy to [Deny Access Profile] and have a enforcement policy rule that check the Category to see if it exists.  Something like: "Authorization:[Endpoints Repository] -> Category -> NOT_EXISTS -> Assign profile -> [ACE] DACL for Fingerprinting.

Chris

Tried the approach of appending "Authorization:[Endpoints Repository] -> Category -> NOT_EXISTS -> Assign profile -> [ACE] DACL for Fingerprinting" to the beginning of the Enforcement Policy Rules, but alas,  no luck. 

TAC is telling me that because MAC only works on Layer 2 that you need to successfully MAC auth before fingerprinting via DHCP.  This seems just the opposite of what I'm trying to do....I'm trying to fingerprint the device, then MAC auth it. 

Still lost and still not a fan of Clearpass. :-(  This shouldn't have to be that hard. 

RyanNetEng,

Based on what you are trying to do, ALL devices must successfully mac auth:

- Devices you do not know about must be successfully place into a VLAN that has the helper address pointing to CPPM for profiling.  The rule you had before needs to point to the Enforcement Policy that allows the user on, and give him a short session-timeout so that he reauthenticates right after being profiled.  This is what should allow the device enough time to get an ip address and have it profiled.  The questin 

- Devices you do know about get mac authenticated, but get switched to a different VLAN based on what type of device it is.

The layer 2 statement is valid, and you simply let an unknown device on, but do not make any fingerprinting decisions about it, because you don't have a fingerprint yet.

Where are you getting stuck?  If you have a device that is not known, is it hitting the rule that you want it to?  Remember that every time you plug in the device, you need to delete it from the endpoints table to simulate that it was never known.

Thanks for staying with me on this, Colin. I really appreciate it.

So to answer your questions, yes, the correct Service is being hit, however it isn't working as planned.

Here's what I'm trying to do...I only want peripheral devices that can't do .1x (VoIP phones, Aruba AP's and Printers) to be authenticated against the Endpoints DB.  To avoid any spoofing, one of the criteria in the Enforcement policy is that the entry in the Endpoints DB has to be marked as "known", as well as the OS Family must match the device type, i.e a device posing as an Aruba AP must be fingerprinted as using the Aruba OS.  All of these extra caveats are simply to prevent spoofing.  I don't want to inject roles and dynamic vlans correlating to those roles.  I want the switch ports to run the show for VLAN assignment.  I want ClearPass to say "yes, it's a known peripheral. turn the port on" or "no, I don't know who you are, keep the port off".  

So while testing all of these settings I've created the following service (I'm still using ACE in the title since you were here last year :-) 

Authentication Tab 

Authorization Tab

Roles Tab (not really using them, but just in case I have this in there):

Enforcement Tab

Enforcement Profile 'Dead End VLAN for Profiling' (VLAN 999 is a null VLAN with IP Helpers pointed to ClearPass only)

Enforcement Profile '[ACE] Wired data Dynamic Vlan' (the %{Device:data} value uses the configuration of the switch port vs. a dynamic VLAN assignment from ClearPass). 

...and lastly, the Profiler Tab

So after plugging in the AP with all of the setttings above in place, here is what I get in Access Tracker (x3 times):

...and the device never gets fingerprinted

**It should be mentioned that yes, during testing I delete the entry from the Endpoints DB **

Things I've noticed:

1. When I change the method to 'Allow All MAC Auth' in the Authenticaton Tab the device gets fingerprinted and stays in the status of "unknown". However it is let on all the way as if ClearPass wasn't even in the mix. 

2.  Having the first rule in the Enforcement Policy of "If the device is not profile in the Endpoints DB, assign the device this NULL VLAN so it can get profiled" does nothing.

So I'm still at a loss on the flow.  If all devices are to MAC Auth against the endpoints DB, how is any authentication possible if the device isn't profiled?  What is it authentication against?  With DHCP being L3, as well as DHCP being the process by which a device is fingerprinted and the Endpoints DB populated, how can an authentication take place on L2 when the L3 activities haven't happened yet? Forgive my ignorance, but this is simply not clicking for me.

You'll need to have the Authentication Method set to [Allow All MAC AUTH] instead of [MAC AUTH].  When using [MAC AUTH], the mac address of your device must be marked KNOWN to successfully authenticate.

What you want to do is use [Allow All MAC AUTH] and allow the device "on" to pass thru the authentication phase onto the role mapping and enforcement policy phase.  Even though you allow the device "on", you can reject it based on the enforcement policy rules.  Try not to worry about KNOWN versus UNKNOWN at this point.

Try this test:

1) Delete your endpoint from the Endpoint Repository. By doing this you'll start the flow as if the device never authenticated in the past and CPPM has never seen/profiled the device before.

2) Change the auth method to [Allow All MAC AUTH]

3) The 1st condition of your enforcement policy should be "Authorization:[Endpoints Repository] Category NOT_EXISTS -> Dead End VLAN for Profiling".

4) The enforcement policy should have a default profile of "[Deny Access Profile]".

5) In the Profiler tab, change the RADIUS CoA Action to "[Cisco - Bounce-Host-Port]".  Make sure your switch is configured for this.  See "aaa server radius dynamic-author" command.

Basically, the 1st enforcement condition identifies that your endpoint has not yet been profiled.  Because the device hasn't been profiled, your profile 'Dead End VLAN for Profiling" allows the device on the network with limiting functionality (get IP address via DHCP, set small session-timeout value like 60 secs).  This "dead end VLAN" needs an DHCP HELPER IP configured to point to CPPM so that when the client requests a DHCP address, it's not only sent to your proper DHCP server but also CPPM for profiling. 

Once profiled by CPPM, a RADIUS CoA will immediately be sent to bounce the switch port.  If everything is configured properly, CPPM will send the CoA almost immediately after the device initially gets an IP address on the profile VLAN.  After the port bounce, and upon reauthentication, the Endpoint Repository:Category for that endpoint will EXIST and actually be something of value for you to test with in your enforcement rules.  i.e. OS Family = Aruba ->Assign AP VLAN.  Add the enforcement rules you need to only allow the device types you want and assign VLANs appropriately.  These rules can be very specific and detailed to only allow the device types you want on your network.  Lastly, the Default Profile "[Deny Access Profile]" kicks in when the device does not meet any of your enforcement rules. 

To prevent MAC spoofing, you can change your enforcement rule #3 to "Authorization:[Endpoints Repository] Conflict EQUALS TRUE -> [Deny Access Profile]".  If there's an endpoint with this condition, both the real endpoint and spoofed endpoint will be denied access if it tries to access the network.

Chris

Sorry for the late reply on this Chris...Greatly appreciate you taking the time to lay all this out for me. Been away at Cisco training and working on other projects, so picking ClearPass back up today.  What you said makes perfect sense and worked great.  Thanks again!

Hello, I'm bringing up this old thread because I have similiar issue.

Question: It's possible in role mapping(or enforcement) check if the mac is known or unknown in the endpoints database?

---

I have thousands of VOIP that makes impossible to mark all of them with mac known. So I'm using [Allow All MAC AUTH], then I have role mapping and enforcement, if category = VOIP then Permit access

It's working fine.

But now I need to grant MAB for some computers.

I can't use the same flow, because if I do it, I will grant access to all computers. I want to only grant MAB for mac address that I set as 'known'

You can create a new Enforcement Policy (or add to an existing MAC Auth Enforcement policy) that looks like this:

Authorization [Endpoints Repository]: Status EQUALS Known 

Actions:  Allow Access Profile

Thank you Ryan!