Management tools are becoming more and more important for installing and maintaining any type of network. Although you may get personal satisfaction from configuring SSIDs, RF parameters, and debugging logs through convoluted AP and WLC command lines, a proper management system can perform all those tasks faster, and at a large scale. On top of standard configuration tasks, management tools also have the advantage of centralizing data from different sources and providing common features to troubleshoot, alert, and log information from heterogeneous systems.
Listing every feature of the Cisco Prime Infrastructure management system would probably require a book of its own. Nevertheless, this chapter should provide you with all the information about its major capabilities, as well as its complementary solution for specific WLAN services, like location and analytics, which is Cisco Connected Mobile Experiences (CMX).
Managing the Management
Accessing the graphical user interface (GUI) is the first task you need to complete to start using Cisco Prime Infrastructure, and differentiated access for administrator groups and privilege levels assignment are among the first requirements of a management tool. A more common definition for this type of feature also goes under the name of multitenancy. As you will see in the next paragraphs, Cisco Prime Infrastructure can provide some kind of user control capabilities through authentication and authorization services, as well as separated access to network device groups and sites through the notion of virtual domains, although not quite full multitenancy options.
Authentication and authorization define the menus and tasks that an administrator can access, and a virtual domain defines the group of network devices on which the administrator can run those tasks.
You may have already guessed that the most basic form of administrative authentication and authorization is through local accounts. A local account is simply a sequence of username and a password, stored in Prime Infrastructure’s local database, which you can map to a group. A group, or role, defines the privileges of an administrator account, hence determining menus that an administrator with that specific role can access. In Prime Infrastructure you can find the full list of predefined groups under Administration > Users > Users, Roles & AAA > User Groups, which is shown in Figure 6-1.
)
Figure 6-1 User Roles
On top of predefined groups with their preconfigured tasks privileges, you can also customize up to four user-defined groups.
Cisco Prime Infrastructure supports authentication of administrator accounts through external RADIUS or TACACS+ servers. The goal of such servers is not just to validate logins and passwords against external databases but also to assign groups and privilege levels for accessing specific tasks. An authentication server achieves this by including additional attributes in the RADIUS and TACACS+ response. It is those attributes that contain the values that tell Prime Infrastructure to what group the authenticated user belongs, as well as the tasks that the user has access to for TACACS+.
All this may sound similar to what you can implement with authorization commands and TACACS+ on switches, for example. However, menus and features that you access through the GUI in Prime Infrastructure do not have their equivalents through the command line. For that reason, we cannot literally refer to “command” authorization on Prime Infrastructure, but rather to menus and tasks authorization.
When authenticating administrators via RADIUS, Prime Infrastructure uses the value [1] Login in the RADIUS attribute [6] Service-Type. This attribute allows you to identify RADIUS requests from Prime Infrastructure and to configure your authentication policies on the RADIUS server accordingly.
The attribute used to assign a group in the RADIUS response is the Cisco Attribute Value Pair (AVP), using the following format: cisco-av-pair=NCS:role0=[GROUP_NAME].
For TACACS+, the authentication server should return a shell profile containing all the attributes for authorizing the corresponding group and privileges.
To understand which value(s) to use in RADIUS and TACACS+ attributes, you can browse to Administration > Users > Users, Roles & AAA > User Groups and click the Task List option under the column View Task for the corresponding user group, similarly to what is shown in Figure 6-2.
)
Figure 6-2 Attribute Values for User Groups
For RADIUS, the attribute NCS:role0 is enough in the final response for Prime Infrastructure to assign the corresponding group, whereas for TACACS+ you need to copy and paste all the attributes in the authentication server’s shell profile.
You can find all the steps to configure user authentication through an external server in the official administration guide:
If groups and roles provide privilege levels for performing specific administrative tasks, virtual domains allow restricting those monitoring and configuration tasks to groups of specific network devices.
When you create a new virtual domain, Prime Infrastructure presents you with the option to configure which site maps, groups of network devices, access points, and so on belong to it. Independently of how you choose to call a group of network devices, all those options in the end refer to the set of switches, access points, and the like that a user assigned to that particular virtual domain will be able to operate.
You can configure virtual domains under the menu Administration > Users > Virtual Domains.
One of the first conceptual associations we tend to do is that virtual domains can provide multitenancy capabilities end customers often ask for, which in some ways is true. On the other side, specifically for wireless deployments, you may have already encountered a common question: How can we differentiate administrative access so that, for example, some users can configure SSIDs and RF parameters only for a particular subset of access points? The short answer is that we cannot. Virtual domains can provide access to a restricted subset of access points, this is true. However, as long as an access point managed by a WLC is in the virtual domain, users from that virtual domain (with the right configuration privileges) will also be able to create any type of SSIDs on the corresponding WLC, which could then be pushed to any other access points attached to that very same WLC.
A good use of virtual domains for wireless deployments is usually to provide differentiated visibility of access points by building or floors, for example. Users of a specific office can then access a dedicated view of their office’s access points only (please note again the term view here).
As for administrative authentication and authorization, you can assign a virtual domain to users either by specifying the virtual domain they belong to when creating a local account or by dynamically assigning that virtual domain using RADIUS or TACACS+ attributes.
When creating a local account, it is mandatory to specify its corresponding virtual domain, and when authenticating a user through an external RADIUS or TACACS+ server, it is also mandatory to send back a RADIUS or a TACACS+ attribute specifying a valid virtual domain. Failing to do so will cause an authorization failure on Prime Infrastructure.
You can find the corresponding virtual domain attributes for RADIUS and TACACS+ under the menu Administration > Users > Virtual Domains by clicking on the option Export Custom Attributes on the top right of the page. Figure 6-3 shows an example of a virtual domain’s custom attributes.
)
Figure 6-3 RADIUS and TACACS+ Custom Attributes for Virtual Domains
Putting authentication, group assignment, and virtual domains together, if you had to authorize users belonging to the group System Monitoring and push the virtual domain Office1, the following would be an example of the two RADIUS attributes you would need to send back to Prime Infrastructure in the final Access-Accept response:
cisco-av-pair = NCS:role0=System Monitoring cisco-av-pair = NCS:virtual-domain1=Office1