Some boxes reference enable secret, some do not

Kevin Melton · ‎05-15-2009

I am working at a client site today that uses a Cisco ACS server via AAA to authenticate users. TACACS is configured and when an admin ssh's to a box on the network, the box queries TACACS which in turn queries Active Directory to authenticate the user.

We came up with a policy that would grant priveleged mode to the authenticated user, and then they would have to enter the "enable secret" password locally on the box to enter into PRIV EXEC mode.

For some reason, most of our Cisco devices work fine this way. But we have a handful that will authenticate directly to PRIV EXEC mode after TACACS authentication without prompting the admin for the enable secret password.

I have inspected the configurations on the devices that do not challenge for the enable secret, and they have the same aaa command configured on them as the ones that do challenge for the enable secret password.

Here is an example configuration:

aaa new-model

aaa authentication login default group tacacs+ line

aaa authentication login vty-access group tacacs+ local

aaa authentication enable default enable

aaa authorization config-commands

aaa authorization exec vty-access group tacacs+ local none

aaa authorization commands 0 default group tacacs+ none

aaa authorization commands 1 default group tacacs+ none

aaa authorization commands 2 default group tacacs+ none

aaa authorization commands 3 default group tacacs+ none

aaa authorization commands 4 default group tacacs+ none

aaa authorization commands 5 default group tacacs+ none

aaa authorization commands 6 default group tacacs+ none

aaa authorization commands 7 default group tacacs+ none

aaa authorization commands 8 default group tacacs+ none

aaa authorization commands 9 default group tacacs+ none

aaa authorization commands 10 default group tacacs+ none

aaa authorization commands 11 default group tacacs+ none

aaa authorization commands 12 default group tacacs+ none

aaa authorization commands 13 default group tacacs+ none

aaa authorization commands 14 default group tacacs+ none

aaa authorization commands 15 default group tacacs+ none

aaa authorization network default group tacacs+ none

Collin Clark · ‎05-15-2009

Do the VTY's have-

privilege level 15

That's typically where you get PRIV EXEC mode from.

Kevin Melton · ‎05-15-2009

We have the following commands configured on our vty lines:

line vty 0 4

session-timeout 30

access-class telnet-access in

exec-timeout 15 0

authorization commands 15 vty-access

authorization exec vty-access

logging synchronous

login authentication vty-access

transport input telnet ssh

line vty 5 15

session-timeout 30

access-class telnet-access in

exec-timeout 15 0

authorization commands 15 vty-access

authorization exec vty-access

login authentication vty-access

transport input telnet ssh

we tried negating the

"authorization commands 15 vty-access" but to no avail.

At that point we were authenticating to TACACS fine and then getting prompted like we wanted. But for some reason( witnessed during debug aaa auth) we were getting password mismatches. We re-entered our enable secret password and tried again, but kept on getting password no match and then "Access Denied".

Perhaps you can help out and tell me what should be configured on the VTY lines so that it will reference the enable secret?

Collin Clark · ‎05-15-2009

What you have looks good. Does everything look OK in ACS?

Richard Burts · ‎05-15-2009

Kevin

My guess at this point is that the issue is not on the router but is in ACS. Can you check on the configuration in ACS of a couple of the devices that put authenticated users directly into privilege mode? Do these devices have the shell exe checked (and do they give privilege level 15)?

The command on the router that works with this is the command:

aaa authorization exec vty-access group tacacs+ local none

I would suggest a slight revision of this to make it like:

aaa authorization exec vty-access group tacacs+ if-authenticated

HTH

Rick

HTH

Rick