Cisco AAA and Audit Logging: Why Authorization Changed Our Decision

A security review required AAA on a Cisco device. The administrator asked why the existing management setup needed aaa new-model. We asked the security team which records they needed. Their concern was administrative access and activity, so we examined whether the existing logging features could meet the requirement.

The documented coverage of login and configuration-change logs addressed parts of it. The unresolved requirement was evidence of prohibited command attempts and their authorization outcome. That requirement led us to choose AAA. Enabling aaa new-model alone does not establish that the required audit records are generated or retained.

Review scope

Context: A security finding requiring AAA.
Initial question: Could existing logging features provide the required audit evidence?
Deciding requirement: Records of prohibited command attempts and their authorization outcome.
Confirmed outcome: The decision to use AAA.

The CLI examples apply to Cisco IOS and IOS XE. NX-OS, IOS XR, and ASA use different configuration models and behavior. These fragments illustrate individual features, not a complete deployment or completed production tests. Check support, prerequisites, and output for the exact device and release.

Required audit evidence

We turned the audit requirement into these questions:

Who successfully logged in?
Who failed to log in?
Who changed the configuration?
What administrative activity was performed?
Who attempted an operation that the account was not permitted to execute?

We compared the available features against each requirement:

Required evidence	Feature considered	Review conclusion
Successful and failed logins	Login-event logging	Relevant to access-history requirements.
Configuration activity	Configuration archive logging	Useful within its documented command coverage.
Complete session and command activity	Combined ordinary logs	Not established as equivalent to AAA accounting.
Prohibited command attempts	Login and configuration logs	Did not establish the required authorization-denial evidence.

Login-event logging

IOS can log successful and failed login attempts:

login on-success log
login on-failure log

These global commands enable login-event logging; they do not define access permissions.

Cisco documents these features in its IOS Login Enhancements documentation. Prerequisites vary by release. In particular, older login-enhancement procedures include login-block settings, whose access-blocking behavior should be reviewed separately.

We considered this a source of login evidence. Validation would require controlled successful and failed logins through the actual management path, followed by inspection of the records. Those records do not establish which commands the user was authorized to execute after login.

Configuration-change logging

The configuration archive logger covers another part of the requirement:

archive
 log config
  logging enable
  hidekeys
  notify syslog

The example enables configuration-command logging and syslog notifications, with hidekeys suppressing password information. It changes the logging configuration. Display the log with this read-only command:

show archive log config

Cisco documents limits to this feature: it covers complete configuration-mode commands, excludes syntax errors and help requests, and does not record individual commands applied through a configuration-file copy. See Configuration Change Notification and Logging.

Its coverage is limited to the documented configuration activity. It does not record every typed command or authorization decision.

The scope of AAA accounting

Cisco documents accounting categories that include EXEC sessions and commands at specified privilege levels, with records sent to the configured security server. These are separate from the local configuration archive. See the Cisco AAA Accounting Command Reference.

Ordinary logs could provide part of the activity evidence. We had not established them as a complete replacement for AAA accounting.

Evidence of denied commands

We still needed evidence for a logged-in user who requested a command outside the account's permissions. The record needed to identify:

The user making the attempt.
The requested command and relevant arguments.
The authorization result.
The time and device associated with the event.
The reason for denial, where available.

A login-success message does not record that authorization decision, and the configuration logger does not provide a general command-authorization trail. The logging alternatives reviewed did not establish this coverage, so we chose AAA. That conclusion applies to the features examined. Other platforms and non-AAA mechanisms require their own evaluation.

Cisco's command-authorization example

Cisco's IOS and ISE example uses TACACS+ command authorization. A restricted user can run permitted commands, and rejected attempts can be inspected in ISE's TACACS Live Logs.

The documented lab uses IOS 15.4(3)M3 and ISE 2.0. It illustrates that particular design; it is not confirmation of identical behavior on every release. See Cisco's TACACS+ Authentication and Command Authorization example.

In Cisco's example, the failed-command evidence is on the AAA server. The reference does not establish that we deployed ISE or TACACS+, or that ordinary device syslog automatically contains those records.

What aaa new-model establishes

Cisco defines aaa new-model as enabling the AAA access-control model. Enabling that model does not demonstrate that all required authorization checks and records have been configured. See the Catalyst 9200 IOS XE 17.4 Command Reference.

Local authentication also does not establish that prohibited command attempts are retained.

The design must specify the authorization method, command coverage, affected management paths, and collection point for the required records.

Acceptance checks before closing the finding

These are proposed acceptance checks, not completed production tests:

Confirm that successful and failed login attempts produce the required identity and outcome information.
Perform a permitted test operation and confirm the required activity record.
Use a restricted test account to attempt an operation that the policy should deny.
Confirm both the denial and a retained record identifying the user, requested operation, and result.
Verify that the security team can retrieve and interpret the evidence at the intended collection point.

AAA changes can affect administrative access. Keep a verified recovery path and test a separate management session before closing the current one.

Decision and remaining verification

We chose AAA for the authorization requirement. Acceptance still requires demonstrating that the necessary records are generated and retained; aaa new-model alone does not complete that test.

For a local-account login migration plan without an external authentication server, see Cisco Catalyst 9200L Local AAA Migration: Planning and Verification on IOS XE 17.18.4. The plan covers login authentication and access verification; command authorization and denial logging require separate validation.

References

For a separate NX-OS example of checking platform behavior before acting on a security finding, see Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It.

Search This Blog

NetOps Field