Security

I am currently running a ClearPass virtual appliance (6.6.8) and would like to enforce what Service is applied based on authentication method.

I have a single SSID and would like two services as outlined:

Service 1 would be applied to any device attempting authenticating with EAP-PEAP or EAP-MSCHAPv2 and would apply enforcement policies if the computer is domain joined and the user is a member of a certain AD group.

Service 2 would be applied to any device attempting authenticating with EAP-TLS or EAP-TTLS using an Onboard certificate and again would apply enforcement policies relating to the user.

When I try to add a service rule that says "Authentication InnerMethod Belongs to EAP-MSCHAPv2 or EAP-PEAP" the policy doesn't apply even though I know that the device is using one of these methods.

Any help would be appreciated.

Not possible. The EAP methods are negotiated after service categorization. It's not a ClearPass limitation, it's how the protocols work.

Is there a list of attributes that we can actually use for service categorization?

 

The right thing would be that the GUI would not show parameters that cannot be really used, but I guess that would require some coding on an attribute dictionary extension actually telling which can be used for what. But in the mean time it would help not to waste time and avoid promises to customers that won't uphold afterwards in real life.

 

Thank you very much!

Unfortunately it varies by authentication method and workflow so we have not compiled a full list.

That is very bad news. If there is a reason for the GUI to only show those allowed is that you gave us not to have a hand written list.

 

Any basic hints on this? Perhaps what is available to match on a radius service is that shown as RADIUS attributes on the input tab of an entry at access tracker? I've noticed there that Auth:OuterMEthod is a Computed attribute, which makes sense it wouldn't be available on service match stage. On a WEBAUTH for OnGuard, the computed attributes goes after the Posture attributes I believe the agent actually submits. Is that so across all services, anything below computed cannot be used on a service match?

 

Forgive me, but I cannot let this go. I must be able to predict what would and wouldn't work. Try and error is not an approach, it's a nightmare waiting to kill us all.

 

How should we proceed to turn this from a useless complain to an actual improvement effort? Enhancement Feature Request? TAC case? Crying outloud?

Please provide more details about the workflow you're trying to accomplish.

EAP-TLS and PEAP on the same SSID. EAP-TLS against an external CA whose certificate I uploaded into ClearPass. PEAP against an Active Directory. EAP-TLS should fail if the certificate provided belongs to the AD and only succed if is validated by the external CA.

 

With two services, I would simply set local db as the auth source on the AP-TLS process. The PEAP auth would use AD as the auth source.

 

But on a single service I must add AD as the auth source for both TLS and PEAP, making it far more complex, requiring enforcement to reject specific cases where TLS succeds against AD.

 

But I did not want to solve my problem, I want to be able to tell if something would work before making any promises to the customer, that is presales, without a full test lab to tell if it actually works and the GUI is not missleading letting you choose a value you cannot use.

---

@PADUA-RLUIS wrote:

I am currently running a ClearPass virtual appliance (6.6.8) and would like to enforce what Service is applied based on authentication method.

I have a single SSID and would like two services as outlined:

Service 1 would be applied to any device attempting authenticating with EAP-PEAP or EAP-MSCHAPv2 and would apply enforcement policies if the computer is domain joined and the user is a member of a certain AD group.

Service 2 would be applied to any device attempting authenticating with EAP-TLS or EAP-TTLS using an Onboard certificate and again would apply enforcement policies relating to the user.

When I try to add a service rule that says "Authentication InnerMethod Belongs to EAP-MSCHAPv2 or EAP-PEAP" the policy doesn't apply even though I know that the device is using one of these methods.

Any help would be appreciated.

---

Why do you want 2 services ? You could do this under 1 service with 2 authentication methods and specify enforcement profiles with the conditions you montionned.

I have managed to resolve the issue by applying an Enforcement Policy that states if the device is [Machine Authenticated] and attempting EAP-PEAP or EAP-MSCHAPv2 authentication to allow, and if device is attempting to authenticate with EAP-TLS to allow, anything else to deny.