cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1798
Views
20
Helpful
7
Replies

Tacacs Server Monitoring password encryption

Hello all,

 

I was wondering if there is way to encrypt the password used in the tacacs server monitoring configuration.

I see that the command itself offers no "key" parameter and since I can not find an example with encrypted password, I assume that it cannot be done.

tacacs-server host 10.10.1.1 test username user1 password Ur2Gd2BH idle-time 3

 

If anybody has any input on this please advise.

 

Thank you in advance,

Katerina

 

 

 

1 Accepted Solution

Accepted Solutions

Just to update the status of the case, the reply we got from TAC is:

 

"According to defect CSCuq78199, this is the current expected behavior for test user, it has not been changed so far"

 

So, no encryption is possible.

View solution in original post

7 Replies 7

Arne Bier
VIP
VIP

What platform is this on? I just checked on my Cat 9300 IOS-XE 16.12 and I cannot get the same syntax. I do have an option to encrypt the TACACS+ shared secret to my TACACS+ server.

 

I assume you already have the following global command enabled?

service password-encryption

Hi Arne,

 

We are running on Nexus 7K 8.3(2).

The thing is that all passwords are encrypted apart for the password that is used for "tacacs servers monitoring".

The service password-encryption command isn't supported, and I cannot find a feature that enables encryption. Any chance it is enabled by default, since all other passwords are indeed encrypted?

The following link shows how to configure "Tacacs Servers Monitoring" for Nexus.

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_tacacsplus.html#wp1551202

 

 

aaah Nexus - forgot about that. Quite a different code base it seems. I don't see any option in the config to obfuscate the password.

 

A question for Cisco (TAC maybe)?

 

If you can't hide the password from prying eyes, and you want to protect this account from being used elsewhere, then perhaps this is a suggestion:

You might want to add a rule to your RADIUS server (hopefully ISE) to only allow authentication using that username if the request came from the Nexus device(s). Depending on how your TACACS+ Policy Sets are structured, if you have a separate set for Nexus devices, then simply add this check into the other device categories (e.g. routers and switches - if the username contains "blah" then reject)

And give this account the least privileges required to do its job.

The test user has only purpose to verify tacacs-server availability. Care would have to be taken to ensure this user cannot do anything other than log off though. It is a risk vs. reward decision.
To protect network security, we recommend that you use a username that is not the same as an existing username in the TACACS+ database.

 

The monitoring user password is not encrypted on Nexus.

Hello Arne,

 

that is exactly what we have done. We have created the account in ISE, permitting authentication only from Nexus devices. The user is not authorized to perform any actions. Requests to any other devices get rejected.

Our concern are IT auditors that will see the unencrypted password and start asking questions, without understanding further explanations.

I also found a cisco document to deploy AES password encryption, but it doesn't seem to have any effect on "tacacs monitoring passwords".

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x_chapter_010101.p...

 

I will follow your recommendation and ask TAC.

 

Thanks!


@katerina.dardoufa wrote:

 

...Our concern are IT auditors that will see the unencrypted password and start asking questions, without understanding further explanations.

 


That happens no matter how securely you configure things. I often encounter uninformed auditors who rely solely on a Nessus scan or similar tool to create their "audit report". I just firs back at them with well-justified reasons for what I've setup and explain any necessary compensating controls that are in place - such as the ones you mention.

 

Just to update the status of the case, the reply we got from TAC is:

 

"According to defect CSCuq78199, this is the current expected behavior for test user, it has not been changed so far"

 

So, no encryption is possible.