Configuring Web Application Proxy with AD to future-proof Exchange

To use Web Application Proxy for publishing Exchange to the Internet, admins can ease the process with simple AD and Exchange configurations.

In part one of the series on how to set up and use Web Application Proxy for publishing Exchange to the Internet,...

we covered Active Directory Federation Service's role during the process and how to begin the Web Application Proxy installation. For part two, we'll complete the Web Application Proxy installation and configure Active Directory and Exchange before we publish Exchange to the Internet. 

Figure 1
Figure 1

With our AD FS server ready, we're ready to configure the component that will actually sit within our perimeter network and publish Exchange to the outside world. We'll start by navigating to Add Roles and Features Wizard within Server Manager and selecting Remote Access.  Choose Web Application Proxy on the Server Role Services page. After installation completes, choose Open the Web Application Proxy Wizard.

After the wizard opens, enter the internal name for the AD FS server you've just configured and the administrative credentials. Finally, select the relevant Secure Sockets Layer (SSL) certificate to use for SSL connections to the Web Application Proxy. In our case, we'll use the Wildcard certificate used earlier on our AD FS server (Figure 1).

Configure Active Directory after Web Application Proxy configuration

With the Web Application Proxy configuration complete, it's time to configure Active Directory to pre-authenticate sessions to Outlook Web App (OWA).

We'll need to perform two steps. First, we'll add the Service Principal Names that will specify that WAP is allowed to request Kerberos tokens for HTTP-based requesters. We'll also need to specify that the WAP server is allowed to authenticate requests on behalf of users for our published Exchange servers.

Figure 2
Figure 2

First, open up ADSIEDIT.MSC on an Active Directory domain control and navigate Active Directory to the WAP server using the Default naming context, and choose Properties. Once the attribute editor opens, find the servicePrincipalName attribute. This is a multi-value attribute, which means we can add multiple values to it in addition to those specified by default.

You'll need to add two lines -- one with the fully qualified domain name (FQDN) of the server and one with the NetBIOS name of the server, both of them prefixed by HTTP/. For example, this could look like HTTP/LDJ-WAP01 and LJD-WAP01.lisajanedesigns.local (Figure 2).

After saving those changes, open Active Directory Users and Computers. Find the WAP server in Active Directory and choose Properties. Select the Delegation tab followed by Trust this computer for delegation to specified services only. Select Use any authentication protocol and add your Exchange Server(s) specifying the Service Type as "http."

Configure Exchange for pre-authenticated access

With our Web Application Proxy server ready to publish and the correct configuration in Active Directory, we'll need to ensure Exchange is configured to allow pre-authenticated access using Windows Integrated Authentication for services. In our example, we'll perform pre-authentication against Outlook Web App and the Exchange Control Panel and follow it up by using pass-through authentication for other services.

Open the Exchange Management Console (or the Exchange Admin Center if you're using Exchange 2013) and navigate to the Servers tab. Select the relevant virtual directories under Client Access.

For each virtual directory you'll use pre-authentication against, make sure Integrated Windows Authentication is selected. After reconfiguring the authentication mechanism used for the virtual directories, you'll need to perform iisreset /noforce against each server you havereconfigured.

Publish and test your Exchange configuration

To complete our configuration, we'll open the Remote Access Management Console to publish each service. In this example, we'll publish the services in this table.

Service Path Authentication Type
Outlook Web App /OWA/ AD FS
Exchange Control Panel /ECP/ AD FS
Exchange Web Services /EWS/ Pass thru
Auto Discover /Autodiscover/ Pass thru
ActiveSync /Microsoft-Server-ActiveSync Pass thru
Offline Address Book /OAB/ Pass thru
Outlook Anywhere /rpc/ Pass thru

With the console open, navigate to Configuration > Web Application Proxy and choose Publish. For each pre-authenticated virtual directory, choose Active Directory Federation Services (AD FS) for the pre-authentication type.

Next, we'll be presented with the Relaying Party screen on the wizard. This will show our Non-Claims Application relaying party trust we created earlier. Select this and press Next. We'll be presented with options relevant to publishing the application against the backend Exchange Server itself. Make sure you choose the details carefully here because changing settings using the GUI will involve removing and recreating the settings. In our example, we can enter a friendly description for our reference, like Outlook Web App, and enter the External URL to publish OWA with a trailing slash (/).

Figure 3
Figure 3

Choose the external certificate next. In our example, this means our Wildcard certificate along with the backend server URL. Finally, enter the Service Principal Name for the Exchange server you're publishing. In our example, this is HTTP/ followed by the FQDN of the Exchange server, like: HTTP/LJD-MBX01.lisajanedesigns.local (Figure 3).

After publishing each virtual directory that requires pre-authentication, we'll use the wizard to publish our virtual directories that use pass-through authentication. Therefore, on the pre-authentication page of the wizard, we'll simply choose Pass-through to avoid pre-authentication. Then we'll enter a friendly name to describe the service we're publishing and the external and internal URLs (again with trailing slashes), and select the appropriate SSL certificate.

After publishing each virtual directory, examine the Published Web Applications section of the Remote Access Management Console. You should see the friendly name you've chosen paired with the external URL used to publish the resource.

Figure 4
Figure 4

With everything in place, test what you've put together to make sure it works correctly. Attempt to access OWA from an external computer or one that resolves the DNS names of our published Exchange resources to the WAP server. Upon accessing OWA, you should see the AD FS forms-based authentication login screen (Figure 4).

You should be able to access OWA normally after entering the correct credentials.

To make sure access on all published protocols works as expected, continue testing with tools such as the Remote Connectivity Analyzer to see that services such as Exchange Web Services, ActiveSync and Outlook Anywhere work as expected.

By using Web Application Proxy in combination with AD FS, you have a future-proof option that helps your organization. If your organization chooses to use cloud-based services such as Office 365, you can take advantage of AD FS single sign-on features to smooth the login process against on-premises and cloud services. This will ultimately offer a better end-user experience.

ABOUT THE AUTHOR:  Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.

This was last published in October 2013

Dig Deeper on ISA Server and Firewalls for Microsoft Exchange Server

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

8 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Hi!
I have configured AD FS + WAP with this manual, and can't get it worked.
Receiving error on AD FS server:
Source: AD FS Event ID: 511
General:The incoming sign-in request is not allowed due to an invalid Federation Service configuration.
Request url:
/adfs/ls?version=1.0&action=signin&realm=urn'%'3AAppProxy'%'3Acom&appRealm=99eef496-e43e-e311-9411-00155dfe080e&returnUrl=https'%'3A'%'2F'%'2Fmail.................

And Source: AD FS Event ID: 364
General:Encountered error during federation passive request.
Exception details:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7009: The request was malformed or not valid. Contact your administrator for details.

Can you help?
Cancel
OK!
I misconfigured DNS
All is working fine now!
Cancel
I am having the same error : event 511 and 364 when accessing OWA internally. when coming from the internet OWA works fine. Any ideas?
Cancel
Same issue here, when accessing OWA internally. Did anyone find a solution?
Cancel
The internal authentication is made directly with the ADFS server and does not run through the ADFS Proxy on the WAP server. As the internal and external name of the ADFS server is the same i don´t know how to "avoid" this.
Does anyone know if the external ADFS Proxy address can be changed?
Cancel
Ok. I recreated the ADFS server and used another name for the service than the the actual  servername so i could use at the internal and external DNS the same external IP. 
Now everything works as expected.
Cancel

Have to perform repetitive and mundane tasks which often end up eroding into their productive allows administrators to design templates to manage all Active Directory account creation and modification processes. Moreover, through its web interface allow only authorized users to perform management actions

Cancel
I would expect in this example that the WAP server is in the DMZ, correct?

So, are you recommending that the WAP server is domain joined and in your DMZ/Perimeter network?

Is this design not insecure?
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close