The Azure AD Application Proxy is similar to the on-premises Web Application Proxy role, starting in Windows Server 2012 R2. With this service, you can enable external access for on-premises applications. Azure AD Application Proxy requires an Azure AD Basic or an Azure AD Premium subscription. The connection is made directly with Azure and done through a proxy into the private network, with an application proxy agent installed on the on-premises web application server.

Let's run a very common use case to include a Kerberos on-premises application into our Azure AD Access UI, https://myapps.microsoft.com. We use our existing application to configure the scenario:

1. Log in to https://portal.azure.com and choose the Azure Active Directory blade.
2. Under Application proxy, we first need to download and install the application proxy agent on our YD1APP01 server.

You don't need to install the agent directly on the application server. It's also possible to use any other server, or also additional agents for redundancy requirements. The agent needs to be installed on a server in the same or a correctly trusted domain/forest to support Kerberos constrained delegation, and the SPN of the application needs to be done on every agent instance. The domain function level needs to be Windows Server 2012 at a minimum. Also, the correct ports need to be accessible from the other server.

3. Download the agent onto the server and start the installation:

4. Agree to the license terms and conditions and click Next.
5. Next, you need to provide global administrator credentials to register the agent to Azure AD.
6. Recognize the notification for outbound proxy usage:

7. The expected result is an Active agent:

8. Now, we can start to configure our Kerberos-based on-premises application.
9. First, we create a group that can be assigned to grant access to the portal:

10. Assign one test user to your group.

11. Next, we will configure the app proxy configuration:

12. As you can see, you are able to provide several additional settings to address your needs.

13. In the next step, we will configure the Single-Sign-On options for our application.
14. Choose the Windows Integrated Authentication option:

15. Enter your Internal Application SPN to configure the Kerberos part.
16. Keep in mind that only Kerberos Constrained Delegation will work:

17. After this configuration, we can test the application with the assigned user in your access group, and you should get a similar result to this:

18. You will find the settings under Basic Settings:

For the certificate, you need to use the following section. Don't forget to create the CNAME inside your public DNS:

The next authentication method we can use for cloud or on-premises applications (through Azure AD Web Application Proxy) is the password-based option. We use it for form-based authentication activated applications that use their own identity provider.

In the next steps, we will add a password-based application access:

1. Add a new application and use the Non-gallery application option.
2. Choose the Password-based option under the Single sign-on method:

3. Provide a name for your application and navigate to the Single-Sign-On configuration:

4. Provide the Sign-On URL and detect the sign-in fields of your application.
5. There are three options to do this configuration:
   • Automatically
   • Manually
   • With custom configuration in the Advanced View:

6. In this example, we used our public DNS provider's login page.
7. You can view the field labels with any browser and the developer tools to provide the values if the Azure AD mechanism doesn't get the correct values:

8. Next, you need to assign the user or group to the application:

9. For now, provide the credentials with the Update Credentials button:

10. Now, you are ready to test the application with your test user.

11. To test the same capabilities with your on-premises infrastructure, we provide you with a small challenge. If you don't get it running, send an email to [email protected] and we will be happy to provide you with the answer.
12. You need to deploy the test application with the following steps on the YD1APP01 server.
13. Create a DNS entry for the app on your domain controller (YD1ADS01), forms.inovitdemos.ch:

Add-DnsServerResourceRecord -ZoneName "inovitdemos.ch" -A -Name "forms" -IPv4Address "10.0.0.6"

14. Create the service account under which the application runs on your app server:

New-ADUser -Name "svcformsapp" -SamAccountName svcformsapp -UserPrincipalName [email protected] -path "OU=Users,OU=AAD,OU=Managed Service Objects,DC=inovitdemos,DC=ch" -AccountPassword (ConvertTo-SecureString "MIA@me1976ch" -AsPlainText -Force) -Description "Forms App Pool Account" -Enabled $True

15. Connect to your SQL Server over in the SQL Management Studio on your YD1APP01:

16. Create a login for your service account under Security | Logins:

17. Assign the dbcreator server role to the user:

18. Next, we need to create the website on the server:

New-Item C:inetpubformsroot -type Directory
Import-Module Webadministration
cd IIS:
New-Item 'IIS:Sitesforms Web Site' -bindings @{protocol="http";bindingInformation=":80:forms.inovitdemos.ch"} -physicalPath 'c:inetpubformsroot'

19. As with the other on-premises demo applications, we will create a HTTPS binding and assign our SSL certificate:

20. We also need to create a new app pool for the website and use the service account to run the app:

21. Next, we will assign the newly created application pool to our website under Advanced settings:

22. The authentication for the page should be configured as shown in the following screenshot:

23. The next step is that we need to copy the content of the formsapp folder from the code package to C:inetpubformsroot:

24. Before you can run the app, you need to configure the web.config file to address the SQL Server instance:

<add name="DefaultConnection" connectionString="Data Source=YD1APP01;Initial Catalog=FormsBasedAuthentication;Integrated Security=True" providerName="System.Data.SqlClient" />

25. Now, you can test your application by registering a user and a successful login:

26. Start with your publishing scenario and log in to this website—good luck!

In the next example, we will use the Windows Server Web Application Proxy to publish a Basic authentication-based application to external users:

1. First, you need to log in to your YD1ADS01 to configure the relying party for the Basic demo application.
2. Navigate to Relying Party Trusts and Add Relying Party Trust.
3. Choose the non-claims-aware option.
4. Fill in the following Display Name: Basic Demo Web Site.
5. Use https://basic.inovitdemos.ch (replace it with your domain) as Relying Party Trust Identifier and click add.

6. Click Next until the wizard is finished.
7. Log in to your YD1URA01 server and open the Remote Access Management console.
8. Click on Publish in the right-hand Tasks pane:

9. Specify the ADFS preauthentication method:

10. Choose HTTP Basic as the type of preauthentication:

11. Choose Basic Demo Web Site relying party.
12. Fill in the following publishing values:

13. Click Next, Publish, and Close:

14. Now, you can test your freshly published Basic authentication app.

In the next section, we will include the first conditional access options.