dcrcli fails after new installation of LMS 3.2

Answered Question
Aug 11th, 2009

After uninstalling LMS 3.1 and installing LMS 3.2 on Solaris the authentication fails when running the dcrcli command.

dcrclient.log:

FATAL com.cisco.nm.dcr.Encoder - Exception in decoding the given string

com.cisco.nm.cmf.security.Base64FormatException: Invalid length.

at com.cisco.nm.cmf.security.Base64Decoder.process(Base64Decoder.java:161)

at com.cisco.nm.cmf.security.Base64Decoder.processString(Base64Decoder.java:184)

at com.cisco.nm.dcr.Encoder.decode(Encoder.java:23)

at com.cisco.nm.dcr.DCRcli.main(DCRcli.java:202)

Any ideas ?

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 7 years 3 months ago

While I am still not able to reproduce your problem, I found quite a few issues with dcrcli, one of which _may_ account for what you're seeing. If you'd like to try a patch, open a TAC service request, and have your engineer contact me directly. I filed CSCtb40866 to track the issues I found with dcrcli.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Tue, 08/11/2009 - 23:54

I cannot reproduce. How exactly are you running the command? The error points to a bad password, or more exactly, a bad base64 encoded password. I just did:

# dcrcli -u admin

(entered admin's password)

dcrcli>

s.leyer Wed, 08/12/2009 - 00:17

# dcrcli -u admin

*DCRCLIFILE Environment variable not set.

Enter your password

(entered admin's password)

Authentication Failed. Verify username and password entered

Joe Clarke Wed, 08/12/2009 - 07:41

Are you certain about admin's password? Is this server integrated with ACS, or using some other authentication module?

s.leyer Thu, 08/13/2009 - 00:34

The password was correct and we're using the local authentication module.

I've made several tests and the problem seems to be due to the password.

THe authentication was successful after changing the admin's password, but when I changed it back to the previous password, the authentication failed again.

Same thing with a new user. Authentication failed when I gave him the admin's password.

Ok, I've found the workaround : new password.

Thanks for the assistance.

Joe Clarke Thu, 08/13/2009 - 04:49

Actually, this is certainly a bug. If possible, can you share the bad password. I should be able to fix that. We saw something similar in Cisco.com credentials a while back. We had a bad base64 encoder.

s.leyer Fri, 08/14/2009 - 03:52

As I can't share the password I was looking for some kind of variation. The decoding of passwords containing only alphabetic characters (upper or lower case) works fine. As soon as there is a numeric character in the password, the decoding fails.

"password" is ok, "password1" fails. Try it out.

I didn't check special characters.

Joe Clarke Fri, 08/14/2009 - 21:24

Thanks for the pointer. I tried to recreate this on Solaris 10, and I cannot. Both "password" and "password1" produce correct base64 strings. I also verified the code has not changed between LMS 3.1 and 3.2.

I would still like to explore this, so if you can open a TAC service request, your engineer can pass the requisite data on to me.

Correct Answer
Joe Clarke Sun, 08/16/2009 - 10:34

While I am still not able to reproduce your problem, I found quite a few issues with dcrcli, one of which _may_ account for what you're seeing. If you'd like to try a patch, open a TAC service request, and have your engineer contact me directly. I filed CSCtb40866 to track the issues I found with dcrcli.

Actions

This Discussion