Also would be good to have an option to connect virtual accounts with Windows accounts so authentication is seamless and automated.
Hi,
the authentication via keypairs is a good idea. Though at least on the server side there is no need to store any password, since Royal Server relys on Windows Security for authentication of the clients. One idea we had though was that the username/password provided by Royal TS/X is checked and mapped onto another (real) Windows account on the server side. This way, the user never sees the password use for any actions on the server side. This might be the same idea you had?
Regarding the keyword: the underlying protocol is SSH and I guess that this should have enough security built in.
cheers,
Michi
hoipolloi
Instead of users authenticating to RS with passwords, it would be better to allow users and/or the server admin to configure (and require use of) public/private keypairs. This removes the need for both server and client (2 separate security surface areas) to have the password stored; in a key-based configuration, only the client needs to keep the private key.
Further. it would be nice if a keyword could be set on client+server for connection obfuscation, an additional layer of security.
Since RS uses Windows accounts for authentication, there is currently no straightforward way to do this. The obvious solution is implementation of virtual accounts (in a RS database) which could be used to authenticate to RS; then users could optionally use Windows accounts to login to the underlying server via RDP, etc.