A city traffic-operations center enables TACACS+ command authorization and then sees privileged commands fail for valid network engineers. What dependency should they verify on the AAA server?
Select an answer to reveal the explanation.
Short Explanation
Turning on command authorization without matching TACACS profiles is like locking every door and forgetting to hand out keys—good engineers still get blocked.
Full Explanation
When a city traffic-operations center enables TACACS+ command authorization and then privileged commands fail for valid network engineers, verify server-side user and group profiles. Enabling authorization without matching permit rules denies commands even for operators who authenticate successfully—the router asks the AAA server, and restrictive or missing profiles answer no for signal-shop and TOC edge changes that would otherwise be routine.
Command authorization does not ignore server profiles and read only the local enable secret once authZ is in force. RADIUS need not be disabled globally for TACACS+ command authorization to run; both can exist with clear method lists. CoPP classifying Telnet in class-default is unrelated to whether command authorization profiles permit a command on the TOC routers.
Exam caveat: authZ failures after enabling command authorization point to AAA profiles and arguments, not CoPP or a mandate to disable RADIUS. Operational check: review TACACS+ shell and command sets for the engineer’s group, compare denied commands in accounting logs, temporarily test a known-good profile on a TOC lab router, and only then chase network path or method-list typos.