Community

Not prompted for NT Authorization credentials from Host

Links used in this discussion

Jenni Armstrong, User (Posts: 14)

Mar 21, 2020 1:23:19 pm EDT

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.

Steve Myers, User (Posts: 2)

Mar 21, 2020 1:40:46 pm EDT

Support level: Free or trial

This is happening to us as well. Windows 10 Pro 1903 is what the viewer is on. From what I can tell instead of prompting for credentials it is using the credentials of the current logged in user.

Pauline, Support (Posts: 2869)

Mar 23, 2020 2:54:12 pm EDT

Hello everyone,

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:

Not prompted for NT Authorization credentials from Host - 23 Mar 2020 02:45:34

If there is an online Microsoft account used, then could you please try switching it to a local account and see if this helps to resolve the issue? Here's a related guide on switching accounts on the Microsoft website.

In addition, we will be extensively testing this to see what can be done in order to resolve the issue.

Please let us know if the solution above helped to resolve the issue.

Steve Myers, User (Posts: 2)

Mar 23, 2020 3:05:19 pm EDT

Support level: Free or trial

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.

Jenni Armstrong, User (Posts: 14)

Mar 23, 2020 3:09:22 pm EDT

Support level: Free or trial

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.

Jenni Armstrong, User (Posts: 14)

Mar 23, 2020 3:36:37 pm EDT

Support level: Free or trial

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.

Jenni Armstrong, User (Posts: 14)

Mar 23, 2020 3:44:37 pm EDT

Support level: Free or trial

Also, your authentication tabs are all mislabled "authorization", which is the wrong word.

Authorization means you allowed to do something. Authentication is proving you're the/an authorized person.

And end users waste a lot of time telling me "i don't have 'authentication' in properties" and it's pissin' me off :)

Conrad Sallian, Support (Posts: 3049)

Mar 23, 2020 4:40:18 pm EDT

Hi Jenni,

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.

Jenni Armstrong, User (Posts: 14)

Mar 23, 2020 6:26:00 pm EDT

Support level: Free or trial

'tis a minor issue of little import. :)

You guys have a pretty good product. It's weird, but it works and is innovative in it's handling of things like multiple monitors. I'm very happy with it as an alternative to others!

Thanks for working on this issue. We've been able to work around things, but it'd be nice to not have to use single-password for so many users.

Pauline, Support (Posts: 2869)

Mar 24, 2020 9:12:53 am EDT

Hello everyone,

Thank you for your patience.

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.

Please let us know if the issue persists.

Submit a reply

^* Website time zone: America/New_York (UTC -5)