Menu
Web Application Proxy and AD FS on AWS
Web Application Proxy and AD FS Quick Start

Appendix: Publishing Outlook Web App to the Internet with AD FS Pre-Authentication

Instead of using the nested AWS CloudFormation template to launch a new environment, you can use the Web Application Proxy and AD FS template included with this Quick Start to launch the components into an existing VPC.

Important

The sub-template for Web Application Proxy and AD FS provided with this guide is built to work with existing VPCs that have two public and two private subnets, and an existing Active Directory Domain Services implementation. More specifically, it is designed to work with the existing Microsoft-based AWS Quick Starts, such as Exchange Server, SharePoint Server, and Lync Server.

In this appendix, we'll show you how to launch the Web Application Proxy and AD FS infrastructure on top of the Exchange Server Quick Start. Then we'll walk-through the steps to publish Outlook Web App (OWA) to the Internet using Web Application Proxy and AD FS.

Note

This walkthrough details the process of publishing OWA using Integrated Windows authentication. You can follow the same general process for Exchange Server 2010, or other web applications you want to publish with Integrated Windows authentication. It is also possible to publish OWA with claims-based authentication using Exchange Server 2013 SP1, but that scenario is beyond the scope of this guide.

  1. Launch the Exchange Server Quick Start.

  2. Once the Exchange Server 2013 stack has been created successfully, launch the Web Application Proxy and AD FS template. As shown previously in this guide, you'll need to specify the KeyPairName for your chosen region. Additionally, you'll need to specify the IDs for your existing VPC and for the public and private subnets.

  3. Initiate a Remote Desktop Protocol (RDP) connection to one of the RD Gateway instances. You can retrieve the Elastic IP for the RD Gateway servers in the Amazon EC2 console. From there, use RDP to connect to the EXCH1 server.

  4. On EXCH1, navigate to the Exchange Admin Center (https://exch1/ecp) in a web browser. Sign in by using the stackadmin user account and password you specified when building the stack.

    
          Logging into the Exchange Admin Center

    Figure 5: Logging into the Exchange Admin Center

  5. In the left pane, choose Servers, Virtual directories.

    
          Viewing the virtual directories on EXCH1

    Figure 6: Viewing the virtual directories on EXCH1

  6. Double-click owa (Default Web Site) on the EXCH1 server. Choose Authentication, Integrated Windows authentication, and then choose Save. You should also change the corresponding setting on the ECP virtual directory on EXCH1.

    
          Setting OWA authentication to Integrated Windows

    Figure 7: Setting OWA authentication to Integrated Windows

    Note

    In a load-balanced production environment, you would modify this setting on each Exchange server that is running the Client Access role.

  7. Establish an RDP connection to the ADFS1 server. In Control Panel, choose Administrative Tools, and then launch the ADFS Management snap-in.

  8. Open the context (right-click) menu for Trust Relationships, and then choose Add Non-Claims-Aware Relying Party Trust to start the wizard.

    
          Adding a non-claims-aware relying party trust

    Figure 8: Adding a non-claims-aware relying party trust

  9. On the welcome page of the wizard, choose Start, and type a display name such as OWA. Provide a unique identifier string for the non-claims-aware relying party trust. Use the default service name created by the Quick Start (e.g., http://sts.example.com/adfs/services/trust) for the URL.

  10. Indicate that you do not want to configure multi-factor authentication, and then choose Next.

  11. Go through the remaining screens without making changes. On the final screen, leave the Open the Edit Issuance Authorization Rules option selected, and then choose Close.

  12. On the Edit Claim Rules screen, choose Add Rule, Permit Access to All Users, and then choose Finish.

  13. Establish an RDP connection to the WAP1 server. In Control Panel, choose Administrative Tools, and then launch the Remote Access Management snap-in.

    
          Viewing the Remote Access Management console

    Figure 9: Viewing the Remote Access Management console

    To publish OWA to the Internet, you'll need to create two rules. The first rule will be a pass-through authentication rule to the AD FS server. This will allow users to pre-authenticate before being connected to OWA.

  14. Under Tasks, choose Publish.

  15. On the Welcome screen, choose Next. On the Preauthentication tab, choose Pass-through.

    
          Selecting the pass-through pre-authentication method

    Figure 10: Selecting the pass-through pre-authentication method

  16. Provide a name such as ADFS for the rule. Specify the external URL, the external certificate, and the back-end server URL as shown in Figure 11.

    
          Configuring the publishing rule

    Figure 11: Configuring the publishing rule

    Note

    If you've implemented internal load balancing for the AD FS tier, you can set the back-end server URL to a load-balanced endpoint instead of an individual server name.

  17. Choose Publish, and then Close to exit the wizard.

  18. Choose Publish again to create a new rule for OWA. This time, set the pre-authentication method to Active Directory Federation Services (AD FS), and then choose Next.

    
          Selecting the AD FS pre-authentication method

    Figure 12: Selecting the AD FS pre-authentication method

  19. For the relying party for the application, select the relying party trust you created on the AD FS server, and then choose Next.

    
          Selecting the relying party

    Figure 13: Selecting the relying party

  20. Provide a name such as OWA for the rule. Specify the external URL, external certificate, back-end URL, and service principal name (SPN) for the back-end server, as shown in Figure 14.

    
          Configuring rule details

    Figure 14: Configuring rule details

    Note

    If you've implemented internal load balancing for the Exchange client access tier, you can set the back-end server URL and SPN to a load-balanced endpoint instead of an individual server name.

  21. Choose Publish and close the wizard.

  22. Establish an RDP connection to DC1. In Control Panel, choose Administrative Tools, and then launch the Active Directory Users and Computers snap-in.

  23. Navigate to the Computers container, right-click the WAP1 computer, and choose Properties. On the Delegation tab, choose Trust this computer for delegation to specified services only. Check the option to use any authentication protocol, and add the HTTP service type on the EXCH1 computer to the list, as shown in Figure 15. Choose Apply, and then choose OK.

    
          Configuring Kerberos constrained delegation

    Figure 15: Configuring Kerberos constrained delegation

    Now you are ready to test accessing OWA from an external workstation or server over the Internet.

  24. If you did not use your own domain name, you'll need to edit the hosts file on your machine to allow your computer to resolve the endpoints at example.com: Add a mapping for sts.example.com and mail.example.com to your local hosts file, making sure that both hosts resolve to the public EIP of the WAP1 server.

  25. Open a web browser from your external workstation or server. Navigate to mail.example.com. You should be redirected to the federation service and prompted for authentication. Provide the stackadmin user name and password, and then choose Sign in.

    
          Pre-authenticating to AD FS

    Figure 16: Pre-authenticating to AD FS

    If the authentication is successful, the connection should be proxied to the EXCH1 server through the Web Application Proxy, as shown in Figure 17.

    
          Connected to the published application

    Figure 17: Connected to the published application