I'm interested in finding out if Radmin can be set up to disallow incoming connections if a user is already logged into the machine, or if a connection can be disallowed if the connection isn't coming from a user who is currently logged in locally.

This question came up because of the availability to sensitive data to prying eyes.

Furthermore, I presume the second part of your question means the refusal of a Radmin connection if there is already a user logged on locally? If that's the case I doubt if Radmin will specifically take account of that.

As an afterthought, as far as local logons go there are probably a few workarounds you could employ. For example you could have policy-driven logon/logoff script which turn the Radmin Server service off/on respectively. This would stop Radmin access while a user was logged on and restore that capability when they logged off.

That wouldn't solve all of your problems by any means, but it may help to form one part of a workable solution.

Paul B wrote:
As an afterthought, as far as local logons go there are probably a few workarounds you could employ. For example you could have policy-driven logon/logoff script which turn the Radmin Server service off/on respectively. This would stop Radmin access while a user was logged on and restore that capability when they logged off.

That wouldn't solve all of your problems by any means, but it may help to form one part of a workable solution.

That's kind of where I was headed with my question.

Another one:

With the option to have the locally logged in user click a prompt to accept an incoming connection turned on, what happens if nobody is logged into the machine to accept the incoming connection?

Paul, the problem with your idea of a logon/logoff script would be that RAdmin gives you control of the console session. This means you still would have to log into the console (assuming you're connecting for Full Control) after connecting with RAdmin, whereupon the logon script would terminate your RAdmin connection!

A better (and simpler) solution might be to configure RAdmin to use Windows Security, and assign permissions to user accounts that have rights locally on the workstation, so that only users who can sit down at that workstation and log on have permission to log on via RAdmin. (You could lock it down further as needed.)

This wouldn't address the possibility of denying an RAdmin connection when someone is already logged on, though. To do that, you could possibly do something fancy with a logon script, where the logon script altered the RAdmin server settings (via a registry patch, probably) to require the local user's permission for incoming connections and deny after the timeout. Then a logoff script could change the RAdmin server settings back to allowing incoming connections with no requirement of a local user's permission.

Ah ... I see you're yourself again now I've actually got round to posting!

You're right in that I hadn't considered that! However the logon/logoff scripts would simply have to disable/enable or pause/resume the Radmin service depending on the identity of the current user. So a user could be reserved for a "genuine" local logon only and the script would affect the Radmin service for "any other user".

And that's similar to your last paragraph. As you say, there are various variations on a theme, though without knowing precise requirements nothing I can think at the moment is especially elegant!

Probably feature of limiting connections amount won't be implemented, there is why:
Imagine that for some reason remote user login then connections aborts, but without immediate TCP/IP timeout. Or remote user just forget about his connection, then nobody will be able to connect to this Radmin server until issue resolves. Hovewer it is still the subject of discussion in Famatech.

I think it would be a good idea to implement this. It's up to the people administering the server to decide whether reducing the number of concurrent users to 1 is acceptable (for example on the basis that log on locally is available). You could also enforce a inactive session timeout after so many minutes _if_ the number of concurrent users is set to 1. So after say, 15 minutes of inactivity Radmiin Server drops the connection and Locks or Logs Off the server.

It's just a question of additional flexibility. The more flexible the product is the more people will buy it. No-one would be forced to set a connection limit of one would they - it's a decision individual users would have to take responsibility for.

And maybe this also ties in with other discussions about protecting Radmin settings to stop _any_ user with a full connection changing the settings - the idea of another permissions level like "Radmin Admin " who _is_ allowed to change settings.

I think it would be a good idea to implement this. It's up to the people administering the server to decide whether reducing the number of concurrent users to 1 is acceptable (for example on the basis that log on locally is available). You could also enforce a inactive session timeout after so many minutes _if_ the number of concurrent users is set to 1. So after say, 15 minutes of inactivity Radmiin Server drops the connection and Locks or Logs Off the server.

It's just a question of additional flexibility. The more flexible the product is the more people will buy it. No-one would be forced to set a connection limit of one would they - it's a decision individual users would have to take responsibility for.

And maybe this also ties in with other discussions about protecting Radmin settings to stop _any_ user with a full connection changing the settings - the idea of another permissions level like "Radmin Admin " who _is_ allowed to change settings.

Paul is right here. This is a feature we'd like to ensure that servers with the most sensitive and critical information aren't being worked on at the same time. You don't have to limit it by default but since this app only does console level access, it would help to give the users some ability to limit how many concurrent connections there are to whichever console at a certain time.