Device Credentials Not Working using TACACS

[malvadobladez]

I am currently having an issue with Cisco Works trying to login to any of my devices.

We use TACACS for enable authentication, What I keep seeing in the ACS Logs is basically a garbage username and a failed attempt.

Here is the version of Cisco Works we are running.

1. CiscoWorks Common Services 3.0.5 24 Nov 2006, 15:40:40 EST

2. Campus Manager 4.0.7 24 Nov 2006, 16:25:26 EST

3. CiscoView 6.1.5 24 Nov 2006, 15:40:52 EST

4. Device Fault Manager 2.0.7 24 Nov 2006, 16:45:18 EST

5. Internetwork Performance Monitor 2.6.0 10 Mar 2005, 18:15:48 EST

6. Integration Utility 1.6.0 10 Mar 2005, 17:10:00 EST

7. Resource Manager Essentials 4.0.5 24 Nov 2006, 15:41:09 EST

Here is a sample of what I see in the ACS Logs

12/05/2006 15:38:46 Authen failed U_@o$5h# Network OPS 10.144.220.100 Invalid characters in username

I am able to login into each deivce manually with the account that has been configured in Cisco Works.

Any help on this would be appreciated.

TIA.

[Joe Clarke]

Can you relate those errors to a time when a specific task happens in CiscoWorks (for example, RME config sync, device credential verification, etc.)? I have not heard of any username corruption issues with CiscoWorks and DCR. Perhaps a particular device or version of device code is bad.

If you are using telnet, try sniffing the packets once you figure out which task or tasks trigger these errors. See if CiscoWorks is actually sending the bad username, or if it is the device doing it when talking to ACS.

[malvadobladez]

CiscoWork is sending the bad username and password, as I can tell from the logs in the ACS it show the ip address of the ciscoworks server as trying to make the connection.

The one area I can repeat this on is device credential reports, When I export the the device list I see all the proper username and passwords, but when I try to verify the credentials I always get the following error.

Device Credentials Verification Job Details

Device Name Read Community Write Community SNMPv3 Telnet Enable by Telnet SSH Enable by SSH

1. c3750_agi_105.net.adp.ca Ok Ok No Value To Test Ok Incorrect Ok Incorrect

The enable username and password are correct and I am able to manualy login to the device with no issue.

[David Stanford]

What does your enable username prompt look like? I'm not even sure if we support enable usernames to be honest, but you can try modifying your TacacsPrompts.ini file so that it has your prompt:

[TELNET]

USERNAME_PROMPT=Username:,username:

PASSWORD_PROMPT=Enter PASSCODE: ,PASSCODE: ,Password:

Also, keep spaces in mind too

[malvadobladez]

User Access Verification

Password: ******

c6509_ibm1_17>en

User Access Verification

Username: username

Password: *******

This is the prompts.

[Martin Ermel]

do you have any special characters in the username?

[Joe Clarke]

What about the sniffer trace? Does RME actually send the garbage username? Is the garbage value the same every time?

[malvadobladez]

The garbase username is the same everytime

U_@o$5h#

As for special charaters in the username no...

cscowks is the username....

Have not been able to do a sniffer trace yet, but the username is always the same, or at least this is the name that ACS is showing coming from the CiscoWorks IP address.

[Joe Clarke]

U_@o$5h# is a bogus username value that is used by the underlying CLI library in CiscoWorks. This username will only be used if DCR does not have a valid username for the device, and there is a problem with authentication.

Therefore, the sniffer trace would be the most useful thing to see why authentication is failing, and causing this bogus value to be used.

[malvadobladez]

I will see about getting that sniffer trace.