With IT networks forming the central nervous system of any organization, managing an estate of wireless access points, switches, and security appliances brings with it plenty of responsibility. Recognizing this, the Meraki team has developed multiple access levels for its dashboard, ensuring just the right amount of visibility and control for every job function. In today’s blog post we’ll look at these access levels and how they can be mapped to different job functions.
Maintaining a complex, disperse network efficiently demands the very best management tools. The intuitive Meraki dashboard provides valuable information to IT managers and service providers who carry the responsibility of maintaining healthy IT ecosystems, tracking performance and use over time. The interface provides a wealth of data in an easily digestible form. Here’s an ideal example – a snippet from a typical monthly summary report:
It’s inevitable that as networks grow, the associated monitoring and control becomes too much for one individual. In larger organizations, particularly those distributed across multiple locations, the functions of configuring, monitoring and supporting data networks often fall to different individuals or teams – sometimes replicated by function at each location. Other Meraki customers choose to have their networks managed by a service provider with staff dedicated to managing select customer networks in some form of Network Operations Center (NOC). Providing granular access for so many organizational scenarios demands well thought-out tools.
Before looking at the specifics, this is a good opportunity to review the Meraki definitions of an Organization and a Network, the basic structural entities used in the dashboard. When a new customer logs in for the first time, the first step will be to create an Organization. This is the top level entity or container, below which networks are created. A ‘Network’ is a container for either a single security appliance or a logical grouping of wireless APs or switches sharing the same configuration settings. Here’s a visual representation with a couple of example structures:
In many cases only a single organization will be required, but for large enterprises comprising multiple divisions it may be desirable to break these into separate organizations with their own admin rights. Managed Service Providers (MSPs) can also use this approach to separate out the various customer networks they take care of, or use separate networks under a single organization, as depicted above.
Once the structure is in place it’s time to establish access privileges.
Organization Admin
At the top of the tree sits one or more organization admins, who are given comprehensive access to all dashboard sections, views and configuration tools, together with a complete list of the organization’s networks (where a regular network admin would see only those networks to which they’ve been given access). Here’s an example which shows networks the organization admin view for the Meraki Corp organization:
A complete list of categories is viewable on the left – including ‘Organization’, which only these top level administrators will see. The organization menu includes the ‘Administrators’ item where other admins can be created and promoted, as can be seen in this graphic:
There are several useful tools included only in the organization menu, including Location Analytics (which can span multiple networks), Security Reporting of intrusion events and the all-important ability to create new networks. The organization admin role also has the privileges to be able to set up other organization admins, with either full (read-write) or read-only access, and network admins, whose view is restricted to only those networks to which they’ve been awarded access.
Network Admin
Using network admins provides more flexibility, with a couple of additional role types. Network level admins are selected by organization admins, either manually from a list, or automatically based on tags (an approach we detailed in a previous blog post) and are given one of four levels of access on a per-network basis, as shown in this snippet:
Full
A user with full privileges enjoys comprehensive monitoring and configuration capabilities for the networks to which they’ve been provided access, making this the best fit for a delegated site admin.
Read-only
Read-only users get the same comprehensive view, which also includes the Overview page showing all networks to which they have access, albeit without the ability to save changes. This option is ideal for junior network admins who do not yet have full responsibility for the networks they work on. It’s also a sensible choice for dashboard demonstrations, which a service provider may like to use to promote their capabilities. Finally, this view is perfect in a NOC environment.
Monitor-only
This restricted view provides a limited read-only Monitor menu, perfect for a manager who merely needs to keep an eye on real-time and trending network use. Note the menu options on the left here compared to what we saw above:
By the way, this screen capture snippet also shows a customized logo in place of the standard Cisco Meraki one. The dashboard provides MSPs the ability to upload a company logo which would appear when the managed customer logs on to their dashboard account, whatever the level of access provided by the MSP.
Guest Ambassador
A minimal interface designed for front desk staff to set up guest user access to the network which we covered in another blog post.
Finally, back at the end of last year we introduced port management roles on our switch line, which enable organization admins to delegate control of individual switch port settings using the same tagging approach we touched on earlier.
Providing granular levels of control greatly assists managers of large and growing networks, both within organizations and – in the case of service providers – between multiple managed organizations. The dashboard makes it easy to establish appropriate levels of access so that junior staff can’t accidentally get out of their depth, or revoke access if, for example, it needs to be suddenly terminated for a departing employee.
We’ve focused our efforts on making the complex task of role based access as intuitive as possible, so that when an admin is working in a specific section of the dashboard, on logical groupings of devices and locations they’re familiar with, it all just makes sense. Do these options cover the way you break down roles and responsibilities in your own organization? Remember, we always love to hear suggestions for enhancements via our Make a Wish box.