cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2649
Views
0
Helpful
9
Replies

LMS 3.2 with RME 4.3 Telnet credentials issue

Martin Smid
Level 1
Level 1

Hi,

I have an issue with telnet credentials in LMS. We use ACS server with TACACS+ for authentication. I can't seem to be able to find a detailed guideline how to configure the credentials so maybe I am doing something wrong. Please see the attached screenshot showing where I configured the telnet credentials. The other screenshot has results of config fetch jobs. What worries me a little bit is the fact that the job itself could not be executed in the first place? The wait time is 3 minutes.

If I test the credentials in RME -> Devices -> Device Management -> Device Credentials Verification jobs the telnet shows as incorrect as well.

EDIT: The telnet credentials are valid. I use them to access our devices.

Hope it makes sense,

Martin

1 Accepted Solution

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

You are configuring the credentials in the correct place.  However, unless you login and are immediately enabled, you will need to enter an enable password as well in DCR.

The first error points to a potential problem with ConfigMgmtServer.  Most of the known bugs surrounding this are fixed in RME 4.3, but there is still one outstanding: CSCtg43962.  Try restarting ConfigMgmtServer with the commands:

pdterm ConfigMgmtServer

pdexec ConfigMgmtServer

Then try and archive the config again.  If it still fails, start a packet capture filtering on all telnet traffic to the device, and run the job again.  The sniffer trace should clearly show what is going on.  If the DCR credentials are correct, another common problem with config archive is custom authentication prompts.  If you have custom prompts configured on your AAA server, you will need to add them to NMSROOT/objects/cmf/data/TacacsPrompts.ini.

View solution in original post

9 Replies 9

Joe Clarke
Cisco Employee
Cisco Employee

You are configuring the credentials in the correct place.  However, unless you login and are immediately enabled, you will need to enter an enable password as well in DCR.

The first error points to a potential problem with ConfigMgmtServer.  Most of the known bugs surrounding this are fixed in RME 4.3, but there is still one outstanding: CSCtg43962.  Try restarting ConfigMgmtServer with the commands:

pdterm ConfigMgmtServer

pdexec ConfigMgmtServer

Then try and archive the config again.  If it still fails, start a packet capture filtering on all telnet traffic to the device, and run the job again.  The sniffer trace should clearly show what is going on.  If the DCR credentials are correct, another common problem with config archive is custom authentication prompts.  If you have custom prompts configured on your AAA server, you will need to add them to NMSROOT/objects/cmf/data/TacacsPrompts.ini.

Hi Joe,

The credentials I use do give you enable access straight away.

About the service restart, I have restarted the whole server several times already mainly because of "Internal error in communication channel". We will probably have to raise a TAC request for a patch, which I believe you wrote, for multi-processor Windows servers.

I will try to get a sniffer between those two servers and hopefully that will show us what's happening. What I don't understand is why some devices show in our ACS log with "missing username" as a failure reason and others don't show at all. We have device pooling every morning and that's when I see at least a reason for failure. If I manually set LMS to fetch the config there is nothing in ACS.

The authentication prompts were never configured so they should be all default, but it is definitely something worth checking out.

Thanks for the info Joe. If you can think of anything else what could cause these issues and shed some light on the inconclusive ACS reports that would be great.

LMS will establish an initial TCP socket to the device to determine supported protocols and for things like transferring vlan.dat, the local interface of the LMS server.  This could result in a "missing username" error on ACS.

Yes, I wrote a patch to fix a problem with DCR communication due to a timing issue on multi-processor Windows machines.  TAC can provide you that patch.

Martin Smid
Level 1
Level 1

The reason for the telnet credentials to fail was that the file with tacacs prompts was not pre-configured with any default values. The username and password promts were added in and everything is fine now.

Thanks Joe.

Hi Martin,

Can you explain more, where have you added the username and password ?

Are you using ACS5.x  or ACS4.x? For us everything works fine with ACS4.2 but then we try with ACS 5.x we get error : 13030 TACACS+ authentication request missing a User name.

If you're using custom TACACS+ prompts on your device (i.e. custom username and password prompts), add those new values to NMSROOT/objects/cmf/data/TacacsPrompts.ini.  The default prompts are "Username:" and "Password:".  Any other values will need to be added to the TacacsPrompts.ini file.

Hi Joseph,

We are using default TACACS+ promts.

But the problem we have is: we are not able to access devices from RME using telnet, but outside of RME telnet with the same username/password works and this error appear just using ACS5.1 server. With ACS4.x works just fine. So why everything works on ACS4.x but fails on 5.1.

We are also using default tacacs+ prompts with ACS 5.1. After updating the tacacsprompts.ini the issue was resolved. The error message with missing username appears whenever LMS (or other monitoring system) uses SNMP to poll the device for config. At least that's what I see in our logs. Whenever LMS can't login and uses SNMP, ACS just spams the log with missing username errors.

Yes now it works fine.

We changed tacacsprompts.ini file to :

[TELNET]

USERNAME_PROMPT=Username:,username:,AD-brukernavn:

PASSWORD_PROMPT=Password:,password:,AD-passord:

root@byggvir #

Thanks you !!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: