A school district connects NSX-T Manager to Workspace ONE Access so civic admins can sign in. Teachers still need Active Directory group-based distributed firewall rules on student VDI. What should the administrator configure next?
Select an answer to reveal the explanation.
Short Explanation
Two different front doors. Access is who may log into NSX Manager, while the AD directory is who the firewall thinks is sitting at the VDI keyboard—do not mix those jobs.
Full Explanation
When a school district connects NSX-T Manager to Workspace ONE Access for civic admin sign-in, that Access connection is RBAC for NSX administrators—not the identity source for teacher Active Directory group-based distributed firewall on student VDI. Next, join NSX Manager to the student Active Directory for Identity Firewall so teacher groups can be used in DFW.
Reusing the Workspace ONE Access connection as the IDFW identity source so teacher groups appear in DFW confuses admin IdP with IDFW directory. Adding teachers to a Carbon Black watchlist does not create NSX IDFW sources. Publishing an Access authentication policy on the VDI segment cannot replace LDAP directory config for IDFW.
Exam caveat: Access-as-NSX-admin-IdP ≠ AD-as-IDFW-directory—configure both roles explicitly when both are needed.
Operational check: keep Access for admin login, add student AD for IDFW, sync teacher groups, publish a pilot IDFW rule on VDI, and document the split identity purposes.
Split identity purposes clearly: Access for who may administer NSX, student AD for who may pass IDFW on VDI. Put both connections on the school district identity architecture diagram, and test that removing an admin from Access does not disturb teacher IDFW groups.