MSP Tenant RBAC and Audit After a Production Change
An MSP manages 25 customer networks in a single ExtremeCloud IQ tenant. Each customer has its own device group and network policy. The MSP has three support tiers: Tier 1 monitors alarms, Tier 2 changes SSIDs and VLANs, Tier 3 manages firmware and tenant-wide settings. Two customers insist on having their own local admin who can only see their own devices. The MSP also wants to automate device onboarding with API tokens and require SSO with MFA for all staff. Last week a Tier 2 technician accidentally disabled a production SSID at a customer site, and the MSP had to rely on a phone call to find out who made the change. There is no change ticketing integration yet. The MSP wants least privilege and a clear audit trail.
1. Design the role and user group structure for the MSP, including the customer local admins and the API onboarding token.
Read the worked answer
Use least privilege and scope by customer. Create user groups mapped to customer device groups and assign read-only monitoring to Tier 1 across the customers they support. Give Tier 2 a role that can edit SSIDs and VLANs only within assigned customer device groups, not tenant-wide settings or firmware. Tier 3 gets tenant-wide administrative rights but still uses named accounts with MFA. Customer local admins get a scoped role limited to their own device group and policy, with no visibility into other customers. Map SSO groups from the identity provider to these ExtremeCloud IQ user groups so joiners and leavers are handled centrally. Create the API token only for onboarding, scope it to the minimum device operations, store it securely, and rotate it. Avoid shared accounts because they destroy accountability.
2. How would you investigate the accidental SSID disablement using ExtremeCloud IQ?
Read the worked answer
Use Audit Logs first, filtering by the customer, object type, and the approximate time window. Identify the account, source IP, action, and before-and-after values for the SSID state. Correlate with Events and Alarms to confirm when the SSID stopped broadcasting and which devices were affected. Check whether the change was made directly in the UI, through an API token, or through an automation workflow. If the SSID was disabled on a network policy, confirm which device groups received the policy and whether any other customer shared that policy. Restore the SSID by re-enabling it or by rolling back the policy change, then verify client association and alarms. Document the timeline and the account involved so the MSP can address the process gap rather than only the symptom.
3. What controls would prevent a repeat of the production SSID outage?
Read the worked answer
Separate production policy administration from everyday Tier 2 work. Tier 2 can stage changes in a non-production policy or submit a change request, while Tier 3 applies production SSID changes during a window. Require approval and a rollback plan, and integrate ticketing if possible so every change has a ticket reference. Enable alerting when a production SSID goes down or a policy change occurs, and review audit logs regularly. Use MFA and SSO for all staff, remove shared accounts, and restrict API tokens to specific onboarding tasks. Back up or export the working policy so restoration is fast. Finally, after any incident, review whether the role model actually enforced least privilege rather than assuming the UI role names were enough.