Community

"Custom Server Security Authorization Error" issue

Page:
Links used in this discussion

Aaron Levinson, User (Posts: 5)

Nov 22, 2019 12:44:30 am EST

Support level: Free or trial
I have the latest software (as of 11/21/2019) installed on several systems.  RU Server on one system, RU Host on three systems (including the system running the RU Server itself), and the viewer installed on a few systems as well.  I have Custom Server Security enabled on the RU Server and on the hosts as well, and this is the only authorization protocol enabled on the hosts.

I have no problem logging into two of the hosts, but for one of them, no matter what I do, I always get the "Custom Server Security Authorization Error" message.  The main difference between the three hosts is that, for the two that I can login to, they are on the same network as the RU Server and use an Intranet IP address to connect to it for authorization purposes and Internet ID purposes.  For the host for which I get the error, it connects to the RU Server across the Internet and uses its public-facing IP address for both authorization and Internet ID.

I can connect to the problematic host without any issue if I use the Windows user authentication protocol, and I assume that it would work with the single password and RU user auths, although I haven't tried those specifically.  So, the issue appears to be specific to the custom server authentication protocol.

I even tried running the viewer from the host itself, connecting by either IP address or Internet ID, but I got the error in all cases.

I examined the viewer and host log files, but there is nothing that is obvious in there, to me, that points to the cause of the problem.  For the host log file, nothing is added when the error occurs.

This seems like a bug to me, and I setup all the hosts the same way except for using the public IP address instead of the internal IP address.  In addition, it is clearly able to access the RU server for custom server security authentication purposes over the public Internet, because otherwise, I would not have been able to add users and groups to the host in the first place.  I following the instructions at https://www.remoteutilities.com/support/docs/setting-up-auth-server/ for setting all of this up.

Thanks!

Polina Krasnoborceva, Support (Posts: 961)

Nov 22, 2019 1:54:45 pm EST

Hello Aaron,

Thank you for your message.

Could you please double-check that your self-hosted Server is accessible fr om the outside. To do so, please do the following:
1. On the Server machine open a web browser and navigate to http://canyouseeme.org
2. Enter the RU Server's communication port number (the default communication port is TCP 5655) in the Port to Check field and click Check port.
3. In case if the form returns Success as the check result, please send us your Host logs from the remote Host machine wh ere the issue occurs, as well as the Viewer logs and the Server logs. You can send them to support@remote-utilities.com.

In case, if you receive Error as the check result, please try referring to this troubleshooting guide and see if it helps to resolve the issue.

Looking forward to your reply.

Aaron Levinson, User (Posts: 5)

Nov 25, 2019 12:45:38 pm EST

Support level: Free or trial
I already know that my RU server is accessible from the public Internet, and I don't need to use canyouseeme.org to check.  I thought this would have been clear from my first post on this topic, since I described successfully connecting a remote host to the server over the public Internet, but I also successfully connected to it from a system running the RU viewer application on the public Internet a few days ago.  I had no problem logging into it using the custom server security protocol from the viewer, and I also had no problem connecting to hosts that are connected to the server via either the intranet and the Internet.

Conrad Sallian, Administrator (Posts: 2556)

Nov 25, 2019 1:09:08 pm EST

Hello Aaron,

Could you please check if you have either "Auto" or "Custom server security" (in fact I recommend you try both as part of the testing/troubleshooting process) value in the field below in connection properties for the Host in question:



Looking forward to your reply.

Like Remote Utilities? Write a review

Aaron Levinson, User (Posts: 5)

Nov 25, 2019 1:14:31 pm EST

Support level: Free or trial
I already tried both :-) .  It didn't make a difference.  I think I had read on another post that "auto" chooses custom server security first if that protocol is enabled on the host.  I tried a bunch of things to isolate the issue when I investigated it, and the only thing that I identified that was different about the setup is that the host in question connects to the RU server via the Internet, as opposed to the intranet.  But, that doesn't mean that's the cause of the issue.

Conrad Sallian, Administrator (Posts: 2556)

Nov 25, 2019 1:32:51 pm EST

Hi Aaron,

I think I had read on another post that "auto" chooses custom server security first if that protocol is enabled on the host.

Yes, correct. We also explain that in our documentation, on this page (see the yellow-highlighted area).

and the only thing that I identified that was different about the setup is that the host in question connects to the RU server via the Internet, as opposed to the intranet. But, that doesn't mean that's the cause of the issue.

I can't but agree that this is not necessarily the root cause. Otherwise, we would see multiple complaints here on the forum that the CSS authorization doesn't work when used over the Internet (and this is a very common scenario).

There is one more thing that you can try - change the communication port the server uses or simple add new one and use it with the Host in question (don't forget to also change it on the Host side in the corresponding Viewer connection props).

Like Remote Utilities? Write a review

Aaron Levinson, User (Posts: 5)

Nov 25, 2019 1:52:54 pm EST

Support level: Free or trial
I can't change the port, as there are multiple hosts, besides the three that I mentioned, that will stop being able to communicate with the server if I do that.  Also, getting someone in IT to enable port forwarding for an additional port is not realistic at this point.  Regardless, it's unclear to me why using a different port number would make a difference anyway.  The host for which the problem occurs can communicate just fine with the RU server over the existing port.  I can connect to this host just fine if I use any other authentication protocol besides CSS.  The host clearly can establish some communication with the server using CSS, because otherwise, I wouldn't have been able to add users/groups to it under the host's CSS settings.  In addition, if I run the viewer on the same system running the host, I can successfully login to the RU server using CSS over the public Internet.  So, the issue appears to be specific to the communication between viewer and host, via the RU server, during the authentication phase, but only when CSS is used.
Edited:Aaron Levinson - Nov 25, 2019 1:55:16 pm EST

Conrad Sallian, Administrator (Posts: 2556)

Nov 25, 2019 2:10:30 pm EST

Hello,

I can't change the port, as there are multiple hosts, besides the three that I mentioned, that will stop being able to communicate with the server if I do that.

In the Communication tab you can add a new port, no need to replace or remove existing ports.

Also, getting someone in IT to enable port forwarding for an additional port is not realistic at this point.

You can try 443.

Still, I recommend that you try at least that and see if you can get any results. Meanwhile, we'll be testing it here as well and see if we can reproduce the issue or at least come up with more ideas about why it is happening in your case.

Like Remote Utilities? Write a review

Aaron Levinson, User (Posts: 5)

Nov 26, 2019 5:06:38 pm EST

Support level: Free or trial
I have a few updates.  I haven't been able to change or add a port number, and 443 won't work.  Regardless, I took another look at the logging on the system that is running the host that gets the error, and I see that there is an error in the log file:
  • a) Error code:  35
  • b) IP address:  127.0.0.1
  • c) Description:  Password is incorrect or error occurs.

I can tell you with certainty that all the passwords are correct.  In fact, there are no passwords to enter by this point, as I am already logged into the RU server by the time I get to this point.

Last night, I was also able to get the customer server security authorization error for some other hosts (the two that access the RU server via the intranet), but I don't believe that it was caused by the same problem.  On the RU server system, the RU Server user interface was unable to connect to the server and kept on reporting access denied, even over a named pipe connection.  Rebooting the system didn't fix anything.  I ended up deleting the HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities\MiniInternetId Registry key, which caused settings to be reverted to their defaults, and that fixed the problem with being able to connect to the RU Server from the UI (note that address book information appears to be stored elsewhere, so that wasn't lost).  But, now, the RU server had a new public and private key, which didn't match that used on the hosts.  So, I had to go to each host that uses the RU server for CSS and login again, which displayed a warning message that the keys didn't match, etc, etc.  Anyway, during this whole sequence, sometimes it would report CSS authorization error, and just updating the key wasn't enough.  I ended up deleting users and groups from the hosts, turning off CSS, turning it back on, and then adding users and groups again.  That was enough to get past the CSS error.  I also tried this on the problematic host, but it didn't help, and I continue to get the CSS error, which makes me think that it is caused by something else.

Conrad Sallian, Administrator (Posts: 2556)

Nov 27, 2019 9:42:36 am EST

Hello Aaron,

There were some fixes to RU Server very recently and we currently prepare an update. We are going to release the update in a few days.

Sorry for any inconvenience.

Like Remote Utilities? Write a review
Page:

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

This website uses cookies to improve user experience. By using this website you agree to our Terms of Service and Privacy Policy.