Role-Based Access for Staff, Contractors, Devices, and Guests
A 500-bed hospital has 2,500 staff, 400 contractors, and 1,200 medical devices. ClearPass is integrated with AD. The current SSID uses one PSK; all clients land in VLAN 200, which can reach clinical servers. Contractors have been found on the clinical VLAN. Medical devices cannot do 802.1X. The security team wants role-based access: staff to clinical applications, contractors to internet only, devices to a server subnet, and guests through a captive portal. The hospital has 300 APs and two controllers.
1. Design the role derivation and enforcement model. Include how each population is authenticated and what the controller enforces.
Read the worked answer
Separate authentication from authorization. Staff use 802.1X against AD; ClearPass maps an AD group such as HOSP-Clinical to a staff role. Contractors use 802.1X or a sponsored account and map to a contractor role. Medical devices use MAC authentication against a registered device list, optionally with profiling to confirm the device type. Guests use a captive portal with sponsor approval or self-registration and a short-lived account.
Enforce on the controller with user roles, not just VLANs: staff role gets VLAN 210 plus an ACL permitting clinical applications and standard services; contractor role gets a guest VLAN and an ACL allowing only DHCP, DNS, and internet; device role gets VLAN 220 and an ACL allowing only the necessary server subnets and no client-to-client traffic; guest role gets an isolated guest VLAN, captive portal, and internet-only ACL. ClearPass returns the role and VLAN as RADIUS attributes, and the controller applies the role at the client's first enforcement point. This removes the single-PSK shared-key model that let contractors reach clinical resources.
2. How would you onboard and authenticate medical devices that cannot do 802.1X without creating a new shared-PSK risk?
Read the worked answer
Use MAC authentication with a controlled registration process. Discover devices, record MAC address, device type, and owning department, then create ClearPass device entries or import from a trusted inventory. On the controller, the device SSID uses MAC authentication against ClearPass; ClearPass profiles the device and returns a device-specific role and VLAN. If the device supports only PSK, use per-device or per-group MPSK rather than one hospital-wide PSK, so a leaked key affects only one device group.
The device role should be least privilege: permit only the required server subnets and ports, block client-to-client traffic, and deny internet unless clinically required. Monitor failed MAC authentications; a sudden spike may indicate spoofing or a misconfigured device. Do not place devices in the same VLAN as staff or contractors. Review the device list quarterly and remove retired equipment.
3. A contractor reports internet access, but monitoring shows the contractor received a clinical VLAN address. What would you check first, and how would you fix it?
Read the worked answer
Check the authorization path before changing the network. In ClearPass, confirm the contractor's authentication succeeded and that the enforcement profile returned the contractor role and VLAN. If the profile is correct, check the controller's role mapping and whether the RADIUS attributes were accepted: a missing or unsupported VLAN attribute can cause the client to fall back to the initial role or default VLAN. Also check for a cached role or an existing session that was not reauthenticated after the policy change.
If ClearPass returns the wrong profile, fix the role mapping rule and reauthenticate the client. If the controller ignores the attribute, correct the server-group or vendor-specific attribute configuration. Then verify the client table shows the contractor role and guest VLAN, and test that clinical subnets are unreachable. Finally, add a monitoring check that alerts whenever a contractor identity appears in the clinical VLAN, so the fallback is caught immediately rather than during an audit.