In this chapter, you learn the following:
The organizational hierarchy and the built-in access levels available in Meraki Dashboard
The various roles available in Meraki Dashboard
How to configure role-based access control (RBAC) within Meraki Dashboard to adhere to the principle of least privilege
The principle of least privilege and role-based access control (RBAC) are key themes across industry best practices. RBAC is an essential feature that enables you to assign appropriate access rights to users based on their roles and responsibilities. Practical use cases for differentiated administrative roles include the following:
Providing help-desk staff with limited access to Dashboard to be able to collect vital troubleshooting information, thereby enabling incidents to be resolved faster.
Providing CCTV operators with the access they need to view and edit footage, while limiting access to network settings.
Assigning limited read-write access for junior administrators. Having fewer admins with full access at the organizational level reduces the likelihood of mistakes that can have a wide-ranging impact.
Meraki Dashboard incorporates RBAC, providing a built-in way to precisely control administrative access to specific parts of the Meraki organization. In addition to the built-in roles, you can create distinct and granular roles if required.
Meraki Dashboard’s Administration Hierarchy
Meraki Dashboard administrator privileges are controlled at the organization and network levels:
Organization administrators have visibility of the organization and all its networks. Organizational admins do not necessarily have the highest permissions. Access can be restricted; for example, it is possible to have an organizational administrator with only read-only access.
Network administrators have visibility of individual networks. Network administrators can have complete or limited control over these networks but do not have access to organization-level information (licensing, device inventory, and so on) unless granted such access at the organization level.
The privileges grant control over what a user can see and do in Meraki Dashboard. Permissions granted at the organization level cannot be reduced at the network level. If required, a user can have access to multiple networks and multiple organizations. We cover how to assign access to multiple networks later in the section titled “Assigning Permissions Using Network Tags.”
For more information on the Meraki Dashboard’s hierarchical structure, see .
Administrator Access Levels for Dashboard Organizations and Networks
Three levels of administrative access are available at the organization level:
None: Users will have no access to the organization, meaning they cannot perform any actions or view any configurations at the organization level. They may, however, still have privileges assigned at the network level.
Read-Only: Users with read-only access can view the Dashboard configurations for the organization but cannot make any changes. This includes the ability to view video footage if the organization has cameras. Be aware that administrators may still have privileges assigned at the network level.
Full: Users with full access have access to all parts of Dashboard (including cameras), can make configuration changes, and can even delete the organization. This access level should be limited to suitably qualified and trusted personnel.
Four additional levels of access are available when configuring privileges at the network level:
Full: This level grants full access to the target network, including the ability to view all of the Dashboard and change any configuration settings (see Figure 4-1).
)
Figure 4-1 An Example of an Administrator Configured as a Network-Only Admin
Read-Only: With this level, users can view all configurations in the target network but are restricted from making any modifications.
Monitor-Only: Administrators with this access level can view a dedicated monitor page in the Dashboard but cannot make any changes. Users with this access level can monitor and analyze network performance metrics, troubleshoot issues, and gain insights into the network’s health and performance.
Guest Ambassador: This level of access is intended for managing user access to Wi-Fi or client VPN access. The most common use case for this role is a hotel receptionist or lobby ambassador needing to provide temporary (time-bound) Wi-Fi access for guests and visitors. Staff with this access level can manage guest users, granting or revoking access as needed. When logging in, the Guest Ambassador user is presented with a purpose-built user management portal. It allows them to efficiently manage guest user accounts without having access to other parts of the Dashboard.
Assigning Permissions Using Network Tags
If you’re not using configuration templates, then here’s a handy little tip that will save you a ton of time when it comes to administering admin users. Because you will have a network for every location, grouping them together in a logical way will make assigning administrative rights far easier. In Dashboard, group networks by assigning them a common tag. Then, when granting access to administrators, select only the tag name rather than all the individual network names. Tagged networks appear with the prefix Tag: in the Target list on the Organization Administrators page.
Follow these steps to tag your networks and assign administrator access using them:
Step 1. Log in to Meraki Dashboard ().
Step 2. Navigate to Organization > Overview (under Monitor), as demonstrated in Figure 4-2.
)
Figure 4-2 Navigating to the Organization Overview Page
Step 3. Select the check box or boxes next to the network(s) you want to tag, as demonstrated in Figure 4-3.
)
Figure 4-3 The Organization Overview Page
Step 4. Click Tag and then enter the tag name you would like to create. In the case illustrated in Figure 4-4, we used the tag Stores. Click Add. The Add button will change to Updating, then quickly turn green, then change to Updated, before changing back to Add.
)
Figure 4-4 Creating New Network Tags
You can now see the tag next to the network name selected previously, confirming that the changes have been applied, as demonstrated in Figure 4-5.
)
Figure 4-5 Confirming Networks Are Now Tagged
Step 5. When updating organization administrator privileges (Organization > Administrators), you can now see the Stores group created with the prefix Tag: in the Target list, as demonstrated in Figure 4-6. From here, just assign access the same way you would to a regular network, by choosing the access level from the Access drop-down menu and clicking Update Admin.
)
Figure 4-6 Assigning Administrator Access to a Group Using Tags
Port-Level Permissions
In Meraki Dashboard it is possible to provision read-only administrator accounts with read-write access to selected switchports. In traditional networks, doing this wasn’t easy, so we avoided it. However, now that the capability exists, some immediate use cases come to mind:
Labs, teaching environments, dormitories, and the like. If you have any such environments in your network, you can now provide limited admin access to staff or students without having to provide them with admin access to the rest of the network. With the access locked down, if required, you could continue to serve regular users off the remaining ports.
Multitenanted environments like airports or shopping centers. In a multitenanted environment where you’re responsible for providing network connectivity to businesses inside your premises, you could provide tenants with admin access to the ports serving just their premises. Because the control is down to the port level, potentially you could now share switches between tenants where you previously had provided a switch per tenant, reducing costs.
Follow these steps to tag your ports and configure roles with port-level permissions:
Step 1. Log in to Meraki Dashboard ().
Step 2. Navigate to Switching > Switch Ports (under Monitor), as demonstrated in Figure 4-7.
)
Figure 4-7 Navigating to the Switch Ports Page
Step 3. Select the ports that you want to tag using the check box next to their name, as demonstrated in Figure 4-8.
)
Figure 4-8 Selecting Ports to Tag
Step 4. Click the Tags drop-down menu and enter the name for a new tag or select an existing tag. In the example in Figure 4-9, we added the tag Lab. Click Add to confirm the changes.
)
Figure 4-9 Creating Port Tags
If you have the Tags column enabled (click the spanner symbol on the far-right column name to customize the columns displayed), you see the new tag associated with these ports, as demonstrated in Figure 4-10.
)
Figure 4-10 Showing Port Tags on the Switch Port Page
Step 5. Navigate to Network-wide > Administration to open the Network administration page, as demonstrated in Figure 4-11.
)
Figure 4-11 Navigating to the Network Administration Page
Step 6. Scroll down to the Port Management Privileges section and click Add a Port Management Privilege.
The privilege name is displayed in the Access drop-down menu when this role is assigned to administrators, as demonstrated in Figure 4-12. Enter a privilege name that makes sense for your use case; then select the port tags that apply.
)
Figure 4-12 Creating a Port Management Role
Step 7. Decide whether this role should be able to do packet captures on these ports (the default is Allowed), as demonstrated in Figure 4-13, and then click Save in the bottom-right corner. A message at the top of the screen confirms that the changes have been saved.
)
Figure 4-13 Selecting Packet Capture Permissions
Step 8. Navigate to Organization > Administrators to open the Organization administrators page, as demonstrated in Figure 4-14.
)
Figure 4-14 Navigating to the Organization Administrators Page
Step 9. Click the name or email address of an existing administrator that you want to modify (or create a new one), as demonstrated in Figure 4-15.
)
Figure 4-15 The Organization Administrators Page (Port-Based Permissions)
Step 10. Set the Organization access to Read-only or None and then select the target network. At the time of writing, the target network cannot be a tagged group of networks—that is, one starting with Tag:. In Figure 4-16, you can now select the Lab admins role created in the Access drop-down menu.
)
Figure 4-16 Assigning Port-Level Permissions on the Organization Administrators Page
Step 11. Click Update Admin to save the changes.
Perform the following steps to verify that these changes are now in effect:
Step 1. Log in to Meraki Dashboard as the user that was just configured. In the example in Figure 4-17, this is the user John Smith. You can see on the network-wide administrators page (Network-wide > Administrators) that this user is configured with the Lab admins privileges. Note how the X is missing under the Actions column, confirming the user has read-only access.
)
Figure 4-17 A Network Admin with Lab Admin Privileges
Step 2. Navigate to the switch ports page (Switching > Switch Ports). Here, the Tags column is enabled to make it clear which ports you have access to. Select those port(s) with the tag to which this user has read-write permissions; then click Edit. In this example, the lab admin has selected port 1/9, as shown in Figure 4-18.
)
Figure 4-18 A Lab Admin Selecting Switch Ports to Modify
Step 3. On the update port page, as shown in Figure 4-19, change the port status to Enabled and click Update.
)
Figure 4-19 A Lab Admin Enabling a Disabled Port
Thanks to port-level permissions, you have successfully enabled this port, despite only having read-only access to the rest of the network (see Figure 4-20). If you try to make changes to another port that is not tagged correctly, you will receive an error, as demonstrated in Figure 4-21.
)
Figure 4-20 Verifying That the Lab Admin Was Able to Enable a Port
)
Figure 4-21 Verifying That the Lab Admin Is Not Able to Edit Other Ports
Role-Based Access Control for Camera-Only Administrators
The Meraki platform features multiple product lines including smart cameras (the MV series) and sensors (the MT series), creating a need for additional admin roles beyond the traditional network admins.
Camera-only roles are intentionally limited to camera-related functions. When correctly configured, local camera-only administrators can log in to both Meraki Dashboard and Meraki Vision. The Meraki Vision portal is a purpose-built CCTV portal designed for staff who need to monitor CCTV footage. Meraki Vision portal has none of the other features of Meraki Dashboard. In Meraki Dashboard, camera-only administrator access is limited to read-only access to the cameras page (other menu items are hidden), as demonstrated in Figure 4-22.
)
Figure 4-22 A Camera-Only Admin’s Limited View of Meraki Dashboard
In either portal, camera-only admins cannot make changes to camera settings such as focus, zoom, or aperture, nor can they create video walls or access the network tab of cameras. A camera-only admin’s access is therefore limited to performing only what is allowed by the following camera roles (see Figure 4-23):
No Access: These admins do not have access to any cameras.
View Live Footage: Admins with this level of access can watch live footage on a single camera or video wall.
View Any Footage: Admins with this level of access can watch live and historical footage on a single camera or video wall.
View and Export Any Footage: Admins with this level of access can watch all footage and manage video exports.
)
Figure 4-23 Camera Roles for Local Administrators at the Network Level
Local camera-only administrators can be configured at the organization or network level. Organization-wide camera admins are configured on the Organization administrators page (Organization > Administration). Privileges at the organization level must be set to None; otherwise, these privileges will override the camera privileges, giving users more access than intended.
Camera-only users should be configured in a purposeful way to limit their scope to what is required. You can configure the local camera-only users as outlined in Table 4-1 and Figure 4-24 to suit their job requirements.
Table 4-1 How to Configure Camera-Only Users to Suit Their Access Requirements
Access Required |
How to Configure |
|---|---|
The same level of access to all cameras in the organization |
Configure the user’s administrator access as follows:
|
Differentiated levels of access to cameras in the organization |
Configure the user’s administrator access as follows:
|
Access to only certain cameras |
The best way to restrict access within the same organization is to group the cameras into different networks. For example, create a camera-only network for common area devices and another for cameras in restricted or sensitive areas. Then configure the administrator’s access as follows:
|
No access to any cameras while retaining access to Dashboard |
The best way to configure this access would be to have all the cameras in their own organization, with another organization for all other devices, such as switches and access points. Only camera administrators would be given access to the camera organization. In this case, you would have two completely standalone instances of Meraki Dashboard, with neither team having any visibility of the other environment. |
)
Figure 4-24 An Example of an Administrator Configured as a Camera-Only Admin
We cover more details on this topic in Chapter 12, “Physical Security.”
Role-Based Access Control for Sensor-Only Administrators
Sensor-only administrators are admin accounts that have access to sensor devices and nothing else in Dashboard. Three additional roles apply to sensor-only admins, as illustrated in Figure 4-25:
No Access: These users do not have access to any sensors.
Read-Only Sensor Access: Admins with this level of access can read sensor readings and configurations but not make any changes.
Full Sensor Access: Admins with this level of access can both monitor and edit sensor readings and configurations.
)
Figure 4-25 Sensor Roles for Local Administrators at the Network Level
At the time of writing, access control for sensors is still undergoing heavy development. It is important to note the following:
Sensors connect via a gateway; both the gateway and the sensor need to be in the same network. This means you can’t have a true sensor-only network.
There is no equivalent to All Cameras in This Organization for sensors. This would be an elegant solution, so do not be surprised to see it added in the future.
It is not possible to select a subset of sensors on the network-wide administration page.
It is important to remember that sensors are used to collect data such as temperature, air quality, and moisture readings, none of which is personally identifiable information. Nevertheless, to create a local sensor-only user (this user will have the same level of access for all sensors in the organization), configure their administrator profile as follows (Organization > Administration):
Organization Access to None
Target to the network containing the sensors and their gateways
Access to the highest access the user requires, such as full access
When single sign-on is configured, permissions for camera and sensor admins can also be assigned using Security Assertion Markup Language (SAML). The organization-wide roles used by single sign-on can be defined in Dashboard by navigating to Organization > Camera and Sensor Roles. The permissions mapping is done at time of login, and the admin user is mapped to one of these locally configured roles. It is recommended to use single sign-on for medium to large organizations or where administrators require differentiated access. Configuring single sign-on using SAML is explained in detail in Chapter 5, “Securing Administrator Access to Meraki Dashboard.”
For more information on role-based access for cameras and sensors using SAML, see .
Role-Based Access Control Using Systems Manager Limited Access Roles
There are additional roles known as limited access roles when using Meraki Systems Manager for mobile device management (MDM). Limited access roles allow you to create roles that have defined privileges, for a defined scope of Systems Manager devices. These roles apply only to System Manager commands such as rebooting devices, requesting device check-in, and pushing out notifications. These commands are targeted at managed end-user devices such as phones, tablets, and computers. Here are some examples of use cases where this functionality could come in handy:
A trainer wants to reboot all classroom devices at the end of a lesson.
A store manager wants all devices in the store to check in at the start of the day (to verify they are functioning and that none have gone missing).
You may have administrators responsible for end-user technology whom you want to give limited access to Meraki Dashboard. You could create a role that provides full access to Systems Manager, while limiting their access to the rest of Dashboard.
Limited access roles remain hidden in Meraki Dashboard until all three of these prerequisites are met:
At least one Systems Manager Agent license has been added.
A Systems Manager Network has been created.
At least one device has been enrolled.
Once the prerequisites are in place, follow these steps to tag your Systems Manager devices and configure limited access roles:
Step 1. Log in to Meraki Dashboard ().
Step 2. If you want to use the built-in tags such as IOS devices or Android devices, you can go straight to Step 5. To use custom tags, navigate to Systems Manager > Devices, as demonstrated in Figure 4-26.
)
Figure 4-26 Navigating to the Systems Manager Devices Page
Step 3. Select the devices you want to tag, as shown in Figure 4-27, and then click the Tag drop-down menu.
)
Figure 4-27 Selecting Systems Manager Devices to Tag
Step 4. Input the tag name in the Add: text input box and click Add. In the example in Figure 4-28, we created a tag called Store_device to identify all the devices that are used in retail store locations.
)
Figure 4-28 Creating a System Manager Tag and Adding It to Our Device(s)
Step 5. Now create the limited access role by first navigating to Systems Manager > General (under Configure) for a standalone Systems Manager (SM) network or Network-wide > Administration (under Configure) in a combined network. Scroll down to Limited Access Roles (see Figure 4-29).
)
Figure 4-29 Limited Access Roles on the Network-Wide Administration Page
Step 6. Click Add a New Limited Access Role.
Enter a name for this role in the text input box under Role Name. Then set the appropriate scope. In the example shown in Figure 4-30, we created a role for a store manager with a scope of With ANY of the Following Tags.
)
Figure 4-30 Entering Name and Scope to Create a Limited Access Role
Step 7. Select the tags that identify the devices that this admin should have access to. In the example in Figure 4-31, we selected the Store_device tag. Click Save in the bottom-right corner.
)
Figure 4-31 Selecting the Tag(s) to Create a Limited Access Role
The Limited Access Roles section should now look like the screen in Figure 4-32. A banner at the top of the page confirms that the changes have been saved (not shown here).
)
Figure 4-32 A Completed Limited Access Role
Step 8. Navigate to the Organization administrators page (Organization > Administrators), as demonstrated in Figure 4-33.
)
Figure 4-33 Navigating to the Organization Administrators Page
Step 9. From page shown in Figure 4-34, click the name or email address of an existing administrator that you want to modify (or create a new one).
)
Figure 4-34 The Organization Administrators Page
Step 10. In the dialog box shown in Figure 4-35, set the Organization access to None. Set the Target to the network containing the Systems Manager devices, and under Access, choose the name of the role you have just created. Here, we chose the Store Manager role. Finish by clicking Update Admin.
)
Figure 4-35 An Example of an Administrator Configured in a Limited Access Role
Step 11. You now return to the Organization administrators page. Click Save Changes for the changes to be applied.
Perform the following steps to verify that the changes are in effect:
Step 1. Log in as the user with the limited access role. Navigate to Systems Manager > Devices. Note the limited view of Dashboard that this user has, as demonstrated in Figure 4-36.
)
Figure 4-36 Navigating to the Systems Manager Devices Page (Limited Access Role)
Step 2. Test that the privileges for this new limited access role are working as intended by requesting a device check-in. Before starting, to make it possible to determine the check-in time, enable the columns for Tags and Last Check-in (MDM) by clicking the settings (or sprocket) icon on the far right. Once this is done, the Device List page should look like Figure 4-37 with the additional columns showing. In this example, you can see that the last check-in time for this device was 7:37 a.m.
)
Figure 4-37 Confirming the Most Recent Check-In Date/Time
Step 3. Check the box on the row for the device(s) you want to check in and select Request Check-in from the Command drop-down menu, as demonstrated in Figure 4-38.
)
Figure 4-38 Requesting a Device Check-In with Systems Manager
Step 4. Click Confirm on the pop-up window, as shown in Figure 4-39. You see the Devices List page again with confirmation that the check-in request has been sent, as demonstrated in Figure 4-40.
)
Figure 4-39 Confirming the Check-In Request
)
Figure 4-40 Systems Manager Devices Page After Check-In Request Sent
You can now see that this device has successfully completed check-in, with a new check-in time of 7:54 a.m., as demonstrated in Figure 4-41.
)
Figure 4-41 Successful Check-In with Updated Time
If you would like to know more about limited access roles, please check out . For more information on Meraki Systems Manager, refer to Chapter 11, “Securing End-User Devices.”
Summary
Role-based access control (RBAC) is a key requirement of modern security standards. In this chapter, we detailed the steps to configure RBAC to adhere to the principle of least privilege. This included learning how to configure user access at the organization and network levels within the Dashboard hierarchy. We also explained how special roles can be created for specific use cases. This included creating roles with control over specific ports, camera-only and sensor-only admins, as well as the creation of limited access roles for Systems Manager admins.
Further Reading
Cisco Meraki. (2023, June 8). Limited Access Roles.
Cisco Meraki. (2023, August 22). Meraki Dashboard Organizational Structure.
Cisco Meraki. (2023, November 1). Managing Dashboard Administrators and Permissions.