Conrad Sallian's community posts

Hello,

I've moved the message to a new topic.
In order to check the availability of Host on machines in a local network, use the Scan for RUT-hosts command.

Allen Pelusso wrote:
Same for me too Adnroid ver 2.3.3 and open and black screen and go off few second after !

Hello Allen,

Let's wait till we update the mobile version with logging so that we could diagnose such issues.Meanwhile, please also check your device against the system requirements (information block on the right)  and specifically if the device supports NEON.

Mind you I only tried ticking various buttons yesterday because neither host were working. I only changed settings in one of them though, which is lucky as the other one suddenly works fine today. So I presume there was a problem yesterday that magically fixed itself overnight [restarts of all machines and networks maybe?].

Yes, sometimes users accidentally enable or disable an option that affects remote connection and can even block it altogether.

In any case I am now happy

So are we :)

Hello Torsten,

Another logmein refugee here Starting with 3 hosts, but will be building to over 10 eventually.
So glad logmein pushed me away, as Remote Utilities has so many more features I wanted.

Welcome to our refugee camp. Everyone gets a blanket and a bowl of hot soup. For free. :)

he connection only goes as far as Manual Log-on 'locked'. I presume this is because the host has windows accounts on it, but I don't understand how to enter any info that gets around that.

Locked sign here means that the remote computer is visible (say, you can ping it's IP address), but you are not logged on. By being "logged on" I mean logged on using the LogOn feature in Remote Utilities, not Windows logon.

As I could not connect via the various connection modes, I played around with RDP settings in the configure screen

RDP has nothing to do with Remote Utilities per se. It's just that we support RDP connection by launching a default client when the user wants to connect via RDP. Also, a feature called "RDP-over-ID" is also possible, when you connect using RDP via an "Internet ID tunnel" created by Remote Utilities.  

To me this feels it should be the other way instead. Why would I need to check identity of the Host, I already connect to it with an IP or ID so I don't see the benefits of it (but I might miss something here).

This is to avoid situation when a different Host (patched by a hacker) is planted on a computer with the only purpose to find out your password when you try to connect to Host.

Instead if the Host would require the Viewer to know the shared secret, it would add an extra layer of security and I think that is the way what most people would expect it to work in.

That's what authorization is for. Authorization and identity check are two different things. Shared secret is not for making the connection more secure. It's for the Viewer to know that it is connecting to the Host it (the Viewer) thinks it is connecting to.

What is the recommended setup to make a connection as secure as possible? Is it a long password and only allow certain ip addresses then?

Long password and incoming IP filter (white list) is enough for good security. To ensure security on the Viewer side, never use the "save password" option.

Hope that helps.

L B wrote:
Hi,

How is the "shared secret" feature supposed to work? Right now I set it on a host but I can still connect to the host with only the password entered in the viewer machine. Using Internet ID to connect, Windows 8 host, Windows 8.1 viewer.

Any input please?

Hello,

The purpose of shared secret is not to replace authorization. It's for checking the identity of the Host. That is, if you have shared secret enabled on your Host, but don't have it enabled in your Viewer (or rather a specific connection on your Viewer), you'll still be able to connect. But not the other way around - that is, if you have a shared secret field populated in your connection properties on the Viewer, but the Host has an empty field (or a different shared secret for that matter), you won't be able to connect.

So the identity check starts at the Viewer side. If the shared secret field in the connection properties in the Viewer is disabled, then no identity check takes place at all, regardless of the Host's shared secret field value. Because the program rightfully suggests that if you didn't enter anything in the connection properties shared secret field, you do not need identity check, and hence there's no reason for not allowing remote connection. But IF there is at least any value in the shared secret field in the connection properties in the Viewer, then the program MUST check it against Host's shared secret value.  

Hello Tom,

Thank you for the kind words!

Indeed, this is the first time we have been reported such an issue. A couple of questions:

1. Can you switch back to Full Control mode in the same window, without closing it? There is a toggle icon on the toolbar at the top in the Full Control mode (the first icon).

2. What is the operating system on both ends?

L B wrote:
I cannot find a way to add a recognizable to the systems in the iOS app. All i can get is a list of Internet ID's. i will never know what system I'm connecting to without creating my own checklist of system names/Internet ID. the Viewer has the ability to record recognizable system names to each host computer. Need this in the iOS app too.

Yes, we plan to make the "address book" on Viewer mobile more feature-rich and powerful. We'll add names  in one of the future updates.

Hi Mirko,

Ctrl + Alt + Del will definitely be implemented. As for auto-lock, it's also a good idea, but we'll see if it's possible to include it in the nearest release.

Yes, that might work too. Thanks for the recommendation, Philip.