Cloud Managed Networks

Hello all!

So for my current 802.1x setup we use an on prem Clearpass server to authenticate by checking with AD and then passing back an AOS Role to Aruba Central.  

In Classic Central I would just setup a Role by going to the Security tab and creating a Role that's named the same as what's passed back from Clearpass.  In the Role we set the VLAN and ACL for the client like the picture below.

In New Central I see Roles and then under Security Policies I see Role-based Policies.   It looks like you link the Role-based Policies to Roles.

So my question is, when Clearpass passes back an AOS-Role to New Aruba Central, does it reference to the Roles or does it refer to the Role-based Policies to pass to clients?   I'm guessing it refers to the Roles and then if they're linked to the Role-based Policy the client gets the rules established in the Role-based Policy?

Anyone have experience with this yet?

yes you first create your roles for APs, access switches and gateways. Then you create your Role-based-policies and reference the role you had created.

Hello all!

So for my current 802.1x setup we use an on prem Clearpass server to authenticate by checking with AD and then passing back an AOS Role to Aruba Central.  

In Classic Central I would just setup a Role by going to the Security tab and creating a Role that's named the same as what's passed back from Clearpass.  In the Role we set the VLAN and ACL for the client like the picture below.

In New Central I see Roles and then under Security Policies I see Role-based Policies.   It looks like you link the Role-based Policies to Roles.

So my question is, when Clearpass passes back an AOS-Role to New Aruba Central, does it reference to the Roles or does it refer to the Role-based Policies to pass to clients?   I'm guessing it refers to the Roles and then if they're linked to the Role-based Policy the client gets the rules established in the Role-based Policy?

Anyone have experience with this yet?

Thank you, I experimented with it yesterday and got it to assign roles to wireless clients yesterday.  

I guess I find it a little confusing separating Roles and Role Policies into two separate things.  From what I found yesterday, you're linking each rule in a Role Policy to a Role.  I can't seem to wrap my head around the reasoning for this.  If I'm creating a Role Policy to be an ACL for a specific Role, then why don't I just link the Role to the whole policy instead of each rule of a policy?

yes you first create your roles for APs, access switches and gateways. Then you create your Role-based-policies and reference the role you had created.

Hello all!

So for my current 802.1x setup we use an on prem Clearpass server to authenticate by checking with AD and then passing back an AOS Role to Aruba Central.  

In Classic Central I would just setup a Role by going to the Security tab and creating a Role that's named the same as what's passed back from Clearpass.  In the Role we set the VLAN and ACL for the client like the picture below.

In New Central I see Roles and then under Security Policies I see Role-based Policies.   It looks like you link the Role-based Policies to Roles.

So my question is, when Clearpass passes back an AOS-Role to New Aruba Central, does it reference to the Roles or does it refer to the Role-based Policies to pass to clients?   I'm guessing it refers to the Roles and then if they're linked to the Role-based Policy the client gets the rules established in the Role-based Policy?

Anyone have experience with this yet?

As it may seem a bit confusing. My understanding of the concept is the role is a single source.  It can be used across different products with the same config. This reduces the need to create roles in groups on classic central for gateways, ap's, switches, etc. 

Think of the role based policies as your "session access-lists" on gateways. You would previously build them and then apply to a role. 

I am not sure if you had issues on airwave with IAP, or classic central with campus/microbranch. The problem with creating a role is you would repeat those same ACL's on many roles and many groups. It was a very tedious process. 

With the new design, you follow the tasks. 

• create role
• create policies / access-lsits
• apply your policies to roles (can apply 1 acl to many roles)

The one thing to keep in mind... When you create your role based policies (access lists). Keep that list as top down (order of operations). Same as you would create rules on a firewall. When you apply those acl's to roles; its important to have that original list be in order of operations.  If you enable an ACL higher in the list that permits rfc1918 on guest, although also permit it lower in the list. The actual acl that is delivered on the device could permit traffic first. This did take me some time to think out the process of what would be best to suit us for mixed environments. 

Its also important to check your roles and acl's on devices to ensure order of operations is correct. It threw me off at first and I didn't catch it until I was validating. 

• AP => show access-rule <role-name>
• GW => show rights <role-name>

I have provided an example of our production AP's which was generated in late November and applied to 15-18 roles. As this was targeted to be order of operations if there are overlapping rules in any 2 access-lists, you may apply the wrong one. Due to that I have created an allow-rfc1918 and apply to employee, printers, network, etc. There is also a deny-rfc1918 that is applied to guest type roles. Sometimes in our case we need to get to captive portal which is part of rfc-1918 on where its hosted and SNAT. In this case the captive portal also needs to be above in the order of operations. 

When you want to apply those acl's to roles, just go down the list in order of operations and link to role where access is needed. 

Thank you, I experimented with it yesterday and got it to assign roles to wireless clients yesterday.  

I guess I find it a little confusing separating Roles and Role Policies into two separate things.  From what I found yesterday, you're linking each rule in a Role Policy to a Role.  I can't seem to wrap my head around the reasoning for this.  If I'm creating a Role Policy to be an ACL for a specific Role, then why don't I just link the Role to the whole policy instead of each rule of a policy?

yes you first create your roles for APs, access switches and gateways. Then you create your Role-based-policies and reference the role you had created.

Hello all!

So for my current 802.1x setup we use an on prem Clearpass server to authenticate by checking with AD and then passing back an AOS Role to Aruba Central.  

In Classic Central I would just setup a Role by going to the Security tab and creating a Role that's named the same as what's passed back from Clearpass.  In the Role we set the VLAN and ACL for the client like the picture below.

In New Central I see Roles and then under Security Policies I see Role-based Policies.   It looks like you link the Role-based Policies to Roles.

So my question is, when Clearpass passes back an AOS-Role to New Aruba Central, does it reference to the Roles or does it refer to the Role-based Policies to pass to clients?   I'm guessing it refers to the Roles and then if they're linked to the Role-based Policy the client gets the rules established in the Role-based Policy?

Anyone have experience with this yet?

Thank you, I experimented with it yesterday and got it to assign roles to wireless clients yesterday.  

I guess I find it a little confusing separating Roles and Role Policies into two separate things.  From what I found yesterday, you're linking each rule in a Role Policy to a Role.  I can't seem to wrap my head around the reasoning for this.  If I'm creating a Role Policy to be an ACL for a specific Role, then why don't I just link the Role to the whole policy instead of each rule of a policy?

yes you first create your roles for APs, access switches and gateways. Then you create your Role-based-policies and reference the role you had created.

Hello all!

So for my current 802.1x setup we use an on prem Clearpass server to authenticate by checking with AD and then passing back an AOS Role to Aruba Central.  

In Classic Central I would just setup a Role by going to the Security tab and creating a Role that's named the same as what's passed back from Clearpass.  In the Role we set the VLAN and ACL for the client like the picture below.

In New Central I see Roles and then under Security Policies I see Role-based Policies.   It looks like you link the Role-based Policies to Roles.

So my question is, when Clearpass passes back an AOS-Role to New Aruba Central, does it reference to the Roles or does it refer to the Role-based Policies to pass to clients?   I'm guessing it refers to the Roles and then if they're linked to the Role-based Policy the client gets the rules established in the Role-based Policy?

Anyone have experience with this yet?