Using Azure App Proxy with RDWeb

With the release of the new Azure App Proxy connector Microsoft decided to finally officially support the App Proxy for the (new) RDWeb Client.

I’ve been waiting for this for some time now because the only way to use the new client was by using the plugin for NPS which wasn’t sufficient as it only supported authentication after you where logged in on the RDWeb Client. It also didn’t support the App Proxy so you still had to open up the HTTPS port to the RDWeb server on your firewall.

Now that it’s here it was time to start writing a blog about it. With some new ideas I’ve gotten from my previous blog about the App Proxy (Securing & using SSO for OWA & ECP with the Azure App Proxy) it was time to start writing this blog.

Now let’s start by summing up some pro’s and con’s this solution has to offer you, what you’ll need in your environment and the steps that need to be taken in order to get it up and running.

Pro’s and cons

Pro’s
  • No more open firewall ports!
    • Port 443 open to the public? No way bro…
  • Pre-authentication
    • You will be able to leverage Conditional Access which (as we all know) enables MFA, SSO and other conditions for Microsoft 365 cloud resources. You can even have specific rules for the RDWeb App as it will be published as an Enterprise Application in Azure.
  • Less attack surface
    • Because there are no patches that need to be installed in order to keep the internet facing OS, IIS and RDS components secure.
  • Include RDWeb in your Company Portal
    • Users will be able to reach the RDWeb Client from the My Apps portal
  • The RDWeb Client is based on HTML5 and therefore compatible with almost every internet browser.
  • You can load balance and “cluster” the App Proxy
    • The App Proxy will allow you to install multiple instances who are aware of each other.
Con’s
  • No SSO support between App Proxy and RDWeb
    • There currently is no support for SSO between Azure App Proxy and the HTML5 RDWeb Client. I’ve tried to let it work based on Windows Integr. Auth. and Form Based but there was no way to send the credentials to the RDWeb Client.

      Sidenote The RD Gateway does however work with SSO and will allow you to only access the RemoteApps through the App Proxy.

Prerequisites

You will need 3 servers in your environment.

A Domain Controller which is responsible for the usual stuff like DNS name resolving and Active Directory.
The other 2 servers are the App Proxy (be sure to implement multiple servers because the more servers you have, the better your HA and LB will get) and of course the RDS server to host the RD Gateway and RD Web services.

You will also need the latest release of the App Proxy which enables support for the RDWeb Client and AD Connect to sync your accounts.

On Windows Server 2019 you will need to disable HTTP2 (Link).

An Azure AD Premium P1 license is also required to make use of the App Proxy.

Remember to allow outbound access from the App Proxy connector server(s) to the URL’s and ports used by Azure (Link).

Data flow

The principal of the App Proxy is to tunnel traffic through the App Proxy connector you install on a server which is located inside your LAN. This connector communicates with the Azure front-end to deliver a sort of kiosk in which the web application runs.
I’ve demonstrated this in the above data flow schema.

Now, let’s get this party started!

In order to leverage the App Proxy we will need to take the following steps:

Install the RDWeb Client

Set the RD Licensing to Per User

Enable and install the Azure App Proxy

Add the application to Azure

Configure the RD Gateway and published RDP to use Azure App Proxy for Pre-Auth

Set the Homepage URL

Assign the application

The end result

Install the RDWeb Client

In order to leverage the usage of the HTML5 client you’re going to download, install and activate the client via Powershell.

In the video I’ve used the following commands:

Install-Module -Name PowerShellGet -Force
Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage
Import-RDWebClientBrokerCert PATH

Where PATH is the location of the certificates CER file

Publish-RDWebClientPackage -Type Production -Latest
Set the RD Licensing to Per User

The HTML5 client will require you to use the Per User license for RDS services so we’ll need to change that setting. Of course you’ll need the appropriate licenses so be sure to have sufficient licenses installed on your RD Licensing server.

Enable and install the Azure App Proxy

To start using the App Proxy you will simply need to enable the functionality and install the App Proxy connector on one or multiple servers. In this blog I’ve only used one server which is sufficient for basic demo purposes.

Add the application to Azure

To make the application available and enable the usage of the App Proxy for RDWeb we will need to add it to Azure and and define the parameters like configuring the URL of the (RDS) server and set the URL of the application for the outside world. In this video I’m using an appproxy.ms.net address but you can also create a URL with your own domain like app.domain.com. The only thing you will need to do then is upload a valid 3rd party certificate for the URL.

Configure the RD Gateway and published RDP to use Azure App Proxy for Pre-Auth

The RD Gateway and RDP file make up the “back-end” where you’ll connect with to start the published RD Web app. These 2 components will need to malformed in order to be in line with the App Proxy structure. You will set the RD Gateway advertised name and the pre-authentication server address to the App Proxy’s URL so that when connecting to the application the RDWeb will stay inside the App Proxy “kiosk” and will not notice any changes to the destination being the RD Gateway.

In this video I’ve used the following commands:

Set-RDSessionCollectionConfiguration -CollectionName COLLECTIONNAME -CustomRdpProperty "pre-authentication server address:s:AZUREAPPURL`nrequire pre-authentication:i:1"

AZUREAPPURL is the URL you are using for your application like https://rdweb.msappproxy.net/

COLLECTIONNAME is the name of your RDS collection like MyRDScollection

You can check if the command applied the correct settings by running the following command:

(get-wmiobject -Namespace root\cimv2\terminalservices -Class Win32_RDCentralPublishedRemoteDesktop).RDPFileContents
Set the Homepage URL

The Homepage URL is the one that’s going to used for the published app in the My Apps portal and points the tile to the right internal URL of the RDWeb server.

Assign the application

To also make the application visible in the MyApps portal you’ll also need to assign it to your users. There is an option to make it available to all users but assigning it to specific users or groups gives you control over which users need which applications.

The end result

Now that you’ve set the correct settings it’s time to enjoy the show!

I hoped you liked reading and viewing this blog!

And if you have any questions, feel free to post a reply!

Dit vind je misschien ook leuk...

29 reacties

  1. Jose schreef:

    Hello, i have also been working on Rd-Webclient (html5) via azure App Proxy but now i’m not able to start an application. Because the Connection seems to not work! My client hangs on “Opening remote port” – and after timeout i get a message “Try to reconnect”!

    So can you also start the “Wordpad” app for example?

    I have found that port 3391 also need to be transportet via app proxy???

    • Patrick van Bemmelen schreef:

      Hello Jose,

      Could you please check the steps from the “CONFIGURE THE RD GATEWAY AND PUBLISHED RDP TO USE AZURE APP PROXY FOR PRE-AUTH” paragraph?
      And did you set the port for the RD Gateway on 443 (default)?
      It seems to me that either the port of the RD Gateway has been changed or Windows Firewall is blocking access to this port.
      Port 3391 isn’t required although it does enable you to use UDP for the connection.

      • Jose schreef:

        I have configured it like yours. I think it would also be no problem if you check “Bypass RD Gateway on local adresses”. This setting if had before! But no difference. I could not start the app because the client hangs on “Opening Remote Port”.

        What are your settings on azure app proxy (additional settings – Http-only Cookies, Secure Cookies, Perstent Cookies, Translate Header, Body ??)

      • Jose schreef:

        Where can i set RD Gateway on 443 (default)?

        • Patrick van Bemmelen schreef:

          Hello Jose,

          You can set the port like so:

          Go to Server Manager > Remote Desktop Services
          Right-click the RD Gateway server name in the navigation pane and select Properties.
          Select the Transport Settings tab.
          Here you should find the ports set for the RD Gateway role.
          It could be that the names differentiate a little because I don’t have a RD Gateway server set up right now 😉

    • Jose schreef:

      Yess! Now i have fixed the problem.

      I have to update the Azure App Proxy!!

      • Patrick van Bemmelen schreef:

        Hello Jose,

        Sometimes it’s the little things that make the difference.. glad to hear that you where able to find the problem!

  2. Jose schreef:

    Hello, now a have another problem. It’s the backslash(\) that makes a problem in the html5 client.

    So if i want to input an path for example c:\\temp\ … it does not show in the webclient. Because the input is converted to different characters!

    • Patrick van Bemmelen schreef:

      Hello Jose,

      Could you please elaborate on what you are trying to add to the App Proxy?
      Is it a Explorer process which opens a file share for example?

  3. jack schreef:

    I can not get the RDP file to work at all, just the web browser session. what could be the issue here? it just keeps saying when connecting to the RDP file:
    “your computer cant connect to the remote computer because authentication to the firewall failed due to missing credentials”.

    • Patrick van Bemmelen schreef:

      Hi Jack,

      The RDS gateway will only be available through the RDWeb because the RD Gateway uses the App Proxy in the authentication flow which only works when you access it through a browser.
      Using RDP files to the RD Gateway isn’t supported anymore after you set up the App Proxy.

  4. Pedro Rocha schreef:

    Hi Patrick, first of all, thaks for the detailed post.

    I follow all the steps but I’m receiving sig in failed error when trying to sign in after Azure AD authentication, I alerady disable HTTP2 and checked every step. When I try to login on Web Client from my internal network it works, there is something else to configure Single Sign On?

    Regards.

  5. Patrick van Bemmelen schreef:

    Hello Pedro,

    Could you maybe post the exact error you’re receiving after you signed in on the Azure App Proxy page?
    This should state the reason why the sign-in information for the RDWeb authentication wasn’t correctly translated to the RDWeb sign-in.

    • Pedro Rocha schreef:

      I receive the following message from RD webclient: “Sign in failed. Please check your username and password and try again”. I checked the security log at the endpoint and my RD Server didn’t receive any connection attempt.

      Microsoft login is ok, the problem occurs when I input my credentials at RD webclient.

      • Patrick van Bemmelen schreef:

        Hello Pedro,

        Could you try to disable SSO and then open the App Proxy and see what is does?
        If it comes with a login screen from the RDS then it’s the way you supply the credentials, there are different ways to choose from like Domain\UPN and SamAccountName. This depends on how you configured the RDS server.

        • Pedro Rocha schreef:

          I tried to login without SSO, using Domain\UPN and it works, but when I access through Azure App Proxy, I receive the sign in failed error on RDS screen.

          • Patrick van Bemmelen schreef:

            I think it was something to do with the Delegated Login Identity you’ve set. Could you check if it is set to User Principal Name? And are UPN’s the same on both on-premise and the cloud? So is the UPN on-premise user@domain.com and the Microsoft 365 account as well?

  6. Pedro Rocha schreef:

    Hey Patrick, i checked everything a lot of times and now it’s working, i need to make a fresh install to work.

    Many thanks for your support.

    • Patrick van Bemmelen schreef:

      Hello Pedro, I’m really happy hear that you had it resolved! And it was my pleasure in assisting you on this!

  7. Ashley schreef:

    Hi Patrick,
    I’ve done this and it’s working fine.
    But it’s only sso when connecting to rdweb.
    Users can connect without the auth going through azure, you can also just open up rdp and set the gateway and it connects. Your article suggests it should not work?

  8. JeremieR schreef:

    Hello
    Greate tuto
    I have a pb with the number of authentication from an external device
    3 authentications : Azure AD – webclient – rdweb
    Is it possible to reduce to 1 or 2 ?

    • Patrick van Bemmelen schreef:

      Hi Jeremie, if you’re using the HTML5 web client this still uses the original RDWeb backend so I’m afraid you won’t be able to trim down the amount of authentication flows. If you’re still using the old RDWeb then I’d advice you to install the HTML5 client.

      • JeremieR schreef:

        I installed HTML5 webclient on the RDWeb server to add compatibility with next gen browser (chrome, Firefox,etc…) because basically RDWeb is only compatible with IE on external access

        • Patrick van Bemmelen schreef:

          That’s correct, and I’m afraid my answer still applies that won’t be able to lower the amount of authentication stages you go through while logging in.

          • JeremieR schreef:

            Is it possible to disable original RDWeb and only have new html5 ?

          • JeremieR schreef:

            Finally I fix my pb with 2 RDWeb servers
            1 for interne usage with classic RDWeb site because we customized iis
            1 for external usage with html5 web client without iis custom

          • Patrick van Bemmelen schreef:

            That’s also a great solution Jeremie, well thought of and glad to hear that you’ve got it resolved!

  9. Chris schreef:

    Hey Patrick, thank you for this article!
    Unfortunately, it seems like I experience the same problem as Pedro Rocha: “Sign in failed. Please check your username and password and try again”.

    Nothing seems to work, can’t login through client, can’t login through web. Users are added to the Desktop Application Group, I’ve also assigned IAM Role “Desktop Virtualization User” but no luck. UPN that I use to log in is exactly the same as in Azure AD.

Laat een reactie achter bij Patrick van Bemmelen Reactie annuleren

%d bloggers liken dit: