Solved: dcrcli fails after new installation of LMS 3.2

s.leyer · ‎08-11-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 ?

Joe Clarke · ‎08-16-2009

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.

View solution in original post

Joe Clarke · ‎08-11-2009

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 · ‎08-12-2009

# dcrcli -u admin

*DCRCLIFILE Environment variable not set.

Enter your password

(entered admin's password)

Authentication Failed. Verify username and password entered

Joe Clarke · ‎08-12-2009

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

s.leyer · ‎08-13-2009

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 · ‎08-13-2009

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 · ‎08-14-2009

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 · ‎08-14-2009

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.

Joe Clarke · ‎08-16-2009

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.

s.leyer · ‎08-24-2009

The patch resolved the issue. Thanks !