"The server's authentication policy does not allow connection requests using saved credentials"
Is there a way to let RoyalTS fill in the credentials on the challenge after a few seconds to work around this? Like an auto-reconnect on connection loss? My team has to deal with almost 150 servers, and we're annoyed like heck about this near useless policy. I have automated away our problem with the high rotation rate of the servers by using dynamic folders and linking them to just 9 password groups, but this one problem eludes me...
I argue that the workaround does no harm because a simple PowerShell script is able to do work around this by waiting 4 seconds, as well as the RoyalTS on the MAC and some other products as well...
So why can't this be a setting in RoyalTS, and give us users the choice to ignore this SERVER SIDE policy and (re)connect after a few seconds?
Or what about giving us the option to use a key sequence task to fill in the challenge popup IF ith happens? II now use a Legato Streamdeck to fix this, but there has to be a better way in RoyalTS to do this!
may I kindly ask why you have this policy in place if it is such a huge problem for your environment. I would argue that the security implications of sending the credentials to the server in a "controlled" environment are less than risking typing passwords through keyboard input simulation into an arbitrary window - especially when it's so easy to mistakenly switch the focus to another app or web site. The damage you can make is much bigger. That is one of the reasons we are hesitant to implement this. Another reason is that dealing with multiple popups makes it difficult or even impossible to identify the correct popup. This could lead to other unpleasant side effects.
So that's a no?
I'm happy to discuss these issues but I really want to know the exact use case and how to setup an environment to ensure it works as good as it can. I'm still curious why admins/companies enable such security policies with the whole purpose to use a client or products to circumvent it. It just doesn't make any sense to me...
I really think that in most of these cases, an overzealous admin put the requirement in place, and declared it a NIST 87443 (made up #) policy, and none of us take time to challenge it. I'm in the process of challenging all these crazy policies where I am. Currently where I am, admin creds need to be at least 15 characters, (UPPER, lower, number, special, nothing found in a dictionary and nothing that has been used in last 40 changes. No saved creds to log into server, and servers and workstations log you out after 5 minutes of inactivity. And they wonder why the team aren't better multi-taskers. Royal really shouldn't even entertain this on their message boards. You guys provide a safe, highly secure program. Circumventing a company's security polices (even if there are stupid polices) is probably not a business you want to be in.
It depends on what you consider more / less secure, as every nerd that has to work with (arguably stupid) security policies looks for a way to lessen the negative impact those security policies have on his/her life.
If you ask my opinion on the matter; using passwords is the problem, there are much better alternatives to that for login security like MFA making the whole point mute.
As for the argument that RTS password entry will lessen the security, I disagree because your workstation should be locked if you leave it preferably with Bluetooth phone auto-lock if you walk away from it. The policy is meant to secure against stupid people that save RDP files on shared desktops and exposing servers that way.
I have RTS setup with a dynamic (shared) server list for the whole team with the passwords coming from a (private) KeePass DB per nerd and with a decent password rotation scheme for RDP, so I don't see the problem of re-inputting a password that is accessible in RTS anyway. Using RTS defeats keyboard loggers, and we can use really long and/or complex passwords.
Feel free to change my mind / convince me that this way of working is not secure.
You could even make this functionality a policy in RTS which is disabled by default, and keep the security guys happy.