05-21-2021 02:02 PM
Hello Team,
I have a customer that is wanting to restrict the local user database to console only.
They also want console to be authenticated with TACACS+ and Local Database.
I have already applied the config to acouple 3750's and 3850's and the configuration works as expected.
But is there any glaring issues that anyone can think of before I do the final proposal to the customer?
Switch##sh run | b aaa
aaa new-model
!
!
aaa group server tacacs+ ISE_TACACS
server name ISETAC01
server name ISETAC02
!
aaa authentication login default local
aaa authentication login CON group ISE_TACACS local
aaa authentication login VTY group ISE_TACACS
aaa authentication enable default group ISE_TACACS enable
aaa authorization console
aaa authorization exec CON if-authenticated
aaa authorization exec VTY group ISE_TACACS local if-authenticated
aaa authorization commands 1 VTY group ISE_TACACS local if-authenticated
aaa authorization commands 15 VTY group ISE_TACACS local if-authenticated
Switch#sh run | b line con 0
line con 0
exec-timeout 0 0
privilege level 15
authorization exec CON
logging synchronous
login authentication CON
transport preferred none
line vty 0 4
access-class 30 in
exec-timeout 1440 0
privilege level 15
authorization commands 1 VTY
authorization commands 15 VTY
authorization exec VTY
logging synchronous
login authentication VTY
line vty 5 15
access-class 30 in
authorization commands 1 VTY
authorization commands 15 VTY
authorization exec VTY
logging synchronous
login authentication VTY
Thanks!
-Ryan Reich
Sirius Managed Services
05-21-2021 10:52 PM
Ryan
I am not clear about this statement of your requirements "They also want console to be authenticated with TACACS+ and Local Database." One way to understand it is that they want the local data base to be used as a backup for login on console if tacacs is not available. And that is what you have configured. Another way to understand it is that a user in the local data base should be able to login on console even if tacacs is running successfully. Your configuration would not accomplish this.
You say that you have configured this and that it works as expected. So I am guessing that the first understanding is what they want. So they have a fall back authentication method for the console and no fall back authentication method for remote access.
You ask if there are any glaring issues. I do not see anything glaring but do see a few things worth mentioning:
- this configuration accepts both telnet and SSH for remote access. From a security perspective it might be better to allow only SSH and not telnet.
- this configuration puts any user who authenticates at user level on access to vty 0 4 directly into privilege mode, bypassing the requirement that they authenticate separately for privilege level access. Is that a good thing? If so why not also do it for vty 5 15?
- you also put any user who authenticates at user level on the console directly into privilege mode. I wonder if they really want that?
- you change the default exec timeout for vty 0 5 but not for vty 5 15? Why this inconsistency?
05-24-2021 08:31 AM
Richard,
Actually the input you gave was great!
I did somehow not lookover the config differences between the 5 15 lines.
Yes I have just then fixed the config for removing telnet... Geez what a hole.
I appreciate the help!
-Ryan Reich
05-24-2021 10:09 AM
Ryan
You are welcome. I am glad that my suggestions were helpful. It is almost always helpful to have a second pair of eyes look through a configuration. That is one of the very nice things about this community. I hope to see you continue to be active in the community.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide