Wednesday, December 26, 2018

Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy

Applies To: Windows Server 2012 R2
This content is relevant for the on-premises version of Web Application Proxy. To enable secure access to on-premises applications over the cloud, see the Azure AD Application Proxy content.
This walkthrough provides instructions for connecting to applications and services from anywhere with Web Application Proxy. For more information about connecting to applications and services from anywhere with Web Application Proxy and Windows Server® 2012 R2, see Connect to Applications and Services from Anywhere with Web Application Proxy and the video for Installing the Web Application Proxy.
Before you perform this walkthrough, make sure you have completed the lab setup guide, see Set up the lab environment for AD FS in Windows Server 2012 R2. Also make sure you have completed the following planning steps that are required in order to deploy Web Application Proxy and publish applications through it using Active Directory Federation Services (AD FS) for authentication and authorization, including workplace join, multifactor authentication (MFA), and multifactor access control.
  • Plan the Web Application Proxy infrastructure—Before you deploy Web Application Proxy, you must plan the infrastructure. For this walkthrough, this includes:
    • The Web Application Proxy server should be located between the corporate network and the Internet; in this walkthrough, this is achieved by configuring two network adapters on the Web Application Proxy server.
    • For clients to reach a published web application they must be able to resolve the external address of the application that is published by Web Application Proxy. In this walkthrough, this is achieved through the hosts file on the client.
  • Plan the Web Application Proxy server
    • It is recommended to join the Web Application Proxy server to the AD DS domain. Joining the Web Application Proxy server to the domain allows you to expand this walkthrough to demonstrate publishing applications that use Integrated Windows authentication.
    • Make sure that the server time of the Web Application Proxy and AD FS servers are synchronized.
    • To install the Web Application Proxy role service, you must have local administrator permissions on the server.
    • To configure the Web Application Proxy server to connect to AD FS, you are required to enter the credentials of the local administrator on the AD FS server.
    • Make sure that there is a certificate in the Personal certificates store on the Web Application Proxy server that covers the federation service name. This certificate is required for AD FS proxy functionality.
      To locate the federation service name value, open the AD FS Management console, click Service, in the Actions pane, click Edit Federation Service Properties, and then find the value in the Federation Service name text box.
    • Make sure that there is a certificate in the Personal certificates store on the Web Application Proxy server that covers the external address of the sample web application; that is, the address that you will configure when you publish the application through Web Application Proxy. In this walkthrough, you can use a self-signed certificate, or a certificate from an Enterprise certification authority (CA).
    Note
    In a production environment, it is recommended to use certificates from a public CA on your Web Application Proxy server.
Task Description
Step 1: Attempt to access the web application from an Internet client Configure an edge server and demonstrate that before configuring Web Application Proxy and publishing the application, the web application server is protected from the Internet, and clients are unable to access the application.
Step 2: Configure the Web Application Proxy server and publish the application Configure the edge server as a Web Application Proxy server, publish the web application, and demonstrate that with the default AD FS authentication scheme, a client device can access the published application from the Internet.
Step 3: Configure and test accessing a website using Integrated Windows authentication Configure an additional website on WebServ1 to use Integrated Windows authentication, configure Kerberos constrained delegation in the lab, publish the application through Web Application Proxy, and demonstrate accessing this application from the Internet.
Step 4: Demonstrate accessing an application using Workplace Join, MFA, and multifactor access control Configure Workplace Join, multifactor authentication (MFA), and multifactor access control, and demonstrate how these additional authentication factors change the user experience when client devices attempt to access the published web application.

Step 1: Attempt to access the web application from an Internet client

In this step, you will configure an edge server and attempt to access the sample application. This step does not install the Web Application Proxy role service on the server. After configuring the edge server you will modify the hosts file on the client computer and attempt to connect to the sample web application through the edge server.

To install the edge server

  1. Create a Windows Server 2012 R2 server with two network adapters, one connected to the corporate network, one connected to the simulated Internet.
  2. Configure the static IP addresses on the server. For example, the network adapter on the corporate network should have an IP address of 10.0.0.2, the network adapter on the simulated Internet should have an IP address of 131.107.0.2.
  3. Join the server to the AD DS domain.

To access the application

  1. In your lab environment, connect the client computer to the simulated Internet network and assign a static IP address; for example 131.107.0.10.
  2. On the client computer, open Notepad as the administrator.
  3. In the Notepad window, open the hosts file located at %windir%\System32\Drivers\etc.
  4. Add two new lines to the file; for example:
  1. 131.107.0.2       webserv1.contoso.com
131.107.0.2       adfs1.contoso.com
131.107.0.2       enterpriseregistration.contoso.com
    • The first line contains the IP address of the Internet adapter of the edge server and the external address of the sample application that you will configure when you publish the application through Web Application Proxy.
    • The second line contains the same IP address and the address of the federation server.
    • The third line contains the same IP address and the address required for Workplace Join.
  2. Open an Internet explorer window and go to the sample web application; for example, https://webserv1.contoso.com/claimapp/.
    The edge server is not providing proxy or publishing functionality; therefore, you will not be able to access the application.

Step 2: Configure the Web Application Proxy server and publish the application

In this step you will:
  • Configure the Web Application Proxy server.
  • Connect the Web Application Proxy server to the AD FS server using the Web Application Proxy Configuration Wizard.
  • Publish the sample application.
  • Attempt to connect to the sample application using the default AD FS authentication scheme.
Before you can publish the application, make sure you have done the following:
  • Create a relying party trust for the sample application in the AD FS Management console. If you did not do this when setting up your environment, see Create a relying party trust on your federation server.
  • Verify that a certificate on the Web Application Proxy server is suitable for the sample application you want to publish.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To install the Web Application Proxy role service

  1. On the edge server, open Server Manager. To do this, click Server Manager on the Start screen, or Server Manager in the taskbar on the desktop.
  2. In the Quick Start tab of the Welcome tile on the Dashboard page, click Add roles and features. Alternatively, you can click Add Roles and Features on the Manage menu.
  3. In the Add Roles and Features Wizard, click Next three times to get to the server role selection screen.
  4. On the Select server roles dialog, select Remote Access, and then click Next.
  5. Click Next twice.
  6. On the Select role services dialog, select Web Application Proxy, click Add Features, and then click Next.
  7. On the Confirm installation selections dialog, click Install.
  8. On the Installation progress dialog, verify that the installation was successful, and then click Close.
Windows PowerShell equivalent commands
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

To configure Web Application Proxy

  1. On the Web Application Proxy server, open the Remote Access Management console: On the Start screen, click the Apps arrow. On the Apps screen, type RAMgmtUI.exe, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
  2. In the Remote Access Management console, in the navigation pane, click Web Application Proxy.
  3. In the middle pane, click Run the Web Application Proxy Configuration Wizard.
  4. In the Web Application Proxy Configuration Wizard, on the Welcome dialog, click Next.
  5. On the Federation Server dialog, do the following, and then click Next:
    • In the Federation service name box, enter the fully qualified domain name (FQDN) of the federation service; for example, adfs1.contoso.com.
      To locate this value, open the AD FS Management console, click Service, in the Actions pane, click Edit Federation Service Properties, and then find the value in the Federation Service name text box.
    • In the User name and Password boxes, enter the credentials of a local administrator account on the AD FS servers.
  6. On the AD FS Proxy Certificate dialog, in the list of certificates currently installed on the Web Application Proxy server, select a certificate to be used by Web Application Proxy for AD FS proxy functionality, and then click Next.
  7. On the Confirmation dialog, review the settings. If required, you can copy the PowerShell cmdlet to automate additional installations. Click Configure.
  8. On the Results dialog, verify that the configuration was successful, and then click Close.
Windows PowerShell equivalent commands
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
The following command will prompt you to enter credentials of a local administrator account on the AD FS servers.
Install-WebApplicationProxy –CertificateThumprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b' -FederationServiceName adfs1.contoso.com

To publish the sample claims-based application

  1. On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.
  2. On the Publish New Application Wizard, on the Welcome page, click Next.
  3. On the Preauthentication page, click Active Directory Federation Services (AD FS), and then click Next.
  4. On the Relying Party page, in the list of relying parties select the relying party for the sample application, and then click Next.
  5. On the Publishing Settings page, do the following, and then click Next:
    • In the Name box, enter a friendly name for the application.
    • In the External URL box, enter the external URL for this application; for example, https://webserv1.contoso.com/claimapp/.
    • In the External certificate list, select a certificate whose subject name covers the external URL.
    • In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL.
  6. On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command set up additional published applications.
  7. On the Results page, make sure that application published successfully, and then click Close.
    Publishing the application may take a couple of minutes.
Windows PowerShell equivalent commands
The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.
Add-WebApplicationProxyApplication
    -BackendServerURL 'https://webserv1.contoso.com/claimapp/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://webserv1.contoso.com/claimapp/'
    -Name 'Claims App'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'App_Relying_Party'

To access the application

  1. On the client computer, open an Internet explorer window and go to the sample web application; for example, https://webserv1.contoso.com/claimapp/.
  2. On the sign in page, enter the credentials of the test user that you created when you set up the environment.
  3. The application appears in the web browser.

Step 3: Configure and test accessing a website using Integrated Windows authentication

In this step you will configure a website on WebServ1 to use Integrated Windows authentication. You can publish this website as an additional application through Web Application Proxy to demonstrate how Web Application Proxy uses Kerberos constrained delegation to authenticate users to non-claims-based applications.
Important
You must join the Web Application Proxy server to the Active Directory® Domain Services domain before you can publish applications that use Integrated Windows authentication.

Install Windows Authentication on WebServ1

When you install the Web Server (IIS) role, by default, it does not install the option to use Integrated Windows authentication (referred to by IIS as Windows Authentication). This procedure installs Windows Authentication.

To install Windows Authentication on WebServ1

  1. On the edge server, open Server Manager. To do this, click Server Manager on the Start screen, or Server Manager in the taskbar on the desktop.
  2. In the Quick Start tab of the Welcome tile on the Dashboard page, click Add roles and features. Alternatively, you can click Add Roles and Features on the Manage menu.
  3. In the Add Roles and Features Wizard, click Next three times to get to the server role selection screen.
  4. On the Select server roles dialog, expand Web Server (IIS), expand Web Server, expand Security, select Windows Authentication, and then click Next.
  5. On the Select features dialog, click Next.
  6. On the Confirm installation selections dialog, click Install.
  7. On the Installation progress dialog, verify that the installation was successful, and then click Close.

Create a new website using IIS

The WebServ1 server already hosts a website that uses claims-based authentication. This procedure creates a new website that uses Integrated Windows authentication.

To create a new website

  1. Open an Explorer window and go to C:\inetpub\.
  2. Create a new folder called NonClaims.
  3. Open C:\inetpub\wwwroot\ and copy the contents to the new folder C:\inetpub\NonClaims\.
    Important
    Do not copy the web.config file.
  4. On the Start screen, click the Apps arrow. On the Apps screen, type inetmgr.exe, and then press ENTER.
  5. In the IIS console, in the Connections pane, expand WebServ1, expand Sites, right-click Default Web Site, and then click Add Virtual Directory.
  6. On the Add Virtual Directory dialog box, in the Alias box, type NonClaims.
  7. Next to the Physical Path box, type C:\inetpub\NonClaims, and then click OK.
  8. In the Connections pane, click the NonClaims virtual directory.
  9. In the middle pane, in the IIS section, double-click Authentication.
  10. In the Authentication pane, right-click Anonymous Authentication, and then click Disable. Right-click Windows Authentication, and then click Enable.

Create a non-claims-aware relying party trust

To publish the application through Web Application Proxy, you must first create a non-claims-aware relying party trust on the AD FS server.

To create a non-claims-aware relying party trust

  1. On the AD FS server, in the AD FS Management console, in the left pane, click Trust Relationships.
  2. In the Actions pane, click Add Non-Claims-Aware Relying Party Trust.
  3. In the Add Non-Claims-Aware Relying Party Trust Wizard, on the Welcome page, click Start.
  4. On the Specify Display Name page, in Display name, enter a name for this trust; for example, Non-Claims Application, and then click Next.
  5. On the Configure Identifiers page, in Non-claims-aware relying party trust identifier, enter an arbitrary URL as an identifier for this trust, click Add, and then click Next.
  6. Click Next twice.
  7. On the Finish page, click Close.
    The Edit Claim Rules for dialog box opens.
  8. On the Edit Claim Rules for , click Add Rule.
  9. In the Add Issuance Authorization Claim Rule Wizard, on the Select Rule Template page, in the Claim rule template list, select Permit All Users, and then click Next.
  10. On the Configure Rule page, click Finish, and then on the Edit Claim Rules for dialog box, click OK.

Configure Kerberos constrained delegation

To allow users to access applications that use Integrated Windows authentication, the Web Application Proxy server must be able to provide impersonation for users to the published application.
Tip
This procedure assumes that the Web Application Proxy server is named EDGE1.

To configure Kerberos constrained delegation

  1. On the domain controller, open Server Manager. To do this, click Server Manager on the Start screen, or Server Manager in the taskbar on the desktop.
  2. Click Tools, and then click ADSI Edit.
  3. On the Action menu, click Connect To, and then on the Connection Settings dialog box, accept the default settings to connect to the default naming context, and then click OK.
  4. In the left pane, expand Default naming context, expand DC=contoso,DC=com, expand CN=Computers, right-click CN=EDGE1, and then click Properties.
  5. On the CN=EDGE1 Properties dialog box, on the Attribute Editor tab, in the Attributes list, select servicePrincipalName, and then click Edit.
  6. On the Multi-valued String Editor dialog box, in Value to add, enter HTTP/EDGE1.contoso.com and click Add. Then enter HTTP/EDGE1 and click Add.
    The Values list now contains two new entries; for example, HTTP/EDGE1.contoso.com and HTTP/EDGE1.
  7. On the Multi-valued String Editor dialog box, click OK.
  8. On the CN=EDGE1 Properties dialog box, click OK.
  9. In Server Manager, click Tools, and then click Active Directory Users and Computers.
  10. In the navigation pane, under contoso.com, click Computers. In the details pane, right-click the edge server, and then click Properties.
  11. On the EDGE1 Properties dialog box, on the Delegation tab, click Trust this computer for delegation to specified services only, and then click Use any authentication protocol.
  12. Click Add, and on the Add Services dialog box, click Users or Computers.
  13. On the Select Users or Computers dialog box, in Enter the object names to select, enter the name of the web server; for example, WebServ1, and then click OK.
  14. On the Add Services dialog box, in the Available services list, select the http service type, and then click OK.
  15. On the EDGE1 Properties dialog box, click OK.

Test accessing the application internally

To make sure that the application is working correctly, you should test accessing the application from the Web Application Proxy server before continuing.

To access the application internally

  1. On the Web Application Proxy server, make sure that IE Enhanced Security Configuration is turned off.
  2. Open an Internet explorer window and go to the non-claims-based web application; for example, https://webserv1.contoso.com/nonclaims/.
  3. On the sign in page, enter the credentials of the test user that you created when you set up the environment.
    The default IIS website appears.

Publish the application

You must publish the application through Web Application Proxy to make it available to external users.

To publish the non-claims-based application

  1. On the Edge server, open the Remote Access Management console: On the Start screen, click the Apps arrow. On the Apps screen, type RAMgmtUI.exe, and then press ENTER.
  2. In the navigation pane, under Configuration, click Web Application Proxy.
  3. In the Tasks pane, click Publish.
  4. In the Publish New Application Wizard, on the Welcome page, click Next.
  5. On the Preauthentication page, make sure that Active Directory Federation Services (AD FS) is selected, and then click Next.
  6. On the Relying Party page, select the non-claims application relying party, and then click Next.
  7. On the Publishing Settings page, do the following, and then click Next:
    • In the Name box, enter a friendly name for the application to identify it in the list of published applications; for example, Non-Claims Application.
    • In the External URL box, enter the external URL for this application; for example, https://WebServ1.contoso.com/NonClaims/.
    • In the External certificate list, select a certificate whose subject covers the external address.
    • In the Backend server URL box, the value is entered automatically and is the same as the external URL.
    • In the Backend server SPN box, enter the service principal name for this application; for example, HTTP/WEBSERV1.contoso.com.
  8. On the Confirmation page, click Publish.
  9. On the Results page, click Close.

Test accessing the application

After publishing the application through Web Application Proxy, you can test accessing the application from the simulated Internet.

To test accessing the application

  1. Connect the client computer to the simulated Internet network and assign a static IP address; for example 131.107.0.10.
  2. Open an Internet explorer window and go to the non-claims-based web application; for example, https://webserv1.contoso.com/nonclaims/.
  3. On the sign in page, enter the credentials of the test user that you created when you set up the environment.
    The default IIS website appears.

Step 4: Demonstrate accessing an application using Workplace Join, MFA, and multifactor access control

In this step you will join the client device to the workplace, and configure AD FS to enforce MFA, and multifactor access control when publishing the sample application through Web Application Proxy, and demonstrate that MFA and multifactor access control are working.
Important
For Workplace Join to succeed, the client computer (Client1) must trust the SSL certificate that was used to configure AD FS in Step 2: Configure the federation server (ADFS1) by using Device Registration Service. It must also be able to validate revocation information for the certificate. If you have any issues with Workplace Join, you can view the event log on Client1. To see the event log, open Event Viewer, expand Applications and Services Logs, expand Microsoft , expand Windows and click Workplace Join.

To Workplace Join your device and access the application

  1. On the client computer, on the Start screen, open the Charms bar and then select the Settings charm. Click Change PC Settings.
  2. On the PC Settings page, click Network, and then click Workplace.
  3. In the Enter your UserID to get workplace access or turn on device management box, type **RobertH@contoso.com** and then click Join.
  4. When prompted for credentials, type **roberth@contoso.com**, and enter the password. Click OK.
  5. You should now see the message: This device has joined your workplace network.
  6. Open an Internet explorer window and go to the sample web application; for example, https://webserv1.contoso.com/claimapp/.
  7. On the sign in page, enter the credentials of the test user (RobertH) that you created when you set up the environment.
  8. The application appears in the web browser showing the claims in your security token. Notice that the token contains both user and device claims.

To configure authentication options and attempt to access the application

  1. Configure advanced authentication options such as MFA and user certificate as described in Step 3: Configure MFA on your federation server.
  2. In your lab environment, connect the client computer to the simulated Internet network and assign a static IP address; for example 131.107.0.10.
  3. Open an Internet explorer window and go to the sample web application; for example, https://webserv1.contoso.com/claimapp/.
  4. On the sign in page, enter the credentials of the test user that you created when you set up the environment.
    At this point, because of the MFA policy that you configured, the user will be prompted to undergo additional authentication.
    This demonstrates that the additional authentication factor that you configured is now required to access the application.
Tip
In this walkthrough, it is necessary to disable MFA before configuring multifactor access control.

To configure multifactor access control and attempt to access the application


  1. Configure multifactor access control as described in Step 3: Configure conditional access control policy based on user data.
  2. Disable MFA as follows:
    1. On the AD FS server, in the AD FS Management console, navigate to Authentication Policies/Per Relying Party Trust, and select the relying party trust that represents your sample application.
    2. In the Actions pane, click Edit Custom Multi-factor Authentication.
    3. In the Edit Relying Party Trust for dialog box, in the Users/Groups list, select the test group that you previously added, click Remove, and then click OK.
  3. On the client computer, open an Internet explorer window and go to the sample web application; for example, https://webserv1.contoso.com/claimapp/.
  4. On the sign in page, enter the credentials of the test user that you created when you set up the environment.
    At this point, because of the access control policy that you set up in the previous steps, an ‘access denied’ message is displayed for this user, demonstrating that the access control rule is in effect.
Posted by at
Labels: ,

1 comment:

Subscribe to: Post Comments (Atom)