Suggestion for useful UAC- and remote setup handling

Hello Uwe

First of all, thank you for the positive feedback. We're happy that you like RDM and Wayk Now, even if you are not currently able to use it in production.

You are not the first person to request this feature, and it is already on our radar (see https://forum.devolutions.net/topic29752-someway-to-handle-uac-better.aspx).

To give you a better idea of where we sit with this feature, we need three separate enhancements to the product:

1 - Our protocol and client already support "remote execution" (where you can run processes and scripts on the remote system). We need to improve this to allow delegation of credentials; this would enable the equivalent of `runas`.

2 - Our remote execution feature also now supports downloading, validation and execution of binaries as of the 3.2 release. This needs further improvement to query and publish Wayk Now URLs.

3 - Client improvements to support reconnection to the newly installed elevated instance.

The first piece is the most complicated, but once implemented, that actually gets us most of the way there. There is significant utility in being able to execute processes and scripts under specific credentials on the remote machine in a secure fashion. It could even be possible to build the remaining pieces on top of that independently, with a properly crafted Powershell script to handle the remote download, installation and configuration.

At this point I can't make any promises, but we'd like to have that implemented - at least in part - in a release within the next six months. If it is only in part, it will be the first section mentioned above (i.e. the ability to remotely execute in the context of a specific user).

As always, please let us know if you have any further questions or concerns!

Thanks,

Hi.

Is there any news on this feature? For us it's the last peace of the puzzle to get out from under Teamviewer :)
We need to be able to run apps on remote computer as administrator when doing a remote session, and the handle UAC prompts.
Thank you.

Hello

Can I ask specifically what your need is? Is it just as you wrote ("runas" administrator on the remote session with no UAC prompts), or do you also need the ability to remotely upgrade the portable WaykNow.exe to the full-fledged, unattended install?

If it's the first case, I have some good news: for Windows servers installed via the .msi, we've added support for elevated remote execution; meaning you can specify credentials alongside the command or script to run and it will be run "as" that user. If you supply administrator credentials, the task will be elevated without a UAC prompt or any interaction from the logged on user. The backend work for that is done and integrated, we still have to update the client to allow you to specify the credentials. I'm afraid that won't be in the 2020.2.1 release but should be in the subsequent one - I'll post back here with an update for you.

Thanks and kind regards,

Hi.

That sound great.

I think it's the first one, We don't need unattended install I think.

We need to be able to have a remote user run the WaykNow.exe, then we enter the session and can use "Run as Administrator" and enter credentials in UAC Prompts if they appear. The remote user don't have admin rights, only we do.

At this point in Teamviewer, we enter "Local admin" credentials when we start the session instead of the Teamviewer password to be able to see UAC Prompts, this is absolutely fine, so if WaykNow could let us interact with the UAC Prompts in the same way, that would be perfect.

Does that make sense? :)

Do you have a lite ETA on when this would be implemented?

Hello

Ok - so the ability to "remote execute" scripts and commands on the remote machine as another (and optionally, elevated) user is coming soon - but this feature itself depends on Wayk Now being installed for unattended access via the .msi. Why? Because to elevate without user intervention, we need SYSTEM privileges.

However, I appreciate what you and the OP are asking for is a little different: your remote users don't have admin rights, so they can't install the .msi. Since the users don't have admin credentials, you can't do anything that triggers a UAC prompt asking for those credentials.

We're going to add what the OP asked for (and, what should resolve your issue as well):

• You connect to the remote machine, where the user is running the standalone WaykNow.exe as a regular user
• You'll be able to initiate an install of the unattended .msi, securely providing your administrator credentials
• On the remote machine, we'll run the install under your credentials and prompt for elevation: this is key, the remote user will see a UAC prompt but it will be the "Yes / No" prompt, *not* asking them for credentials
• Assuming they click "Yes", the install will run and at this time, your Wayk session will be disconnected
• Once the install completes on the remote machine, Wayk Now will reopen and you will have to reconnect
• You will now be able to interact with the remote machine at the highest level: UAC prompts will be visible and controllable, Ctrl+Alt+Delete will work, etc

We have that in prototype stage now and it should be completed for the next release. For a loose timeline, we Wayk Now releases are normally every 6-8 weeks but we don't have a fixed cadence so it may be sooner. I'd say you can expect this before the end of the summer, but I'll post back here with some firmer details.

Let me know what you think. Thanks and kind regards,

That sounds great!!!, I'll be looking very much forward to that.
Do you think there would be a way to uninstall the .msi automatically after we close the session ?
I see a bit of a GDPR issue (I'm in Europe). If I understand you correct, we will effectively be able to reconnect again at any time, without user interaction with the program installed?
Thank you.

How would this work in a terminal server/citrix environment ?

Hello

Yes - upgrading to an unattended installation leaves the machine accessible without user interaction (as the program is now "installed").

We can offer a corresponding "Uninstall" function, but it won't be automatic on session termination.

Remember that to either remotely trigger an install or uninstall, you will need to provide administrative credentials for the remote machine and the user will have to accept the UAC prompt. The implication is that you already have the rights necessary to administer the machine (even thought the remote user does not).

Thanks and kind regards,

Hello

Yes - upgrading to an unattended installation leaves the machine accessible without user interaction (as the program is now "installed").

as the person above noted tho, as with GDPR and fun, it might be helpful to be able to just uncheck SRD if not wanted, so you can run PFP only.

That sounds great!!!, I'll be looking very much forward to that.
Do you think there would be a way to uninstall the .msi automatically after we close the session ?
I see a bit of a GDPR issue (I'm in Europe). If I understand you correct, we will effectively be able to reconnect again at any time, without user interaction with the program installed?
Thank you.

With SRD, you can connect at any time without additional user consent, but the fact remains that consent was initially given. As long as this is clear with your users, this should not be a problem. One possible improvement for SRD would be to add an option to require explicit user consent at all times, even with admin credentials for the target machine. We don't have an ETA for this improvement, but we'll consider doing it in the coming months.

Otherwise, if you wish to enforce explicit user consent at all times, the best would be to disable SRD and use Prompt for Permission (PFP). With PFP, the only way to connect is with explicit user consent.

The important part is that the user knows what he is consenting to. In this case, you are an administrator of the target machine for the given user, so I suspect there is already a kind of (verbal or written) agreement in place where a lot of control has been given to you.

Best regards,

Otherwise, if you wish to enforce explicit user consent at all times, the best would be to disable SRD and use Prompt for Permission (PFP). With PFP, the only way to connect is with explicit user consent.

Alright, you got me there My1, I forgot that we currently cannot disable SRD for unattended access. Forget that part from my previous answer, the recommendation is to simply use PFP if you require explicit user consent at all times, and not use SRD even if you could be using it. The ideal solution would be to add an option to always require user consent regardless of the authentication type instead of disabling SRD altogether. We'll put that on our to do list, we just don't have an ETA for this improvement.

I forgot that we currently cannot disable SRD for unattended access

In fact you cannot switch SRD at all.
when wayk is installed with service, you get SRD, if not, you dont.


well not using SRD is fun and all but especially when you dont nesecarily control (as in a higher administrative level) the computers's Admin Accounts might not be overly well secured, leaving them as a relatively easy entrypoint, especially on the computers of many (usually older) individuals, where seeing things like 1234 as the password is not uncommon and frankly to be expected as no one expects that password to be usable for remote access as that usually isnt the case either due to RDP not even existing in Home and iirc being off by default in Pro (and even if it were on, you need port forwardings to get into RDP).

just a relatively quick way to turn off SRD (which fun fact is even outlined in the documentation, but doesnt work) would be probably the simplest method for all parties involved.
requiring consent on top of SRD is probably extra coding and bonus confusion, while just "no SRD here" is straightforward and (hopefully) not too hard to code in.
https://helpwayk.devolutions.net/kb_configcommandline.html

The ideal solution would be to add an option to always require user consent regardless of the authentication type instead of disabling SRD altogether

may I ask why that may be the case? I mean why not just straight use PFP in the first place and disable SRD instead of such a seemingly hacky workaround solution?

The decision to make SRD mandatory for unattended access was driven by the fact that SRD is the *only* way you can connect at all times, including when no user is currently logged in. Think about it the other way around: we sell a product that promises unattended access, and the first thing you would do is disable true unattended access, making only attended access possible. PFP and SRP are *not* available at the Winlogon screen, they are only available when a user is currently logged in to the system.

Now I understand that in your case specifically, you may want to permanently disable unattended access and use Wayk Now only for attended access, with explicit user consent at all times. SRD + explicit user consent is still better than PFP alone, in the sense that one has to present valid credentials for the target system first, even if as you say, those credentials are extremely weak.

We can consider making it possible to disable SRD for unattended access, but you have to understand that this really goes against the nature of unattended access itself. Making it mandatory by default was simply a way to prevent users from shooting themselves in the foot by effectively disabling true unattended access.

Best regards,

well with disabling SRD disabling unattended was kinda what I meant. the dilemma is currently:

service = forced unattended
no service = no UAC access

one thing that could be done tho would be to add a quick info to the (grey) SRD to note that unattended is on, have an unattended access checkmark somewhere in the globals, and then if that is off, make SRD able to be turned off.

on the other hand with setting up a globally set custom password(s) for unattended (but please hashed or at least not world-readable), SRP with unattended could even be done (in theory at least, some others do precisely that), also has the extra bonus of being very direct with this is specifically for unattended access, giving the user a bit more of a nudge to actually choose a decent password, while being able to take windows Accounts out of the loop.

I created a ticket to make it possible to disable SRD with the unattended service. Consider this matter closed.

Hello

Wayk Now 2020.2.4 is now available, and contains some initial support for this use case.

If you connect to a standalone WaykNow.exe, the "Actions" menu will contain a "Install Unattended Access" option. If you select it, and accept the following prompt, you'll be asked for administrative credentials for the remote machine. Next, the remote user will be asked for confirmation, and then need to accept a UAC prompt - but, critically, this is a "Yes" / "No" UAC prompt, not one asking for administrative credentials (which you have already securely supplied).

Once all that is confirmed, it will take a few moments to download the latest .msi and kick off a passive installation. Once the installation is complete, Wayk Now will relaunch as an unattended installation and you will be able to reconnect (reconnection is not automatic, but the 6-digit Wayk ID should be preserved from the standalone install). There is no automated uninstall; once you are finished, you can choose "Uninstall Unattended Access" from the "Actions" menu or just trigger the uninstall via Programs and Features (since the installation is unattended, you will be able to interact fully with UAC prompts and privileged applications).

This feature is predicated on the following:

• Windows to Windows only, for now
• Both machines need to have the latest version
• The client needs an enterprise license (the functionality is built on top of remote execution, which requires a license)

Please let me know if you have any questions or feedback,

Hello again

To specifically follow up on some of My1's comments: it's not documented yet, but we've added wider support for configuring Wayk Now at install-time. The following password options are available on the MSI:

AllowPersonalPassword
AllowSystemAuth
AllowNoPassword
PersonalPasswordType
PersonalPassword

So, for example; you could bootstrap an installation allowing ONLY SRP with a custom password something like this:

msiexec /i WaykNow-x64-2020.2.4.0.msi /passive CONFIG_ALLOW_NO_PASSWORD="false" CONFIG_ALLOW_SYSTEM_AUTH="false" CONFIG_ALLOW_PERSONAL_PASSWORD="true" CONFIG_PERSONAL_PASSWORD_TYPE="1" CONFIG_PERSONAL_PASSWORD="MyStrongPassword123!"

Please let me know if you have any questions about that.

Thanks and kind regards,