I don't know too much about the Radmin security mechanism, but it seems that Radmin security is _only_ a mechanism to allow you to authenticate a connection to Radmin Server on the remote machine. I don't think there's any functional authorisation involved once you're authenticated.
So I think that using Radmin Windows security simply allows you to authenticate your machine access using a Windows user on the remote machine. Once you have (for example) a Radmin in Full Control session then the user rights on that remote machine have no bearing on what you are authorised to do in within the Radmin session.
Furthermore, as you have discovered, the Radmin session simply gives you a view of the current desktop; effectively sharing a session with any currently logged on user. It does not give you a separate session on the remote machine.
So in your scenario it sounds like you need to carefully manage your access. You would have one user connecting at a time and have them log off afterwards. That way another user can connect (regardless of whether Radmin Server is configured with Radmin security or Windows security) and then log on to the PC with their own Windows credentials.
There have been a few threads an here recently about limiting the number of concurrent Radmin users ... but I think it's "watch this space" on that one ... see this thread ...
Eugene Idzikovsky wrote:
Probably feature of limiting connections amount won't be implemented.
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.
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!
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.
Have a look at this thread ...
... I don't know if that change would be in the next release ... ?
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 I understand it, you've set up the internet-facing (or at least Radmin viewer-facing) router to port forward to the internal router's WAN IP, and the internal router to port forward to the machine running Radmin Server. Is that correct?
I've never had to configure two routers like that but that's the only way I would think to do it.
In light of some of the recent login discussions here is one alternative; connect securely without having to enter a user name and password into Radmin Viewer. This does not involve saving user names and passwords but it does rely on your Windows logon credentials.
The bottom line is that the same Windows accounts and credentials (user names and passwords) need to exist on both machines and you need to connect using Windows authentication. Here it is step-by-step:
1) On the remote PC (running Radmin Server) configure Radmin Server to use Windows Authentication.
2) On the remote PC set up a user account with the same user name and password as the one you will use on the local PC (running Radmin Viewer).
3) On the remote PC add that user under Radmin Server permissions.
4) On the local PC open the Viewer properties for your connection. Under General / Windows Security make sure that "Do not use current user in windows authentication" is not checked.
5) You should now be able to connect directly without re-entering your Windows credentials.
6) If you want to connect directly to a PC using a shortcut you can use something like this as your shortcut target:
... where 18.104.22.168 is the IP you'd normally use. See the Radmin Viewer help file for the full command-line syntax.
So if you choose you can connect to another PC securely with a single click. Note that this is not auto logon by saving your user name and password. It simply configures Radmin to use the Windows credentials that you've already supplied.
For those living in impenetrable bunkers I'm guessing it should work with Windows users set up without passwords
I think you're quite right with regard to a change in the handshake mechanism. And as you've probably seen this is topical on a few threads.
The only kind of support I'm involved in on a professional basis is generally more application than PC orientated. Although I seed the requirement for something like the registry facilties described above, that (as a specific example) wouldn't be highest on my 'to do' list for Radmin. What really annoys me is that I've never seen any kind of Radmin technical roadmap. You see lots of good, sensible suggestions on here and occassionally you'll get a nod of 'that will be in at the next release'. But we don't know when the next release is, what's in it, and what's planned to be in the release after that. So everyone gets het up because in development terms nothing seems to be being done. I'm sure it is; it's just not visible enough to the people who pay to use the product.
There are several, really useful but simple things that would improve usability (like auto-hide toolbar and minimise from full-screen), then other harder but essential things (like the connectivity/handshake mechanism). For me these sorts of things need to come before things like a registry editor which is if you like an "add-on application" to a remote access application. The former are things which are integral to things to the access tool itself. But either way - the users have no idea what's planned for Radmin.
I think it would be really helpful if these lists were maintained publically on this website and some sort of roadmap produced with intended release dates and also any reasons why certain ideas are rejected. As it is there is just post after post of the same suggestions and the same gripes that nothing is happening.
Give the users some confidence in the evolution of Radmin, a fundamentally a good product; not the feeling that it's standing still.
I had a bit of a mare installing it but I think that was a problem at my end. The install hung and I had to manually uninstall the network driver and hack out the registry entries before it would let me reinstall. It's okay now. But I haven't heard any horror stories about it on here so I do think it was just a glitch at this end. I installed it on a second machine and it went on fine.
Configuration is fairly straightforward. Is it any easier than setting up a port forward? No, not for me, but then I know what I'm doing with my router. But at least if you go down the hamachi route then as the support person there is only one set of instructions to work with.
The current licensing is free for non-commercial use. The link from the pinned post on the Troubleshooting forum isn't to the latest version. It's to an earlier one which I think was on a different license - so I'm not sure if the "old" link is deliberate.
However hamachi performs very poorly over my (admittedly very naff 0.5 Mb) broadband connection. Considering I've effectively only got half of that because both of the hamachi test machines are this side of the router it's hardly surprising. However at least TeamViewer VPN worked after a fashion - hamachi continually drops the connection.
Radmin aside I actually really like hamachi as a product. You can set up your own multiple VLANs and you have a lot of control over access, network groups and configuration. So I'm definitely going to hang on to it just for the VPN.
One neat feature of hamachi relating to earlier posts on this thread is that you can turn off encryption on a per VLAN basis. I tried doing this and although I think performance was improved, it still wasn't enough to allow hamachi to maintain the connection.
So as a VPN for Radmin use then TeamViewer VPN (also free for non-commercial) has the edge for me, but that's only because of my naff connection.
But as a product hamachi wins easily from what I've seen, and for most people I'm sure it's just fine for Radmin use. But as you say, it's one more potentially unnecessary thing to have to worry about.
Bottom line then - I'd still like to see a lightweight VPN built into Radmin!
If you search the forums this is one of the big complaints - the inability of Radmin to lock out the remote user and black out the screen. Particularly since this is offered by many of Radmin's competitors! I really think it would be in famatech's best interests to get this one sorted!