Azure Active Directory Application Proxy (AAP) has found its way into many organizations during the pandemic as an approach to delivering internal applications quickly and securely to stay-at-home employees. Security comes from Application Proxy (App Proxy) integration with Conditional Access, which can enforce multifactor authentication (MFA) and ensure access from trusted, managed devices tagged as "healthy." The architecture makes deployments simple. The proxy does its work with outbound network connections to the cloud only – central IT does not need to drill down into firewalls [1].

Many applications continue to make use of a full-fledged client architecture, according to which the client talks to the back end with special or proprietary protocols – or the back end cannot be easily published. In other use cases, especially when the client does not remain on the user's device but is also to be made available, the standard scenarios of a classic HTTP proxy end. A trick provides a way out: By publishing a session on a VM or session host, entire applications can be published, provided the solution makes the session accessible by a gateway or proxy over HTTPS. If you can publish the Citrix or remote desktop environment with App Proxy, you can also handle these scenarios.

In other words, you are changing the task to one of providing clients with access to a session server, which you do in as simple a way as possible, with single sign-on (SSO) – but with protection, of course. The session server then gives access to clients that do not need to talk to the back end over HTTP protocols.

Get Prepared

The implementation with Microsoft technology envisages Remote Desktop Services (RDS) for this task in combination with AAP, which publishes the RDS, supports SSO, and adds safeguards with the help of Conditional Access. This scenario allows the IT team to offer both convenient access to services with SSO and to use the set of rules from Conditional Access to define policies that only allow access by known devices perceived to be healthy or MFA for the connection.

In the simplest case, for a proof of concept, an Azure Active Directory (AD) tenant and a server running both RDS and the App Proxy agent will do the trick. For a production environment, you will want to follow Microsoft's recommendations for the number of sessions and users you are targeting. RDS comprises multiple roles; for publishing with App Proxy, the focus will be on the RD Web Access role, which handles session-to-HTTP translation. In the example here, AAP is the bridge between clients connecting from the home office and the internal network, where the session hosts and RD Web Access reside. The servers, to enable SSO, also all need to be members of a Windows AD.

Also on the procurement list is a TLS/SSL certificate for the RD web app, which is used with a private key in Azure AD (AAD) and for RDS. If you want to reach the RD services (in this example, by https://websession.contoso.com ), you need the appropriate certificate for this address. You will then use it to install the RD roles on Windows Server. You should also be able to create a new canonical name (CNAME) for the target domain so that you can redirect the URL of the RDS to the unique publishing URL you get from Azure AD.

Installing Roles and Certificates

For the setup, it is best to start small: In a test environment, you can store all the required server roles for Remote Desktop and the application proxy on one server. If you plan to expand the setup slowly afterwards, you can also start with multiple servers. The RD Web Access and RD Gateway roles can be concentrated on one server and the remaining Remote Desktop roles distributed to another or multiple servers.

To start the RD setup, go to the Server Manager and, depending on the target architecture, select Standard deployment for multiple servers sharing different roles or Quick Start , then Add roles and features . The first RDS roles end up on a server, but the RD Gateway role is not yet included. Continue with Quick Start for easy deployment, then install the Gateway role. For publishing applications shared in virtual sessions, select Session-based desktop deployment .

Once the basic installation is complete, you will see a graphic on the target servers on the left Remote Desktop Services menu under Overview in the Server Manager; this shows you the installed roles. You can add new servers for RD Gateway and RD Licensing ; the other roles are already installed. Check here that all roles are present.

If the gateway is already installed, select Tasks | Edit Deployment Properties and check that the name of the server is correctly in fully qualified domain name (FQDN) form for the self-signed SSL certificate. Under Logon method , make sure that Password Authentication is chosen in the drop-down menu and Use RD Gateway credentials for remote computers is checked (Figure 1). In case of a new RD Gateway installation, click on Configure certificates before closing the dialog. If the RD Gateway is already available, check in the Certificates section whether all SSL certificates are stored for all roles.

Figure 1: Remote desktop components must be able to use the correct certificates for secure publishing.

To configure SSL certificates for internal and external trusts, you can use the Create new certificate and Select existing certificate buttons for each role. The Select existing certificate option lets you select the certificate in PFX format (i.e., with a private key) by specifying the password and allowing its use for the respective role. However, you have to repeat this process of adding the certificate for all roles so that Success appears in the State column at the end of each role line.

If no app is configured for RD access yet, you need to create a collection where you publish the apps. If you have chosen quick deployment, this is already done, including publishing Paint and Calc as sample apps. Otherwise, you need to create a new collection in the Server Manager in RDS under Collections .

If you have chosen the same DNS name internally and externally, as in the example, you need to register the name internally in the DNS: The CNAME for websession.contoso.com should point to the name of the machine with RD Web Access and the RD Gateway.

Finally, to prepare pre-authentication for configuration with App Proxy, you need to customize the collection in PowerShell. The following PowerShell command sets the collection to pre-authentication, listening for the public DNS name that is also used from the Internet:

Import modules RemoteDesktop
Set-RDSessionCollectionConfiguration -CollectionName "QuickSessionCollection" -CustomRdpProperty "pre-authentication server address:s:websession.contoso.com/ `n requirepre-authentication:i:1"

Note the `n delimiter between the URL and the require pre-authentication properties.

Configure the Proxy

Once the service is available locally, you can start using App Proxy to configure publishing to the outside world. You have two options: either you set up simple publishing or you let AAD perform pre-authentication, after which Conditional Access enforces further rules.

If you do not already have an App Proxy agent installed on your local network that you can use for publishing, you will want to go to the AAD portal (logged in as administrator) and download the agent from Application Proxy | Download connector service . Transfer the installation file to either the RD host or another Windows server that has a network connection both outbound to the Internet and to the Remote Desktop Server. After you start the installer, it will prompt you for permissions to register the connector in the cloud with a logon window for AAD. You can specify a user who occupies the Application administrator role. It does not have to be the Global administrator .

Shortly after installation, when you reload the Azure AD portal, take a look at Application proxy and find the agent marked with a green arrow, which tells you that the connection is up. The next step is to create the publication in AAD. First, click on Enterprise applications | +New application . Under the On-premises applications heading, you will see a suggestion for Add an on-premises application , which you can accept. Now the App Proxy publication wizard starts up.

Enter the application name and the internal and external URLs, which should be the same (Figure 2). In the selection field for External Url , the tenant-specific <Tenant-Name>.msappproxy.net domain is preselected, but you can select any domain for which you have completed domain registration, including validation in AAD. Therefore, you also can use internal domain addresses, as long as the internal domains are resolvable on the Internet. Finally, select Azure Active Directory as the option for Pre Authentication . The rest of the default settings are correct.

Figure 2: For secure RD application sharing, configure Azure AD App Proxy with AAD pre-authentication.

At the end of the dialog, you will see a message stating that you need to create a CNAME record for the target domain, which is required for redirection from websession.contoso.com to websession-contosotenant.msappproxy.net and avoids certificate errors. Once you have saved the App Proxy application with +Add , create this CNAME with a time to live (TTL) of 3600 seconds in the public DNS that clients go to outside the network. Once the application is registered, note the Application ID and Object ID in the app settings in the Overview – you'll need these again right away if you want to publish the HTML5 web client.

In Properties check whether User assignment required? is set to Yes , then the AAD will check before pre-authentication whether an administrator has assigned the RDSs to the user and whether access is desired. You now have several levers for restricting access to the services. You can define at both the gateway level and the AAD level which employees are allowed to connect to RD Web Access. Then, you can add definitions in Users and Groups .