Unable to get multiOTP CP to activate 'User does not exist'

edited July 2018 in General
Hi all, I have a weird issue that I have spent the better part of a day going over debug logs and code to find the cause but am getting nowhere.

Environment:
Dedicated linux (CentOS 7) server for multiOTP with Apache and Freeradius LDAP Sync with AD working - Tests fine from command line/Web GUI, working fine from the radius side with our Cisco ASA VPN.

Now I am trying to enable some servers with multiOTP CP for RDP but it refuses find the user.

If I use just the username/password/OTP combo, it does not even connect to the OTP server.

If I use domain\username, password, OTP it connects but returns "User doesn't exist", yet the logs seem to indicate otherwise:
2018-07-24 08:52:27 debug Server-Client Info: *CheckUserExists server request for username with challenge MOSH...........................
2018-07-24 08:52:27 debug Server-Client Info: *CheckUserExists intermediate error code: 22
2018-07-24 08:52:27 debug Debug Info: Host answer is correctly formatted.
2018-07-24 08:52:27 debug Server-Client Info: *ReadUserData server request for username

When XML Debugging is turned on, I get:

ErrorCode 19 /ErrorCode;
ErrorDescription INFO: Requested operation successfully done /ErrorDescription

So there seems to be no error, but for some reason it insists the user doesn't exist.

one thing to note - The XML response is identical (other than password) regardless of the OTP being correct or random.

Comments

  • Well bugger me, I just worked it out!! No mention of this anywhere in the documentation that I could find but the server secret does not seem to be able to support special characters. Either that or I needed to quote the command when setting the secret.
    I had a password with uppercase, lowercase, a number and a '!' on the end. As a last ditch effort, I tried it with just a long password with upper and lower case and it worked fine!!!
    The deceptive part there is that looking over the source code, if the decoded response contained 'MOSH' at the start, apparently the secret matched (or did I get that wrong)?
  • Hello, no, you are (hopefully!) wrong. The 4 first characters must be 'MOSH' to start the decoding process, but you need of course the same shared password on the other side in order to decode the content. Concerning the "!" character at the end, we were unable to reproduce the problem. We put the secret "testcache!" on both side and it worked like a charm. Regards,
This discussion has been closed.