Security

The one thing that I really dig about Clearpass is the flexibility - the one thing that drives me up the wall is the lack of something akin to the VRDs. I figure, if I can't find it in the docs, I might as well create it and share it. I have a couple of solutions that I've put together that I will be sharing in the upcoming weeks.

 

The first one is how to authenticate Airwave via Clearpass. My lab is running Clearpass 6.2 and Airwave 7.7.3. I have a Windows 2012 server with defined users and groups and I've built the necessary role mappings under Configuration > Identity > Role Mappings in Clearpass. I've also created Clearpass / Tips roles that are mapped to my Windows 2012 groups.

 

Here's the steps necessary for Airwave to authenticate to Clearpass via RADIUS.

 

Airwave:

 

Setup the Radius Configuration in Airwave:

 

1. AMP Setup > Authentication > Enable RADIUS Authentication and Authorization > "Yes"
2. Add the Clearpass information to "Primary Server Hostname/IP Address"
3. Add the Clearpass shared secret to "Primary Server Secret" and confirm that secret
4. Click "Save"

 

Add a new Airwave user role:

 

1. AMP Setup > Roles > Add
2. Create a role called AMP-Administrator
3. Select a type of "AMP Administrator"
4. Check "Enabled" as Yes
5. Click "Add"

 

Clearpass:

 

Add the Airwave network device to Clearpass:

 

1. Configuration > Network > Devices
2. Add the Airwave "IP or Subnet Address"
3. Enter the "RADIUS Shared Secret" that was defined above.
4. Select "Vendor Name:" of "Aruba"
5. Click "Save"

 

Add the Airwave network device to a Device Group:

 

I use device groups for everything in Clearpass. This step can be optional, it's just my personal preference.

1. Configuration > Network > Device groups
2. Select "Add Device Group"
3. Fill in the "Name" field
4. Select "List" under "Format"
5. Under the "List", move the Airwave Server IP from the "Available Devices" to "Selected Devices"
6. Click "Save"

 

Create an Airwave Enforcement Profile:

 

1. Configuration > Enforcement > Profiles
2. Click "Add Enforcement Profile"
3. Select "Aruba RADIUS Enforcement" as the Template
4. Provide a name, "Aruba Airwave"
5. Make sure that "Accept" is set under "Action"
6. Under Attributes:
i. Type - "Radius:Aruba"
ii. Name - "Aruba-Admin-Role (4)",
iii. Value - "AMP-Administrator"
7. Finally, click "Save"

 

Create an Airwave Enforcement Policy:

 

1. Configuration > Enforcement > Policies
2. Click "Add Enforcement Policy"
3. Under "Enforcement", provide a name, "Aruba Airwave Login Enforcement Policy"
4. Verify that RADIUS is the "Enforcement Type"
5. Select "[Deny Access Profile] for the "Default Profile
6. Select "Rules" and click "Add Rule"
7. Mine looks like this:
   i. Type - Tips
   ii. Name - Role
   iii. Operator - EQUALS
   iv. Airwave-Admins
8. Enforcement Profiles > "Profile Names" > "[RADIUS] Aruba Airwave"
9. Click "Save"

 

Create an Airwave Login Service:

 

1. Configuration > Services
2. Click "Add Service"
3. Select "Type" of "RADIUS Enforcement ( Generic )"

4. Provide a name for the service, "Aruba Airwave Logins"
5. Under "Service Rule" enter the following:
   i. Type - Connection
   ii. Name - "NAD-IP-Address"
   iii. Operator - "BELONGS_TO_GROUP"
   iv. Value - "Aruba Airwave"
6. Under Authentication:
   i. Authentication Methods - PAP
   ii. Authentication Sources - <your AD>
7. Under Roles select the "Role Mapping Policy" for your domain. Here's what mine looks like by clicking "Modify."
   i. Type - Authorization:Windows-2012
   ii. Name - memberOf
   iii. Operator - EQUALS
   iv. Value - CN=Airwave-Admins,CN=Users,DC=top,DC=local
   v. Actions > "Role Name" > "Airwave Admins"
8. Under "Enforcement" > "Enforcement Policy" select the enforcement policy that we created > "Aruba Airwave Login Enforcement Policy"
9. Click "Save"

 

That should be it. You now should be able to log into Airwave with your AD credentials via RADIUS. You can verify that things are working by attempting to login to Airwave and viewing the results in Clearpass at the Access Tracker found under Monitoring.

 

Also, the above steps can also be extended to map AD users to other Airwave roles, such as a Help Desk account. 

 

Let me know what you think and if it works out for you.

 

-Mike

Thanks for the guide.

There also is an arubapedia guide but I will check to see what the class level it is. It might be set for partners only.


Thank you,
Troy Arnold
tarnold@arubanetworks.com

Please excuse any typos
Sent from my mobile device

How did you know I was just about to embark on that step!!?!

 

Thanks

Matthew,

 

I had a feeling there might be a couple of people out there in a similar boat. 

 

-Mike

Excellent work boston1630, thanks for your contribution.

 

To follow up on your work, I've created an enhancement request for CPPM to add a "Service Template" that does something along these lines.  This should simplify the task of integrating AirWave logins with ClearPass in a future software release - not sure which one at this point, but the ticket is in the system (it's #17427 FYI).

 

Thanks again and I look forward to seeing more great solutions!

Hi Dave,

 

Thanks - that's an awesome idea! I'll be looking forward to this in future releases.

 

-Mike

This is something I'm trying to do, but I don't have the liberty of creating the groups in AD. However, I'd WOULD like to use AD for authentication. My thinking was that AD could be used for authN while the clearpass local DB could be used for authZ.

 

So, "holland" could exist in AD with my password.

Then, "holland" would exist in the CPPM Local DB with associated attributes on which the CPPM enforcement policy leverages to return the appropriate Airwave role.

Has anyone made this work?

Hey Ryan,

Try using AD as your authentication source and the Local Users SQL Db as your authorization source and then in the enforcement profile reference the TIPS role that is assigned in the local user database.

 

 

 

 

Did that, except I used custom attributes instead of tips role since I will need more granularity. No dice. I have a TAC case opened but was thinking somebody may have already done this in the community...

Ryan,

 

You can do what you are trying to accomplish. I just tested in my lab. The only thing is in you AD/LADP source make sure you uncheck "Enable to use this authentication source to also fetch role mapping attributes"

 

 

I just made a copy of my AD Auth source and used it only for airwave.

 

Troy,

Can you try and reproduce what I'm doing though? Use your AD for authentication but then use the Local database for authorization.

- Ryan -

Yes I was able to get it working. I will be in my office tomorrow if you to have a quick call in the afternoon

Troy,

Not sure how you got that to work. When I try to copy the [Local User Repository], I get this error:

"You are not allowed to copy a Local type of Authentication Source"

. . . so, how were you able to pull this off?

- Ryan -

Ryan,

 

I copied my AD source not the Local user.

 

I copeied that one so I could modify the setting not pull role atributes for that service. Im pulling roles for other services from my AD so I didnt want to mess with the original.

 

I Authenticated against AD and then just authorized off the local DB roles assigned to the same username.

 

 

Could you leave the option "enable to use this authentication..." option enabled and still accomplish the goal?

 

I believe that we are doing something similar except we are using two external LDAP's.

 

The common point between the two is the user name. We can then use this name to do lookups in the secondary LDAP as the secondary source contains far more information. We then added the secondary LDAP as an authorization souce. In the Access Tracker we can see attributes pulled from both the authentication source as well as the authorization source. 

 

I think you could build rules based on both. Not sure if it works differently with the local db though.

 

 

The problem is that if you leave that checked and CPPM finds that they belong to a group it will use that as the member of.

You most likely be able to do it with some creative policies but it was just easier in my lab to disable that option so CPPM will only look at my local roles.

Ah that makes sense!

 

I am not 100% familiar with the working relation between the CPPM and AD as I don't have an AD to work with directly.

 

keeping it simple is alway better when possible!

 

Thank you for the clarification!

 

Cheers

Troy, support has told me I had to submit a feature request, as this is not currently supported.

https://arubanetworkskb.secure.force.com/cp/ideas/viewIdea.apexp?id=08740000000LDzm

 

If you have this working, please let me know when you have time so we can get this working at OSU.

 

Thanks!

I followed your instructions before I had a handle on roles and enforcement (not sure I do yet) and it didn't work for me.

 

After getting several other device groups working and learning a bit as I did, I was able to fix my implementation of your instructions.

I'm not sure if it's a typo, or just a stylistis varyation, but "fixing" it made mine work.

 

Under "Create an Airwave Enforcement Policy:" you have:
 7. Mine looks like this:

 ...
  iv. Airwave-Admins

 

while under "Create an Airwave Login Service:" you have:
 7. Under Roles select the "Role Mapping Policy"...
  v. Actions > "Role Name" > "Airwave Admins"

 

I edited the enforcement policy to use the role equal "Airwave Admin" (note the space vs. dash) so that the two stanzas match and got much better results.

 

Matthew, can you explain this further? Are you refering to screen shots, because I didn't see any. It's just not clear what you have created. I appreciate the involvement; let me know what you have.

 

Thanks!

I was refering to the original-post -- if my (limited) understanding of the roles and enforcement policies is any good, there are two references to the same role - one with and one without a dash.

 

I was actually planning on starting on your problem next - since I also don't have AD access, and need a few "groups" which don't exist. I'll post my results as I go.

Just to explain a little more on what Ryan is doing is creating a custom attribute on a role. Not using just the role itself. We will need to use a custom sql query to use the attribute that he created to do what Ryan is trying to accomplish.

For example

Tarnold=ad
Admin=local role
Airwave admin=custom attribute in admin local role

For anyone that needs it, I finally got this to work with the help of Aruba TAC's Mathew. (Thanks!) Basically, we had to build a custom SQL filter/query for the local database. Go into the local DB authentication source, then under the attributes tab to create new. Then create something like what I've attached. This will allow you to then build enforcement polices based on the value of the custom attributes. Tons of use cases, but as of now, I'm using central AD for authentication and Clearpass local DB for authorization. I'm pretty happy with these results.

 

Hi

 

I think I've followed the instructions but it's not working and I'm looking for some help. Everything is working on the ClearPass side. I can see the request come through via Access Tracker. It's accepted and I can see the User-Role being pushed back to Airwave

Radius:Aruba:Aruba-User-Role

AdminViaClearPass

 

This role is configured as an AMP-ADmin in Airwave (as instructed) and the role is enabled. However, from the Airwave login page I'm just getting login denied. What am I doing wrong?! Is there somewhere I can look in Airwave to show me the Accept coming back from ClearPass?

 

Thanks in advance for the help and feedback.

 

I'm using a beta of Airwave v8 against a 6.3.0 ClearPass install.

 

Chris

 

 

The Radius:Aruba attribute you need to send from ClearPass to airwave is Aruba-Admin-Role, not Aruba-User-Role.

Cheers Ryan. Apologies to all for not following the instructions exactly!!!

Hi guys! Great guide.

 

I've got an Airwave implemented like this and on my authentication source (AD) I had to check Allow bind using user password to get the authentication to work.

 

The issue I'm facing:

When I log in for the first time in a while, the authentication will always fail and this is what pops up in the access tracker:

 

 

If I log in again straight after, the login will be successful and I'll see my admin-role returned. 

 

Anyone know how I can fix this issue?

 Hello Christoffer

 

Is this AD source not in use by other services? Establishing the AD connection takes some time when you first instance it. Default server timeout on the AD source is 10 seconds. Might be that the authentication takes longer than 10 seconds first time, and when you try again the connection is established and cached so therefore it suceeds. Try adjusting the server timeout on the AD source - see if that makes any difference.

Hi John and thank you for your reply.

 

Increasing the server timeout value from 10 to 15 seconds seem to have done the trick! The authentication happens instantaneously so there's no 12 second bind going on but changing it did solve the problem somehow. 

 

Thank you!

Hi again! I seem to have been to quick to announce this victory. Although the problem seems to be less frequent, it's still there. Any other suggestions of what could be causing this?

Anyone have any ideas? The issue is getting highly irritating. See the description of the problem 4 posts up. Thanx,

Unfortunately It could be a few things to look at. The most common I have seen is the AD being underpowered and its taking too long for the auth request to be processed when the cache setting times out. 

 

I would suggest that you open a TAC case so engineering can look at the CPPM logs to find out where the time out is happening. 

After fighting the LDAP battle in Airwave for too long I went with this solution. Perfect tutorial. It's so nice when things work! :D