Scoping RBAC for a Contractor on a Fabric Network
A university runs XIQ-SE with Extreme Fabric Connect across three campuses: North, South, and West. The site hierarchy is currently flat, with all 1,100 devices in a single default site. A third-party contractor will manage the South campus access switches for 30 days and needs to view topology, alarms, and port status, but must not change VLANs, fabric roles, or device configuration. The internal tier-1 NOC needs to acknowledge alarms and bounce ports, but not edit policy. A separate policy team owns fabric role and VLAN mapping changes. Authentication is via Active Directory; today everyone who logs in is mapped to a single XIQ-SE administrator group because 'it was faster during the rollout'. The security office also wants an audit trail showing who acknowledged alarms and who changed fabric policy.
1. Design the user groups and authorization mapping, explaining why each group gets its level of access.
Read the worked answer
Use AD groups mapped to distinct XIQ-SE user groups, and make the mapping explicit rather than relying on a default group.
- Contractor-South (read-only, site-scoped). Needs topology, alarm, and port status visibility for South only. Give read access to the South site scope and no write access to device configuration, fabric roles, or policy. This satisfies the business need without granting change rights that the contract does not cover.
- NOC-Tier1 (operational write, limited). Needs alarm acknowledgement and port enable/disable. Grant the specific operational actions, not general configuration write. If port bounce is implemented as a device action, scope it to the NOC's sites and audit it. Do not give policy or fabric write.
- Fabric-Policy (policy write). Owns role, VLAN, and fabric attach mappings. This group should be small and should not also have full user administration.
- XIQ-SE-Admins (full). Break-glass and platform administration only; membership should be reviewed and should not include the contractor.
Map AD groups to these XIQ-SE groups and remove the catch-all administrator mapping. The audit requirement is met by unique named accounts and by retaining the XIQ-SE audit/log records for the 30-day period and beyond; shared accounts would defeat it.
2. The site hierarchy is flat, so how do you actually restrict the contractor to South campus?
Read the worked answer
The scope has to exist before you can assign it. RBAC in XIQ-SE follows the site/device organization, so a flat hierarchy gives you only 'all devices' or 'no devices'.
Steps:
- Create a top-level University site with child sites North, South, and West, and assign devices by management subnet, seed device, or inventory rule. Validate the assignment counts against the known per-campus totals (for example, South should have roughly one third of the 1,100 devices).
- Create the contractor's user group with read-only access and attach it to the South site scope, not the root.
- Create a test AD account in the contractor group and log in to confirm: South devices visible, North and West not visible, and configuration/policy menus not writable.
- Check the fabric view. Fabric topology may span campuses; if the contractor can see all fabric nodes through a global topology view, restrict the topology scope or accept that read-only fabric topology is visible and document that decision. Do not grant fabric write to compensate.
If the platform's site scoping cannot meet the requirement, the fallback is a separate XIQ-SE instance for the contractor, not a broad read-only account on production.
3. Which fabric and policy objects should be protected from the NOC and contractor groups, and why?
Read the worked answer
Protect anything that can change forwarding or admission for a whole campus:
- Fabric roles and VLAN-to-role mappings. A role change can move an access port into the wrong service VLAN or isolate a department.
- Fabric attach and control settings. Changing IS-IS/SPBM parameters or attach port configuration can cause fabric-wide reconvergence.
- Policy and ACL objects. A modified ACL can silently block management access or clinical/student traffic.
- Device configuration templates and scripts. These apply at scale and can overwrite local changes.
The NOC's legitimate actions are alarm acknowledgement and port state changes. Those are bounded and reversible. Fabric policy changes are neither: a bad role mapping may look fine in the UI but break authentication or DHCP for an entire building. The policy team should own them, with change control and audit. The contractor should have read-only visibility so they can troubleshoot their own switches without being able to alter the fabric. This separation also gives you a clean audit answer when security asks who changed a role: the policy group's named accounts, not a shared administrator login.