Step 2: Plan the Web Application Proxy Server

  • Article

Updated: August 26, 2013

Applies To: Windows Server 2012 R2

The next step of planning for an Web Application Proxy deployment is to perform planning for the Web Application Proxy server.

Task Description

2.1. Plan the Web Application Proxy Role Service Installation

Plan the additional server roles that will be installed on the Web Application Proxy server.

2.2. Plan Multiple Servers

Plan adding additional servers to your deployment to create a multiple server Web Application Proxy deployment.

2.3. Plan Certificates

Plan the location, names, and issuers of certificates required by Web Application Proxy.

2.4. Plan NTP

Plan the time synchronization for claims in your deployment.

2.1. Plan the Web Application Proxy Role Service Installation

The following table describes the supported Remote Access role service deployments.

DirectAccess VPN Web Application Proxy

Single server deployment

Single server deployment

Single server deployment

Multisite deployment

Multiple server deployment

Not supported on the same server

Not supported on the same server

Multiple server deployment

Multiple server deployment

Cluster deployment1

Multiple server deployment

Multiple server deployment2

Note

1—In a pre-existing DirectAccess cluster deployment, you can install Web Application Proxy only using Windows PowerShell.

2—In a pre-existing multiple server Web Application Proxy deployment, you can install DirectAccess only using Windows PowerShell.

Important

If you deploy DirectAccess and Web Application Proxy on the same server, you cannot use a read-only domain controller.

You can deploy the Web Application Proxy role service on a server that is also running the Internet Information Services (IIS) role. However, in this type of deployment, you must make sure that IIS is configured to only listen, or be bound, to URLs that are not configured as external URLs on Web Application Proxy.

2.2. Plan Multiple Servers

The Web Application Proxy configuration is stored on the AD FS servers in your organization. After configuring the first Web Application Proxy server, you can install additional Web Application Proxy servers to create a multiple server deployment. When you install the role service on the new server in the multiple server deployment, the configuration is automatically transferred to the new server after completing the Web Application Proxy Configuration Wizard.

2.3. Plan Certificates

The following table describes the certificates that are required when deploying Web Application Proxy, and any other requirements when using those certificates.

Certificate purpose and location1 Certificate issuer2 Notes

Server authentication for the Web Application Proxy server.

Import the certificate to the Personal Certificates store on all Web Application Proxy servers.

Public CA

  • For clients to be able to connect to published web applications using HTTPS, Web Application Proxy must present a certificate that is trusted by clients. Because clients are not required to be included in your PKI, this usually requires you to acquire a certificate from an external certification authority (CA).

  • It is not recommended to use an Enterprise CA if users are allowed to use their own devices to access published applications.

  • You can use single name certificates, subject alternative name (SAN) certificates, or wildcard certificates.

  • You may require more than one certificate to successfully publish all the required applications.

Enterprise CA (internal)

Server authentication for the federation server.

Import the certificate to the Personal Certificates store on all Web Application Proxy servers.

Public CA

This certificate is required for AD FS proxy functionality.

  • The subject of this certificate must match the Federation Service name value that is specified in the AD FS Management console. 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.

  • For Workplace Join, the certificate must have the following subject alternative names (SANs):

    • <federation service name>.<domain>

      For example, adfs1.contoso.com.

    • enterpriseregistration.<domain>

      For example, enterpriseregistration.contoso.com.

            > [!NOTE]
            > Only one certificate is required for server authentication for the federation server.
            > <P></P>


            <p>
              
            </p>
          </div>
        </td>
      </tr>
      <tr>
        <td>
          <p>Enterprise CA (internal)</p>
        </td>
      </tr>
    </table>

Note

1—If any certificate that you use has certificate revocation lists (CRLs), the server with the configured certificate must be able to contact the server that distributes the CRLs; the CRL distribution point (CDP). Clients must be able to reach the CDP. The type of CRL determines what ports are used.

2—In all cases, the client must trust the issuing CA and any intermediate CAs.

2.4. Plan NTP

When using AD FS preauthentication, the time of all Web Application Proxy servers must be identical to the time of the AD FS servers so that the timestamps on claims match. The time of all Web Application Proxy servers must be identical to the time of the applications servers when using Kerberos constrained delegation. It is recommended to enable Network Time Protocol (NTP) on all Web Application Proxy and AD FS servers.

See also