Creating an administrator configuration – Brocade Mobility RFS Controller System Reference Guide (Supporting software release 5.5.0.0 and later) User Manual

Page 684

Advertising
background image

672

Brocade Mobility RFS Controller System Reference Guide

53-1003099-01

12

Once the new name is defined, the screen’s four tabs become enabled, with the contents of
the Administrators tab displayed by default. Refer to the following to define the configuration of
the new Management Access policy:

Creating an Administrator Configuration

- Use the Administrators tab to create specific

users, assign them permissions to specific protocols and set specific administrative roles
for the network.

Setting the Access Control Configuration

- Use the Access Control tab to enable/disable

specific protocols and interfaces. Again, this kind of access control is not meant to
function as an ACL, but rather as a means to enable/disable specific protocols (HTTP,
HTTPS, Telnet etc.) for each Management Access policy.

Setting the Authentication Configuration

- Refer to the Authentication tab to set the

authentication scheme used to validate user credentials with this policy.

Setting the SNMP Configuration

- Refer to the SNMP tab to enable SNMPv2, SNMPv3 or

both and define specific community strings for this policy.

SNMP Trap Configuration

- Use the SNMP Traps tab to enable trap generation for the policy

and define trap receiver configurations.

For deployment considerations and recommendations impacting a controller or service
platform’s Management Access policy configuration, refer to Management Access Deployment
Considerations on page 12-687
.

Creating an Administrator Configuration

Adding or Editing a Management Access Policy

Management services (Telnet, SSHv2, HTTP, HTTPs and FTP) require administrators enter a valid
username and password which is authenticated locally or centrally on a RADIUS server. SNMPv3
also requires a valid username and password which is authenticated by the SNMPv3 module. For
CLI and Web UI users, the controller or service platform also requires user role information to know
what permissions to assign.

If local authentication is used, associated role information is defined on the controller or
service platform when the user account is created.

If RADIUS is used, role information is supplied RADIUS using vendor specific return attributes.
If no role information is supplied by RADIUS, the controller or service platform applies default
read-only permissions.

Administrators can limit users to specific management interfaces. During authentication, the
controller or service platform looks at the user’s access assignment to determine if the user has
permissions to access an interface:

If local authentication is used, role information is defined on the controller or service platform
when the user account is created.

If RADIUS is used, role information is supplied by RADIUS using vendor specific return
attributes.

The controller or service platform also supports multiple RADIUS server definitions as well as
fallback to provide authentication in the event of failure. If the primary RADIUS server is
unavailable, the controller or service platform authenticates with the next RADIUS sever, as defined
in the AAA policy. If a RADIUS server is not reachable, the controller or service platform can fall
back to the local database for authentication. If both RADIUS and local authentication services are
unavailable, read-only access can be optionally provided.

Advertising