Mixed Cisco and FortiSwitch VLAN Enforcement
A hospital has 18 Cisco Catalyst 2960X switches and 6 FortiSwitch 108E access switches. FortiNAC-F uses SNMPv3 authPriv for read-only polling and a CLI service account for write actions. The Cisco switches appear in inventory with the correct model and ports, but when a policy assigns VLAN 40 to a registration port, the port stays in VLAN 10. The FortiSwitch devices enforce VLAN 40 correctly. The Cisco CLI account is privilege level 1, and the TACACS+ server returns 'Command authorization failed' for 'configure terminal'. The SNMPv3 user has full read access to the required MIBs. The network team wants to keep SNMP read-only, avoid Telnet, and retain command accounting. They also do not want to give the service account full administrator rights on every switch.
1. Why does the FortiSwitch enforce VLAN 40 while the Cisco switch does not, even though SNMPv3 read polling succeeds on both?
Read the worked answer
SNMP read success only proves monitoring. VLAN assignment is a write action, and on Cisco IOS FortiNAC performs that write through the CLI, not through the read-only SNMP user. The FortiSwitch path is working, so the policy, VLAN 40 definition, and FortiNAC enforcement engine are not the common failure point. On the Cisco side, the CLI account is privilege 1 and TACACS+ rejects 'configure terminal', so FortiNAC can read the port state but cannot change it. The switch logs and FortiNAC device validation should show the CLI write failure. Do not conclude that SNMP polling is broken; check the device's read and write capability separately and confirm that FortiNAC selected the CLI method for VLAN changes.
2. What is the minimum change to the Cisco service account, and how do you validate it without granting full admin?
Read the worked answer
Grant only the commands FortiNAC needs, using TACACS+ command authorization or a limited privilege role. Typical commands include entering configuration mode, selecting an interface, setting access and voice VLANs, and writing the configuration; FortiNAC also needs the show commands it already uses. If the platform cannot scope commands cleanly, a privilege 15 account is the fallback, but it should be restricted by AAA to the FortiNAC management address and audited. Validate in two steps: first, use the FortiNAC device test to confirm CLI login and read/write; second, manually SSH from the FortiNAC CLI to one lab switch and run the exact VLAN change on an unused port. Confirm the port changes, the change is logged, and FortiNAC can read the new state. Then test a policy-driven assignment on the same lab port.
3. Would enabling SNMP read-write on the Cisco switches be an acceptable shortcut? Explain the trade-off.
Read the worked answer
No, not as a shortcut. SNMP read-write gives broad object-level write access, is harder to scope to specific VLAN commands, and often bypasses the TACACS+ command accounting the team wants. It also creates a second enforcement path to test and troubleshoot. FortiNAC may support SNMP writes on some vendors, but the safer design here is least-privilege CLI with AAA. Keep SNMPv3 authPriv read-only for inventory and topology, and fix the CLI authorization. If SNMP write is used, it should be a deliberate vendor-supported design with a restricted view and change control, not a workaround for a privilege-1 account.