There are a number of ways to leverage the FRP connection for pushing files to remote QWS Endpoints. Below are a few options that have been tested for functionality, but any tool that can leverage the IP of the BicDroid Connection (and port information provided by the QWS-CSP web GUI), can be used for this purpose.
Linux Management Host
Multiple Option - PSSH and PSCP
- The source can be found here - https://github.com/ParallelSSH/parallel-ssh. Depending on your host OS, there are also pre-built RPM and DEB files available from repositories
- For simplicity, it's recommended to have a secure and static management host for FRP activities, and use SSH key pairs to streamline passwordless connections to QWS Endpoints
- If it's not possible to secure this management host, PSSH will still be functional, but will pause on each QWS Endpoint for an authentication check
- Create a file (ie. QWS_CLIENTS) with each remote IP and port of the QWS clients, each on their own line as: admin@FRP_IP:PORT
- Alternatively, this file can also be directly downloaded from the portal, but that will only be populated with currently connected clients. Ports are configured dynamically, so this will change over time as clients disconnect / reconnect.
- To push files in parallel to all QWS clients, the syntax is as follows:
- pscp.pssh -h QWS_CLIENTS filename /remotedir
- Success / failure status will be presented back in the CLI for each line in the QWS_CLIENTS file
- This method would allow for the same file to be transferred to multiple targets at once
- To execute the same command on multiple QWS clients in parallel:
- pssh -i -h QWS_CLIENTS "command to be executed"
- Success / failure status will be presented back in the CLI for each line in the QWS_CLIENTS file
- This method would allow for the silent installation on multiple targets at once
- Note that the file will either have to be an MSI, or and EXE that supports silent command line switching (ie - WinSCP-install.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART)
- For simplicity, it's recommended to have a secure and static management host for FRP activities, and use SSH key pairs to streamline passwordless connections to QWS Endpoints
Individual Option - SSH and SCP
- From the QWS-CSP web GUI, find the entry for the client, and note the port number. The syntax to connect is as follows:
Windows Management Host
Multiple Option - WSUS
- For this option, you will need to have a Windows server available in your infrastructure, and have WSUS installed. Configuring each QWS Endpoint to connect to this machine for Windows updates will give you a variety of ways to push file and configuration updates. This requires advanced knowledge of WSUS, and will not be covered in the scope of this document
- Alternatively, if there is an Active Directory server available, files can also be pushed to domain joined QWS Endpoint via group policy.
Individual Option - RDP
The QWS-CSP web GUI provides an RDP port for each user, which can be reached on the internal LAN only via the IP of the BDC Server, and the specific port. Depending on the latency of individual connections, establishing an RDP session can sometimes require more than one attempt.
Individual Option - Chocolatey (Work in Progress)
Chocolatey is an open source repository for Windows, that acts much the same way that yum or apt-get do for Linux distributions. There is a list of community maintained packages here: https://chocolatey.org/packages.
There is also documentation on creating custom packages here: https://chocolatey.org/docs/create-packages
In order to use this method, firewall exceptions will need to be made to the Chocolatey repository / website.
To install Chocolatey on your local admin machine, open PowerShell and enter the folllowing:
- Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Installing Chocolatey on the remote client will require that PowerShell be opened in elevated mode. Then enter the following commands:
- netsh winhttp reset proxy
- Enable-PSRemoting -Force -SkipNetworkProfileCheck
- Set-Item wsman:\localhost\client\trustedhosts *
- Restart-Service WinRM
- Test-WsMan QWS_VM_NAME
Once connectivity has been validated with the final command in the list above, packages can be installed as follows:
- Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
- Invoke-Command -ComputerName QWS_VM_NAME { choco install PACKAGE_NAME -y } -credential Administrator
It's possible to also use Chocolately to install on multiple machines at once, by adding this script block to the command above:
$ComputerList = "QWS_CLIENT1","QWS_CLIENT_2"
foreach ($Computer in $ComputerList)
{
Invoke-Command -ComputerName $Computer
{
iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
choco install PACKAGE_NAME -y
}
}- Making the command: Invoke-Command (ScriptBlock above) -credential Administrator
Adding multiple machines to a domain at the same time
From the CSP portal, the Export Reverse Proxy button will generate a text file with all of the currently registered QWS Endpoints. Using this text file and the FRP channel, administrators can automate joining all of these endpoints to the domain in a few different ways, depending on corporate network structure.
Scripting logins to each entry on the exported list, and using pssh to execute the powershell command "$env:computername" will generate a list of machines names for each successful connection. If the names are discoverable between the VPN subnet and the domain server, one command can be executed to join them all at once.
With this list (ex. - computers.txt), in Powershell run these commands:
$computers = Get-Content -Path computers.txt
Add-Computer -ComputerName $computers -Domain "YourDomainName" -Restart
Alternatively, if the machine names are not discoverable, running pssh and executing the Powershell command below will join each machine to the domain as a connection is established over the FRP channel, and restart the VM:
Add-Computer –domainname "YourDomainName" -Restart
After the AD bind process is successful, end users can log in as the "User" account to connect to the corporate network, and then switch users to their domain account after the network connection is established. This will cache their credentials in the VM, so that future logins can be done offline if desired. An additional reboot may be required in order to repopulate the VPN configuration information from the encrypted store.
Once joined to the domain, the domain administrator account can log in via the FRP with the command as below:
ssh -p FRP_port -l administrator@domain FRP_IP