A game studio needs an MDS account that can build and activate zones but cannot create user accounts or change AAA. Which control enforces that split on the SAN switch?
Select an answer to reveal the explanation.
Short Explanation
An MDS role is a job description written on the SAN switch itself. You permit zoning commands in a custom role and leave out user and AAA administration. Port security decides which HBA may log in, not which person may type zone commands.
Full Explanation
MDS authorization is role-based. A custom role can permit the zoning command set, including activating a zoneset, and deny the commands that create users or change AAA. Assigning the studio account to that custom role enforces the split on the SAN switch. Port security on an F port binds a host PWWN so a stranger cannot complete FLOGI there. It does not decide which operator may enter configuration mode, and it does not permit or deny zone commands. Fabric binding limits which switch WWNs and domain IDs may join the fabric. It does not grant a zone administrator a login, and it does not stand in for a role on the switch. An RBAC role that exists only on an Ethernet Nexus leaf applies to that leaf. The MDS does not copy that role when a host logs into the SAN. Caveat: if a AAA server returns a role name that does not exist on the MDS, the session will not receive these zoning rules, so the custom role has to exist on the switch. Operational check: log in as the zone account, activate a test zoneset in a lab VSAN, and confirm that creating a user and changing AAA are both rejected.