There seems to be a glaring oversight in the way guest ambassador accounts function. Any guest ambassador is able to revoke authorization for all other accounts currently existing, including all other admin accounts. Is there a way to prevent ambassadors from being able to do that? If not, assuming a guest ambassador had actually done that, how would the admins go about regaining access to their accounts and the dashboard?
Are you sure?
"Guest ambassador: User only able to see the list of Meraki authentication users, add users, update existing users, and authorize/deauthorize users on an SSID or Client VPN. Ambassadors can also remove wireless users, if they are an ambassador on all networks"
Yes, I am sure. I created a test guest ambassador and logged in as that user. The ambassador has the permissions it should (create a user, authorize a user, and revoke authorization for a user). But, included within the list of all currently-added guest user accounts is the list of admins of the system. The ambassador account is able to revoke the authorization of any/all admin accounts. This seems like a huge risk and something that should be preventable.
They can revoke ssid or vpn access to the ssid/vpn(network) they have access to. But not dashboard access.
Thank you for that clarification. So, it sounds like the admin accounts will still be able to sign into the Meraki dashboard website...they just would not be able to connect to any networks until their condition has been resolved. I would Meraki has this on their radar, at least. Ideally, I would love to see some additional restrictions in place on ambassadors, like the ability to only create accounts and/or re-authorize them but not the ability to de-authorize. Additionally, I would like it so ambassadors don't even see the administrators in the list of users whose accounts they can make adjustments to.
>So, it sounds like the admin accounts will still be able to sign into the Meraki dashboard website...they just would not be able to connect to any networks until their condition has been resolved.
This is exactly the case. Also note that "admin" users are not "authorized" by default. You still have to do that manually.