Blocking device per category

[shpapy]

Hello,

I build a service and IM trying to block a device per category.

The device is been classified correctly but is authenticated, IM sure something is messed up with my service classification

can someone advise?

Thanks.

Authorization:[Endpoints Repository]:Category	SmartDevice
Authorization:[Endpoints Repository]:Device Name	Android
Authorization:[Endpoints Repository]:MAC Vendor	Murata Manufacturing Co., Ltd.
Authorization:[Endpoints Repository]:OS Family	Android

Policies Used -
Service:	ArubaController_UserAuthentication
Authentication Method:	EAP-PEAP,EAP-MSCHAPv2
Authentication Source:	AD:10.1.3.1
Authorization Source:	[Endpoints Repository], Active_directory
Roles:	Block_Devices, [User Authenticated]
Enforcement Profiles:	PEAP_Active_Directory_Auth
Service Monitor Mode:	Disabled

Authentication Methods: 1. [eap-tls-Authorization Required-no] 2. [MSCHAP] 3. [EAP PEAP] Authentication Sources: Active_directory Strip Username Rules: -

Authentication: Authentication Sources:   Strip Username Rules:

Authentication: Authentication Methods: 1. [eap-tls-Authorization Required-no] 2. [MSCHAP] 3. [EAP PEAP]

Authorization: Authorization Details: [Endpoints Repository]

Authorization: Strip Username Rules:   Authorization Details:

Roles: Role Mapping Policy: Block_SmartPhones

Posture: Posture Policies: Posture Policies: - Default Posture Token:   Remediate End-Hosts: Disabled Remediation URL: Posture Servers: Posture Servers: -

Proxy Targets: Proxying Scheme:   Proxy Targets:   RADIUS attributes to be removed from remote server (proxy target) reply   Type Name     Accounting Requests:

Proxy Targets: Proxy Targets:   Strip Username Rules:

Enforcement: Use Cached Results: Disabled Enforcement Policy: Encrypted_Users

Audit: Audit Server: - Audit Trigger Conditions:   Action after audit:

Profiler: Endpoint Classification: SmartDevice,Computer RADIUS CoA Action: [Aruba Terminate Session]

[cjoseph]

You could do this one of two ways:

1.  You could use the Enforcement Profile as "Radius Deny" or Radius Drop.

2.  If you are going to use Aruba Radius COA enforcement policy, you need two things:

In Configuration> Network> Devices, you need The Aruba Controller as an entry (which you probably have), but you need to make sure that "Enable Radius COA" is checked.  In addition, on the Aruba Controller side, in the AAA profile for this WLAN, you need to define and attach an RFC 3576 server profile (the CPPM server ip address and preshared key), in order for COA to work.

[shpapy]

Using option 1.

I got under enforcement so I could extend this role and add the rest of the parameters, BUT under the rules editor there is no category,

I can block by device type and vendor and IM looking for categories, that's why I added authorization source to look for category smartphone and block it but it doesn't work.

 also, cant i use role mapping and then assign a default block role for this?

Use Cached Results:	Use cached Roles and Posture attributes from previous sessions
Enforcement Policy:	[Sample Allow Access Policy][Sample Deny Access Policy]Encrypted_Userskjn	Add new Enforcement Policy

Enforcement Policy Details

Description:
Default Profile:	[Drop Access Profile]
Rules Evaluation Algorithm:	evaluate-all

	Conditions	Enforcement Profiles
1.	(Authentication:OuterMethod EQUALS EAP-TLS)	TLS_Certificate_users
2.	(Authentication:OuterMethod EQUALS EAP-PEAP)	PEAP_Active_Directory_Auth

[cjoseph]

In Role Mappings, try,

Authorization:[Endpoints Repository] Category Equals SmartDevice

To set a role that you would deny later using the Enforcement Policy.

[shpapy]

thats what i have but it dosent work. and the Enforcement Policy dosent support categories from what i see.

Policy: Policy Name: Block_SmartPhones Description: All devices categorized as smartphones will be blocked. Default Role: Block_Access

Mapping Rules: Rules Evaluation Algorithm: Evaluate all   Conditions Role Name 1. (Connection:Client-Mac-Vendor CONTAINS Murata) Block_Access 2. (Authorization:[Endpoints Repository]:OS Family EQUALS Android) Block_Access

[cjoseph]

Here is a good approach.  Create roles for devices like "Android", "SmartDevice", etc.

In your Role Evaluation Policy, use those rules to Set Roles (Tags) for Devices, and make sure you have "Evaluate All".  So A device could end up with the tags:

[User Authenticated] (built in), Android, SmartDevice.

You then use the Enforcement Policies (First Applicable) to check on the Roles, like if role Equals User Authenticated and Role Equals SmartDevice and Role Equals Android, set it to an enforcement profile that blocks access.

Long story short, Role Mappings are used to set Roles or Tags to Devices.  Enforcement Policies are used to make decisions based on all the Roles (tags) that an incoming authentication has.

[shpapy]

ok i see, but how can i pass the tag? just to use the same name ?

can you give an example of this?

also i got several enfo. policy now i need to combine them?

[cjoseph · Accepted solution]

Step1:  Define Any Role (tag) that you want your devices to have in Configuration> Identity> Roles.  For example, I would create one for Android, because that is one attribute that I want to track later.

Step2: In your Role Mapping Policy, write a rule that looks in the Endpoint Repository and If it sees that is an Android, Attach it to the Role Android.

Step3. In your Enforcement Policy use a rule that looks for authentication and TIPS: role Equals Android that you established and then set the enforcement policy to allow or block whatever you want.

Below is an enforcement policy that looks to see if the device authenticated in AD and if it has the Android role, and it sends back a reject to the controller:

[Liony Ko]

Hi Colin,

 I'm just read your old post.... Regarding your Step2 below:

Step2: In your Role Mapping Policy, write a rule that looks in the Endpoint Repository and If it sees that is an Android, Attach it to the Role Android.

If the device is never be connected (and accepted) to that SSID, then that device wouldn't recorded into Endpoint Repository right? So we didn't know whether that device is an Android or not. How to manage this case?

Thanks,

Niko

[cappalli]

You would put unprofiled devies into an interim profiling state and enable profiling on the service.