Wired Intelligent Edge

Hello All,

I've never had to configure Management Authentication for management access to the MAS Switches via RADIUS. So I wanted to confirm if I am on the right track as regards my thoughts towards configuring this.

So, based on the fact that they will be using RADIUS, will I have to build a Role for example for IT. Then an ACL giving them access to the Management VLAN (to manage the MAS Switches). Then configure the RADIUS Servers and associate them to a Server Group which will be applied to the "aaa authentication mgmt" Profile. Is this correct so far?

Secondly, can I use Server Derivation Policy associated to the Server Group configuration and can my Attribute from AD be "Class" which when successfully authenticated, assigns them to the Role I created.

Will this work for Management Authentication?

I know for User Authentication, this would be the norm but wanted to be sure about Management Authentication.

Look forward to your responses.

Any ideas anyone?

Hello,

Unlike user authentication where you create user-roles, management authentication uses 4 pre-defined roles:

The roles are defined as follows:

• root: permits access to all management functions on the Mobility Access Switch
• read-only: permits access to CLI show commands or WebUI monitoring pages only
• guest-provisioning: permits access to adding and configuring guest users in the Mobility Access Switch’s internal database only
• network-operations: permits access to Monitoring pages in the WebUI and the CLI commands thatare useful for monitoring the Mobility Access Switch.

These roles can be passed back using the Aruba VSA (Aruba-Admin-Role) or a standard RADIUS attribute and a server derivation rule will need to be used to map to the aforementioned roles. The latter is probably what you want to use given your application and yes it would be part of the server-group that is associated to the "aaa authentication mgmt" profile.

As a side note, this is the same for Mobility Controlles too.

I'm not quite sure what you mean by "Then an ACL giving them access to the Management VLAN (to manage the MAS Switches)." It is assumed that if they are in the management authentication process, they already have connectivity to the switch through at least one of these connection methods, ssh, telnet, webUI, or console.

Best regards,

Madani

---

@madjali wrote:

Hello,

Unlike user authentication where you create user-roles, management authentication uses 4 pre-defined roles:

 

The roles are defined as follows:

• root: permits access to all management functions on the Mobility Access Switch
• read-only: permits access to CLI show commands or WebUI monitoring pages only
• guest-provisioning: permits access to adding and configuring guest users in the Mobility Access Switch’s internal database only
• network-operations: permits access to Monitoring pages in the WebUI and the CLI commands thatare useful for monitoring the Mobility Access Switch.

These roles can be passed back using the Aruba VSA (Aruba-Admin-Role) or a standard RADIUS attribute and a server derivation rule will need to be used to map to the aforementioned roles. The latter is probably what you want to use given your application and yes it would be part of the server-group that is associated to the "aaa authentication mgmt" profile.

 

As a side note, this is the same for Mobility Controlles too.

 

I'm not quite sure what you mean by "Then an ACL giving them access to the Management VLAN (to manage the MAS Switches)." It is assumed that if they are in the management authentication process, they already have connectivity to the switch through at least one of these connection methods, ssh, telnet, webUI, or console.

 

Best regards,

 

Madani

---

Thx Madani.

So I guess I can use the "Class" Attribute (for example in a Group called "IT" in AD) and then have my Server Derivation policy map this "Class" Attribute to the "root" role. Correct?

Yup, that should work just fine.

Madani

Awesome!!!!