This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies.
Each guide in the Infrastructure Planning and Design (IPD) series addresses a unique infrastructure technology or scenario. These guides include the following topics:
The guides in this series are intended to complement and augment the product documentation.
Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective Microsoft Forefront® Unified Access Gateway technology.
Benefits for Business Stakeholders/Decision Makers:
Benefits for Infrastructure Stakeholders/Decision Makers:
Benefits for Consultants or Partners:
Benefits for the Entire Organization:
Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.
This guide leads the reader step by step through the process of planning a Forefront Unified Access Gateway (Forefront UAG) infrastructure. The guide addresses the following fundamental decisions and tasks:
Before starting the technical design, it's very important to fully understand the business objectives for the project:
The business objectives should be prioritized right at the start of the project so that they are clearly understood and agreed upon between IT and the business.
DirectAccess can provide seamless connectivity experiences for mobile workers when connected to the Internet. DirectAccess enables the mobile workforce to increase their productivity by providing them with the same connectivity experience—whether in or out of the office. Forefront UAG can be used in conjunction with DirectAccess to provide fault tolerance, scalability, and increased management for the DirectAccess infrastructure. In this case, the DirectAccess design should be completed at the same time as the Forefront UAG design, because both Forefront UAG and DirectAccess must be installed on the same server and are configured together using the same interface.
For more information, see:
To limit the scope of the material, the following assumption has been made:
This guide addresses the most common scenarios, decisions, activities, options, tasks, and outcomes. Forefront UAG architecture has well-defined requirements and supported configurations; planning a Forefront UAG infrastructure that incorporates elements beyond this document should be carefully reviewed with Microsoft Support Services to ensure that it will be a supported scenario.
This guide addresses the following decisions and/or activities that need to occur in preparing for Forefront UAG. The three steps below represent the most critical design elements in a well-planned Forefront UAG design:
Some of these items represent decisions that must be made. Where this is the case, a corresponding list of common response options will be presented.
Other items in this list represent tasks that must be carried out. These types of items are addressed because their presence is significant in order to complete the infrastructure design.
The following figure provides a graphical overview of the steps in designing a Forefront UAG infrastructure.
Figure 1. The Forefront UAG infrastructure decision flow
Figure 2 illustrates the relationship between the components that can work together to deliver an edge protection and access solution with Forefront UAG.
Figure 2. Example Forefront UAG Architecture
The components can be designed in many different ways; Figure 2 shows them in a particular implementation for illustrative purposes only.
This guide addresses considerations that are related to planning and designing the following necessary components for a successful Forefront UAG infrastructure:
This guide does not address the following:
In this step, the scope of the Forefront Unified Access Gateway project will be defined and the client requirements will be determined. This will be used to determine the requirements of the client populations that will be included. In addition, the service level expectations for Forefront UAG will be determined so that they can be used to appropriately size and place the infrastructure in later steps.
If an organization is considering multiple implementations of Forefront UAG, it can iterate through this guide for each instantiation.
The output of this step will be used in later steps to determine how many instances of Forefront UAG will be required, and then to design the infrastructure for each of those instances.
Before designing a Forefront UAG infrastructure, an organization needs to determine which parts of its environment to include in the scope. This information will enable planners to know the boundaries for which they are building a solution and, in Step 2, to determine how many instances of Forefront UAG will be required.
Start by defining the populations of clients for which Forefront UAG will provide access. These could be enterprise workstations used by traveling workers, workstations on a partner extranet that access corporate data for order fulfillment, or any client on the Internet if information or services are to be exposed publicly.
This will be used to later determine:
Next, define the corporate resources that those client populations will access through Forefront UAG. The corporate resources may include specific applications, such as Exchange or SharePoint, or the clients may be provided access to the entire corporate network. This will be used to guide the placement of Forefront UAG instances in Step 3; it will also determine which Forefront UAG client components must be installed on the client workstations, if any.
Finally, determine whether DirectAccess will be used by the client populations that are in scope. If so, determine whether the only role of Forefront UAG will be to provide scale-out for a DirectAccess server infrastructure. In that use case, the Forefront UAG client code will not need to be deployed to the client workstations.
Record this information in Table A-1: "Project Scope" in Appendix A: "Job Aids."
Refer to Task 1 in which the scope of the project was determined in order to understand which populations of client workstations will be included. This will determine the location of the Forefront UAG client installations, the number of Forefront UAG instances in Step 2, and the design and placement of Forefront UAG servers in Step 3.
For each population of clients that is in scope, use Table A-1 in Appendix A to record the following information:
Repeat this task for each group of client workstations and record the results in Table A-1 in Appendix A.
If there is a requirement to evaluate client health prior to allowing access, there are two options:
Either option, or both of them, can be used to verify the health of client endpoints connecting to the Forefront UAG server.
If NAP is used, the Forefront UAG server will need to connect to the server running NPS where NAP policies are stored. This will be used to guide placement of the Forefront UAG server instances in Step 3.
Decide if NAP will be used and, if so, record that and the location of the NAP server in Table A-1 in Appendix A.
Ask business stakeholders whether any future changes are planned for the environment that may affect the Forefront UAG design. For example, are any acquisitions or divestitures planned for the environment in which Forefront UAG will be implemented? These could affect the size of the client population and, therefore, the infrastructure sizing.
In this step, the scope of the Forefront UAG project was defined, and the client requirements were determined. This was used to understand the requirements of the in-scope client populations. In addition, the service level expectations for Forefront UAG were determined in order to appropriately size and place the infrastructure in Step 3. Finally, the approach for evaluating endpoint health was decided. Data gathered in this step was recorded in Table A-1 in Appendix A.
In Step 1, the project scope was defined and the user and client populations were identified for inclusion in the project.
This step will be used to decide how many instances of Forefront UAG are required in order to service the needs of the in-scope client population. Only one instance of Forefront UAG can be hosted on a server, so the output of this step will be used in the next step to design the server infrastructure for each instance.
A Forefront UAG instance includes the following:
Separate Forefront UAG instances cannot be integrated, so adding instances to the design decentralizes the infrastructure.
In this task, the number of Forefront UAG instances will be determined and the scope of each instance defined so that the design of the server infrastructure for each instance can be completed in the next step.
Begin with one Forefront UAG instance; then add more instances only if necessary for:
In order to determine whether DirectAccess may be in use, refer to Table A-1 in Appendix A.
Note If applications such as Exchange and SharePoint will be published using Kerberos constrained delegation, the Forefront UAG server and the published Web server must be members of the same domain.
In Table A-2: "Instance and Server Design" in Appendix A, record a name for each instance of Forefront UAG that will be designed, along with the reason for its inclusion in the architecture and the clients that will be assigned to it. This information will be used in Step 3 to design the server infrastructure for each instance.
In this step, the number of Forefront UAG instances required to service the in-scope client population was decided. Only one instance of Forefront UAG can be hosted on a server, so the output of this step will be used in the next step to design the server infrastructure. The data gathered in this step was recorded in Table A-2 in Appendix A.
Now that the number of instances of Forefront UAG has been determined, the server infrastructure must be designed for each instance to meet the requirements for each group of clients listed in Step 1. The scale out and fault-tolerance design for the server infrastructure will be completed, if required, and the data store will be designed.
In this task, the Forefront UAG server will be designed and placed. To understand the load that will be placed on the server and the resources to which it must be connected, it can be useful to review the functions that the server performs:
The Forefront UAG product group provides a recommended server configuration in "System requirements for Forefront UAG servers," available at http://technet.microsoft.com/en-us/library/dd903051.aspx. However, there is no architectural guidance offered to support this recommendation. Performance test data, available in "Forefront UAG DirectAccess performance information," at http://blogs.technet.com/b/edgeaccessblog/archive/2010/06/22/forefront-uag-directaccess-performance-information.aspx provides some guidance on hardware configuration.
The entire Forefront UAG server product is designed to be run on the same server, with the exception of the data store, which can be run on either the Forefront UAG server or a remote server. This is the only supported configuration, and so roles cannot be split out across multiple servers. Forefront UAG is a 64-bit application, so it is able to take advantage of large memory.
The recommended server configuration assumes that the Forefront UAG server and the services on which it may depend (Network Load Balancing, Forefront TMG, SQL Server, and DirectAccess) will run on a dedicated server because sharing the server with other workloads is not supported.
The Forefront UAG server can be run in a virtual machine. If a virtual machine will be used, ensure that it has access to CPU and memory resources equivalent to those specified for a physical machine.
The UAG product group's recommended disk capacity is 2.5 gigabytes (GB), in addition to the requirements of the operating system. However, no architectural guidance is offered to support this recommendation. The number of access policies that must be stored will depend on how many different policies are required for different Forefront UAG clients using the same applications, as well as the number of applications that will be accessed.
Record the server configuration that will be used, and then add it to the design in Table A-2 in Appendix A.
The server will typically be placed in the perimeter network. It should have high-speed network access to the endpoint machines for which it will provide access and to the identity repositories that will be used to authenticate users, such as AD DS, LDAP, and RADIUS. If client certificates will be used, the Forefront UAG server should have access to the certificate revocation information provider.
If Forefront UAG will be used with DirectAccess, both must be installed on the same server. As stated in the previous step, the UAG Network Connector application cannot co-exist with DirectAccess, so plan to implement them on separate servers. In addition, when using DirectAccess, the Forefront UAG server will require public IP addresses and cannot be placed behind a network address translation (NAT) firewall. Refer to the Infrastructure Planning and Design Guide for Direct Access, available at http://go.microsoft.com/fwlink/?LinkId=164151, for further information on these requirements.
Record the location of the Forefront UAG server in Table A-2 in Appendix A.
Refer to the requirements that were determined in Step 1 for fault tolerance and performance of the Forefront UAG instance being planned. Use these requirements to determine whether fault tolerance or additional scale may be required within the instance.
Load balancing of incoming requests can be performed by either of the following:
Note that Forefront UAG is not compatible with failover clustering provided by Windows Server 2008 R2.
No architectural guidance is available for determining the number of servers that will be required in the array, so plan to deploy an initial set of users, monitor performance, and use that as the performance baseline for their workload; then plan the number of servers accordingly.
The array function is implemented by Forefront TMG, which is installed by the Forefront UAG installer. The array members share the same configuration and provide the same set of services. If an array node fails, services can be accessed from another array member. One of the array members is configured as the array manager and holds the configuration for the entire array.
There is no fault-tolerance solution for the array manager. If the array manager fails, clients can continue to use the remaining members of the array, and if necessary, one of those members can be configured as a replacement array manager.
To deploy multiple Forefront UAG servers in an array, all the servers must be domain members.
If fault tolerance will be needed, add it to the design, and record it in Table A-2 in Appendix A.
Decide what type of data store will be used if logging will be enabled. The Forefront UAG server can record information about system usage, user activities, and alerts about security risks. These can be used to troubleshoot Forefront UAG issues, to assist remote users if they encounter problems while accessing the internal resources published by Forefront UAG, and to provide an audit log.
Forefront UAG can log events in the following ways:
If fault tolerance is required, the log files can instead be placed on a clustered file server.
If logging will be enabled, decide what type of data store will be used, and record that in Table A-2 in Appendix A.
No guidance is available from the Forefront UAG product group to determine the size of the data store. The data that can be logged is listed in "SQL Server logging fields" at http://technet.microsoft.com/en-us/library/ee441342.aspx and in "Web proxy log fields" at http://technet.microsoft.com/en-us/library/cc441708.aspx. However, the fields that are actually logged will usually be a subset of these, based on the features of Forefront UAG that are in use.
If the available disk space is exhausted, notification of that will depend on the logging mechanism in use. If the Forefront UAG built-in logging process is used, logs are no longer written to the disk without notification.
A cleanup process is available that can be used to prune the Forefront UAG logs when they reach a configurable size. This is described in "Cleaning up log files" at http://technet.microsoft.com/en-us/library/ee406237.aspx.
Design the Forefront UAG log space to be as large as possible; then monitor the size of the log files that are written during typical use to determine the required space.
Record the size and location of the data store in Table A-2 in Appendix A.
The server infrastructure for each instance was designed in this step. This included determining whether the Network Policy Server and data store will exist on the Forefront UAG server or on a remote server, as well as the type and size of the data store. In addition, the fault-tolerance and scale-out design for the server infrastructure was completed in this step. Data gathered in this step was recorded in Table A-2 in Appendix A.
The Forefront UAG installation program automatically installs a customized version of Forefront TMG. Forefront UAG utilizes many functions that are in Forefront TMG, including the array and the firewall. It also stores the publishing rules for the Forefront UAG portal. If Forefront TMG is uninstalled from a Forefront UAG server, this creates a configuration that Microsoft does not support.
Note that Forefront UAG does not support the stand-alone version of Forefront TMG; the only supported configuration is where Forefront UAG automatically installs its own version of Forefront TMG.
Further information about Forefront TMG's role when used with Forefront UAG is available at http://technet.microsoft.com/en-us/library/ee522953.aspx.
This guide has summarized the critical design decisions, activities, and tasks required to enable a successful design of Microsoft Forefront Unified Access Gateway. It focused on decisions involving:
This was done by leading the reader through the three steps in the decision flow to arrive at a successful design. Where appropriate, the decisions and tasks have been illustrated with typical usage scenarios.
The business objectives should be prioritized at the start of the project so that they are clearly understood and agreed upon between IT and the business.
When the architecture has been designed, a pilot should be conducted before a major rollout begins so that lessons learned can be incorporated back into the design. Refer to the Forefront UAG TechNet library at http://technet.microsoft.com/en-us/library/ff684081.aspx to proceed with the installation.
This guide, when used in conjunction with product documentation, allows organizations to confidently plan the implementation of Forefront UAG.
This section provides job aid examples to record data while planning the Forefront UAG infrastructure.
Step 1. Use the table below to record information relative to the Forefront UAG project scope.
Table A-1. Project Scope
Client population and location
Corporate resources in-scope
Will clients use DirectAccess? (Task 1)
Will Forefront UAG be used ONLY to provide server scale out for DirectAccess?
Fulfillment partners – North America
North America network
Exchange AA01 - AA07
SharePoint tracking system
Table A-1. Project Scope (Continued)
Max # clients in location
Will clients travel between locations?
OS in use
Forefront UAG functionality
Table A-1. Project Scope (Continued)
Authentication method and identity provider
Will client use DirectAccess? (Task 2)
NAP enforcement and NAP server location
Y, New Jersey site
Steps 2 and 3. Use the table below to record information relative to the Forefront UAG server instances and the design of each instance.
Table A-2. Instance and Server Design
Forefront UAG instance name
Reason for design
Forefront UAG servers in instance
Forefront UAG server configuration
Boise call center
2.66 GHz Dual core, 8 GB of RAM
Boise call center
2.66 GHz Dual core, 8 GB of RAM
Boise call center
2.66 GHz Dual core, 8 GB of RAM
Table A-2. Instance and Server Design (Continued)
Forefront UAG server location
Fault tolerance and scale out
Data store type, size, and location
SQL-11, 60 GB, Boise
SQL-11, 60 GB, Boise
SQL-11, 60 GB, Boise
Forefront UAG complements DirectAccess when they are both installed on the same server. Forefront UAG can provide the following services to DirectAccess:
When workstations access the Forefront UAG server using the VPN configuration, by default, communications between clients and the Forefront UAG server are encrypted with Transport Layer Security (TLS), using 128-bit encryption. TLS is an updated version of Secure Sockets Layer (SSL), and both are sometimes referred to as "SSL encryption." This requires that the Forefront UAG server has a server certificate that can be used for TLS/SSL, and that the client computers trust the certification authority (CA) that has issued the server certificate.
When workstations use DirectAccess with Forefront UAG, in addition to a server certificate on the Forefront UAG server, both the Forefront UAG server and all clients will require certificates for the IPsec security associations (SAs). The SAs are created by using Authenticated Internet Protocol (AuthIP), an enhancement of the Internet Key Exchange (IKE) protocol. AuthIP requires both peers (the client and the Forefront UAG server) to have trusted certificates.
Some applications may have additional certificate requirements—for example, publishing Outlook Anywhere by using Forefront UAG requires that the Exchange Client Access Server (CAS) server certificate be installed on the Forefront UAG server.
It is beyond the scope of this guide to fully describe the roles and relationships between all elements of a public key infrastructure (PKI), but in order to determine the strategy for the certification authority, a few key elements must be fully understood.
Each certificate is associated with a public key and a private key. In the case of a server certificate, the server holds the private key and keeps it secret, while the public key is available with the certificate and is provided to the client. The client uses the server's public key to encrypt a small packet and then sends the packet to the server. The server can decrypt this packet using its own private key. This provides the basis for a key exchange in which the two computers securely exchange new, symmetric encryption keys that will be used to encrypt data for the connection.
Before creating and exchanging session keys, the client must trust the server. In order to determine the validity of the server certificate, the client can examine the certificate for a signature. Each certificate has been signed by its issuer (usually a CA, as described below). The CA signs the certificate by encrypting a small attribute by using its secret, private key and including that in the certificate. The client can use the public key of the issuer to decrypt that signature. If the decryption fails, the certificate is fraudulent or damaged.
Each client maintains its own list of trusted issuers. If a certificate signature decrypts properly, it is a valid certificate, but it is only trusted if the issuer is in the list of trusted issuers maintained on the client. (Certificates may also be chained. A root CA issues a certificate to an intermediate CA, which in turn issues one to a server, for example. The root CA must be trusted for any certificate in the chain to be trusted.)
There are three ways to provide certificates to the Forefront UAG server and to enable the client workstations to trust them:
This requires no infrastructure setup and there is no additional cost for the certificates, but every client machine must be configured to trust these certificates. This configuration can require significant work. Each client downloads a copy of the certificate and an administrator adds it to the trusted certificate store.
Due to the administrative overhead, this is usually only a recommended solution in test environments or for very small deployments.
Since the client and the server both already trust the CA, there is no need to manually place a certificate on the client or to change the client's configuration, which can be very convenient. There will normally be a fee for the server certificate.
This approach is often used if unmanaged clients (that is, non-domain–joined clients) will connect to the Forefront UAG environment, and DirectAccess is not used.
Clients, however, must be configured to trust this CA. By default, members of the AD DS forest will automatically trust the Enterprise CA because domain policies will force the root certificate into the Trusted Root CA store on all domain members. If the CA is a stand-alone CA (not part of the AD DS infrastructure), Group Policy can be used to configure domain members to trust the CA. Non-domain members, such as non-managed computers will need to be configured manually.
If DirectAccess will be used, an Enterprise CA should be designed for the organization. This CA can also issue the client certificates required for DirectAccess and IPsec. The domain can be configured so that domain members automatically receive all required certificates.
Microsoft Operations Framework (MOF) offers integrated best practices, principles, and activities to assist an organization in achieving reliable solutions and services. MOF provides guidance to help individuals and organizations create, operate, and support technology services, while helping to ensure the investment in technology delivers expected business value at an acceptable level of risk. MOF's question-based guidance helps to determine what is needed for an organization now, as well as providing activities that will keep the organization running efficiently and effectively in the future.
Use MOF with IPD guides to ensure that people and process considerations are addressed when changes to an organization's technology services are being planned.
Figure D-1. The architecture of Microsoft Operations Framework (MOF) 4.0
The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a continuum of organizational maturity. (For more information, see http://go.microsoft.com/fwlink/?LinkId=229236.) The model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in creating the Infrastructure Optimization Model was to develop a simple way to use a maturity framework that is flexible and can easily be applied as the benchmark for technical capability and business value.
IO is structured around three information technology models: Core Infrastructure Optimization, Application Platform Optimization, and Business Productivity Infrastructure Optimization. According to the Core Infrastructure Optimization Model, Forefront UAG can be used to move an organization from a Standardized to a Dynamic level of maturity, enabling dynamic application access and recovery for desktop applications in the process.
At a Standardized level, the enterprise may use Forefront UAG to assess client health before permitting any access to the corporate network. At the Rationalized level, providing a virtual private network (VPN) is included so that users outside the corporate firewall can securely access different types of resources within the corporate firewall. At the Dynamic level of maturity, only the functions and content for which clients have privileges is exposed, and the client's health and location is used to dynamically modify those privileges.
Figure E-1. Mapping of Forefront Unified Access Gateway technology into the Core Infrastructure Optimization Model