last person joined: 4 days ago 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Clearpass & OnGuard (wired cisco)

This thread has been viewed 4 times
  • 1.  Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 12:11 AM
    Anyone running CPPM with OnGuard? How do you implement enforcement? Vlan DACL? How does it inform users they are in a remediation ?

    This is a Cisco Wired environment.

  • 2.  RE: Clearpass & OnGuard (wired cisco)

  • 3.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 12:39 AM
    Thanks for the link. I did set that up and got it working however not really sure how the OnGuard piece functions. And how we will inform our wired users that don't have the agent.

    I'd really like to have a DACL enforcement. With no Vlan switching.

  • 4.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 12:44 AM

    OnGuard is a very flexable module and I would recomend to work with the local SE or partner on setting it up.


    We are constantly releasing new How-To documents and I will post a notice here when its avaible. 

  • 5.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 01:03 AM
    Thanks we had a demo but we didn't get a full demo. Couldn't really find any how-to on the OnGuard piece. Document I did find seems tie in with Clearpass guest. I'm interested how OnGuard will notify users to remediate.

    Thanks. I'll look forward to more how-to's :-)

  • 6.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 01:16 AM

    You have the option to have the persistent client auto remediate without moving the client to a remediation role, or you can bounce or apply a role or DACL to the client and force the user to a captive portal to inform them to self remediate. 


    When a client is healthy 

    screenshot_01 May. 23 00.10.gif


    In my lab I have a sample posture to look for notepad.exe and if the agent finds the program running it will close the program and post a notification to the agent without moving the client to a different role. Again its very flexible so its comes down to what you would like to do. That's why its important to work with a local SE until a current document is posted.


    screenshot_02 May. 23 00.12.gif


  • 7.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 23, 2013 07:55 AM
    Thanks we did work with our SE. He just was not a Clearpass specialist. Do you know how clearpass can force a captive portal for a computer? Is this done using a radius url redirect or a specific vlan. He only showed us things on our aruba controller so it was not applicable to our wired network.

    Thanks for all your help.

  • 8.  RE: Clearpass & OnGuard (wired cisco)

    Posted May 25, 2013 01:25 PM

    i think this applies somewhat for the wired side if it isn't aruba:


    i build something similar and did use seperate vlans for healthy and unhealthy clients, the client can show a message and you do need it to do health checking, without your choices are limited.

  • 9.  RE: Clearpass & OnGuard (wired cisco)

    Posted Jun 05, 2013 08:53 PM
    Any documents on how to deploy the OnGuard agent to computers in a cisco wired environment? IE computer that has credentials but someone uninstalled agent or never was installed. ??

  • 10.  RE: Clearpass & OnGuard (wired cisco)

    Posted Jun 07, 2013 06:51 PM

    Most end up using domain policy to just force the client down. There are many examples of Domain policy to install applications.

    The general Idea is that the computer will do a Machine Auth that will get a DACL for the quarantine network that has access to the basics (DNS,ICMP, CPPM and normally AV server and AD);

    Domain policy pushes onguard to the machine when it refreshes the domain policy.
    When a user logs in the get [Machine Auth][User Auth] and Unknown role which can be another DACL

    Onguard then runs and bounces the clients NIC


    User comes in again with the above but healthy and gets the full DACL.

    Your DACL's have to be exact or the cisco switch will not accept it. Meaning, no conflicting rules, not leading or trailing spaces.

    (a conflicting rule would be something like allow UDP any any and another rule that says allow DNS any any, since DNS is UDP 53 cisco treats it as conflicting rules; at least it did on the build I was using);


    Since I am not allowed to disclose client information, I can say there are several VERY large companies that are using onGuard with cisco, one specifically using DACL's.


    Let me know if you have any other questions.

  • 11.  RE: Clearpass & OnGuard (wired cisco)

    Posted Jun 07, 2013 11:41 PM

    That sounds simple. Yea I guessed getting application installed on corporate devices but what do you do with personal devices? We are looking at doing DACL enforcement where we can then SVI enforce on our older switches. Our management wants web-auth for everything. We want our users to be directed to each step. Any of your clients doing web-auth on cisco switch via clearpass/guest?

    Thanks for the previous reply. This is a complex product especially in multi-vendor environments. :-)

  • 12.  RE: Clearpass & OnGuard (wired cisco)

    Posted Jun 10, 2013 02:03 PM

    Using webauth on switches unfortunitly has not been very sucsessful. This is because most switches require you to make a choice on your auth methiod based on port. So you can either have MAB or 802.1x or MAB with 802.1x or Webauth. 

    Not Webauth + Something else. So because of this people tend to stay away as port function in the network is more dynamic. 

    After all who wants to open a support ticket with the network team because the printer moved from 1 cube to another. 


    Personal devices are normally limited to just wireless. This way you can use onboarding and multiple captive portals to get them from place to place. Hardwried becomes a challenge because captive portals at the ethernet level hasnt really taken off; 

    I know that our switches have been doing it for a while, but that is because we rely on a 'role' based authenication model where others do port based.

    So we can have a captive portal per role and COA your role at will. 

    With cisco you can COA the DACL, but because the captive portal stuff is port based, you cant COA the configuration of the port. 


    You might be able to do some sort of telnet enforcement; Where you change the running config based on a telnet enforcement profile; But i have never tested nor attempted this, so i dont know if its possible. Even then, seems like a lot of problems that can happen with timeouts. 


    This might be one of those situations where its best to limit to wireless only.