topic Re: This is unacceptable. in Cloud Networking Platform

This is unacceptable.

Raphael_L — Fri, 10 Oct 2025 12:00:29 GMT

Hi ,

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview ( this will be updated )

Read-only and monitor-only are able to perform disruptive actions ( without any logs 😍 ) such as Cable-tests and port cycles.

And now it's getting worse. These roles are now able to perform packet captures on your switches. Does that make any sense ? Absolutly not.

Who thought that this was a good idea ..?

I feel like Meraki isn't taking security seriously.

Re: This is unacceptable.

Rasmus Hoffmann Birkelund — Fri, 10 Oct 2025 13:44:07 GMT

Where do you see that read-only and monitor-only users can do pcaps?

Re: This is unacceptable.

Raphael_L — Fri, 10 Oct 2025 13:56:00 GMT

I haven't tested all the ways to do it but this is one of them :

Might also be accessible with the new UI from Intelligent packet capture

Re: This is unacceptable.

Rasmus Hoffmann Birkelund — Fri, 10 Oct 2025 15:11:57 GMT

I think I remember that it is a bug. There was another thread about it some weeks ago. The doc also explicably says that it’s not present for read- and monitor-only users.

Re: This is unacceptable.

Raphael_L — Fri, 10 Oct 2025 15:23:54 GMT

Confirmed by support this is not a bug. The doc as mentionned will be modified.

I have been advised by our development team the feature of packet capture is available in switch port page for Read-only user as by desgin in a new dashboard UI version.

Our KB Packet Capture Overview will be updated accordingly.

Re: This is unacceptable.

BHC_RESORTS — Fri, 10 Oct 2025 17:40:02 GMT

I agree that cable testing and port cycle is not a read-only function as it is doing something, but packet capturing is a read-only function. Granular security would be nice, but it's still a passive/read only operation.

Re: This is unacceptable.

CMR — Fri, 10 Oct 2025 19:19:20 GMT

I actually think there needs to be three levels.

manage

operate

view

I have several users who I want to be able to run cable tests, bounce ports, take packet captures etc. but not change things so with the current admin and read only, I'm happy for them to have the role. I wouldn't give someone access at all if I was worried about them bouncing ports for fun.

Re: This is unacceptable.

Raphael_L — Fri, 10 Oct 2025 21:08:11 GMT

This ^

I have around 400 users. Most of them are 100% clueless about networking. They only want to see the status of the switch ports , view the usage and so on. I don't want them to do packet captures, port cycles. Hell no.

Re: This is unacceptable.

roland.hollatz1 — Sun, 12 Oct 2025 07:12:50 GMT

I fully agree with you, read only should be read only without doing any action on the Dashboard

Re: This is unacceptable.

Philip D'Ath — Sun, 12 Oct 2025 20:32:08 GMT

I think you have outgrown the Administrator access controls that are provided by Meraki and need to consider a more granular and formal RBAC system, such as that offered by Boundless Digital.

https://www.boundlessdigital.com/product/access-control/

The question in my mind is what solution fits 80% of the customer base while retaining the "Meraki Simple" philosophy.

I think on balance, the current controls and functionality offered are about right (including allowing packet captures, switch port tests, and port cycles) for the vast majority of customers.

Re: This is unacceptable.

Stephen007 — Mon, 13 Oct 2025 13:08:58 GMT

Agreed — Meraki’s RBAC model needs to evolve.

I’d like to echo the point about outgrowing the current Admin vs. Read-only roles. For organizations with tiered support (Tier 1–4), the lack of granular access controls creates operational and security challenges — especially when using SSO.

Solutions like Boundless Digital offer the kind of role-based granularity that’s becoming essential. The real challenge is maintaining the “Meraki Simple” experience while expanding access control flexibility.

Would love to see Meraki explore native enhancements that strike this balance — perhaps starting with customizable permission sets tied to SSO roles.