Security

Reply
Contributor II

[Tutorial] Offload RAP WhitelistDB to Clearpass

This tutorial goes over how to create a whitelistDB on the clearpass server via Local Users DB. There are a few custom SQL scripts that will be performed while obtainging attributes from the Local Users. RAP's can be staged by non-network admins with ease of provisioning via clearpass. 

 

Local User entry must contain the mac address for Username / Password along with the following items to be classified and pass radius VSA's to the mobility contorller. 

- AP-Type: 

- AP-Group:

- AP-Name:

 

 

Configure Mobility Controller to use External Radius (Clearpass)

1.aaa-auth-vpn-default_rap.png

 

 
Create SQL Authentication Source

This custom filter will allow us to derive attributes from the Local Users DB and use these attributes within an authorization source via the services policies. 

 

2.Authentication-source-general.png

 

 

 3.Authentication-source-primary.png

 

 

4.Authentication-source-attributes-type.png

select user_id, tag_name, tag_value from tips_local_users_attr_view where
((user_id = '%{Radius:IETF:User-Name}') and (tag_name like '%AP-Type%'))

 

 

5.Authentication-source-attributes-name.png

select user_id, tag_name, tag_value from tips_local_users_attr_view where
((user_id = '%{Radius:IETF:User-Name}') and (tag_name like '%AP-Name%'))

 

6.Authentication-source-attributes-group.png

select user_id, tag_name, tag_value from tips_local_users_attr_view where
((user_id = '%{Radius:IETF:User-Name}') and (tag_name like '%AP-Group%'))

 

7.Authentication-source-attributes-defaults.png

select user_id, name from tips_local_users_attr_view where
(user_id = '%{Radius:IETF:User-Name}')

 

9.Authentication-source-summary.png

 

Roles

The following 2 roles will need to be created, the RAP role is applied as a default role to the local users, and the RAP Authenticated role is derived from a successful role process via the service policies

 

10.rap-roles.png

 

 

Role Mappings

The following role mapping will allow us to validate the MAC address of the IETF:Username via the radius request and associate it with the Local Users DB. We will also be confirming some of the following attributes.

 - Enabled

 - Client-MAC-Vendor

 - AP Type: contains AP (this can be changed by users preference)

 - AP Group: exists

 - AP Name: exists

 

If not all of these values are true the device will not pass the role mapping and not receive the role RAP Authenticated. Also another note for why AP Type attribute was created is so you can have other MAC authentication services applied in the config without causing conflicts. 

 

12.role-mapping-policy.png

 

11.role-mapping-eval.png

** Note ** If you have any issues adding mappings due to attributes, you can update the attributes under the administration section.

 

 

Enforcement Profiles

It will only be necessary to create the [RAP whitelistDB - Return VSA] profile (since this data will be passed to the mobility controller). You can also create the RAP Update Endpoints DB profile as well. Since our users will be populated and used via MAC Authentication from the Local Users, we dont necessarly need to pupluate date in Endpoints. 

 

[RAP whitelistDB - Return VSA]

 

13.enforcement-profile-return-vsa-profile.png

 

14.enforcement-profile-return-vsa-attributes.png

 

[RAP Update Endpoint DB]

15.enforcement-profile-update-endpoint-profile.png

16.enforcement-profile-update-endpoint-attributes.png

** Note ** If you have any issues adding mappings due to attributes, you can update the attributes under the administration section.

 

 

Enforcement Policy

Without a successful role mapping from earlier we will fail the enforcement policy causing us to fail the radius request and get dropped. 

 

For another layer of security you can always add the [User Authenticated] role to the rules page. This way the user will need to have [RAP Authenticated] + [User Authenticated] to pass the policy page. 

 

17.enforcement-policy-name.png

 

18.enforcement-policy-rules.png

 

Services

We will apply all of our customized settings under this service profile, we will also be looking for the Client MAC Vendor whish is displayed to us via the radius request. This will also rule out any non-aruba device that may not be needed to be classified for this service policy. We will also be selecting our Local Users DB for MAC Authentication, and using our custom sql filters for the authorization settings.

 

22.service-overview.png

 

21.service-authentication.png

 

23.service-authorization.png

 

24.service-roles.png

 

24.service-enforcement.png

 

 

Create Local USer (RAP)

In the following example I have removed half of the MAC address. Esentially you can use uppercase / lowercase for the mac address and the password will be the same as the username. 

local-user.png

 

 

Access Tracker Output

After completing all of the necessary configs in the clearpass server we should be able to review access tracker and see our authetnicated user. We will also be reviewing the Authorization Attributes section under Input as this is where many of our custom options have came from. 

 

25.access-tracker-summary.png

 

26.access-tracker-input.png

 

27.access-tracker-output.png

 

 

The output of the "ap database" shows that we have received the following VSA's to the clearpass server. 

 

ap-database.png

Justin Kwasnik | ACMX# 598 | ACCX# 638
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: