We are not using RUServer. These are simple win10 machines. Out of 13 identically configured workstations, 5 end users had to be set to single password auth. With ALL of those cases, my workstations at home get the windows auth window.
With all of these users, the Viewer would attempt to connect, and on the 2nd or 3rd attempt, the user/pass/domain dialog appears and then disappears. After 5 failed attempts the viewer fails and reports access denied, bad credentials.
This occurs when auth is set to "auto" or "windows security".
Initially it appeared these were win10home users, but i've seen at least two using win10pro. Most likely these users have not updated their home machines, because that's how people are, but i don't know that for a fact.
I'm sorry i don't have any further details to assist.
This is to inform you that we're currently considering that the issue might be occurring if there is an online Microsoft account associated with the Windows user on the Viewer machine instead of a local user account.
Could you please let us know if there is an online Microsoft account used on the Viewer machine where the issue occurs instead of a local account? This can be seen in Settings -> Accounts -> Your info:
Yes you are correct, I am using a online account which is the defacto standard for windows at this point. I am not willing to change to a local account. So please come up with a bug fix as soon as feasible. Thank you.
I have a user with two windows machines, both using the same online account to login. One of them works normally, as expected with windows security, the other exhibits the behavior being discussed in this thread.
Try again, folks, Microsoft account isn't the problem.
Interestingly, the computer that connects with windows security is using a ms online account running windows on MacBootCamp on a Macbook. The one that fails is a regular windows machine & an ms online account.
You are absolutely right - the correct way to say is "authentication method" (when referring to "single password", "ru security" etc.) , while authorization actually refers to what a specific user is allowed to do (permissions volume). This was the initial intent for the current tab name though, to show that different rights and permissions are set for different, well, authentication methods.
We will do our best to correct this mistake and update the program and the documentation as soon as possible. Sorry for any inconvenience.
This is to inform you that we've managed to reproduce the issue and implement a fix for it. We've sent a link for the download of the test version of the Viewer with the implemented fix to your emails.
Please try replacing the original Viewer executable file rutview.exe in the Viewer installation folder C:\Program Files (x86)\Remote Utilities - Viewer with the new test version executable. We recommend that you rename the original rutview.exe, for example, rutview_old.exe and copy the new test version of rutview.exe to the same folder.