Book Image

Microsoft Forefront UAG 2010 Administrator's Handbook

By : Erez Ben-Ari, Ran Dolev, Erez Y Ben
Book Image

Microsoft Forefront UAG 2010 Administrator's Handbook

By: Erez Ben-Ari, Ran Dolev, Erez Y Ben

Overview of this book

Microsoft Forefront Unified Access Gateway (UAG) is the latest in a line of Application Publishing (Reverse Proxy) and Remote Access (VPN) Server products. The broad set of features and technologies integrated into UAG makes for a steep learning curve. Understanding all the features and abilities of UAG is a complex task that can be daunting even to experienced networking and security engineers. This book is the first to be dedicated solely to Microsoft Forefront UAG. It guides you step-by-step throughout all the stages of deployment, from design to troubleshooting. Written by the absolute experts who have taken part of the product’s development, official training and support, this book covers all the primary features of UAG in a friendly style and a manner that is easy to follow. It takes you from the initial planning and design stage, through deployment and configuration, up to maintenance and troubleshooting. The book starts by introducing UAG's features and and abilities, and how your organization can benefit from them. It then goes on to guide you through planning and designing the integration of the product into your own unique environment. Further, the book guides you through the process of publishing the various applications, servers and resources - from simple web applications to complex client/server based applications. It also details the various VPN technologies that UAG provides and how to take full advantage of them. The later chapters of the book educate you with common routine “upkeep” tasks like monitoring, backup and troubleshooting of common issues. Finally, the book includes an introduction to ASP, which some of the product's features are based on, and can help the advanced administrator with enhancing and customizing the product.
Table of Contents (21 chapters)
Microsoft Forefront UAG 2010 Administrator's Handbook
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Considerations for placing the server


We assume a network administrator does not need this book to learn how to physically secure a server, but there is one hardware aspect that should be kept in mind. Many organizations place their servers in a secure location – a dedicated server room (a.k.a. The Dungeon), which is sometimes even isolated from the main company campus. This is not a bad practice, but keep in mind that during installation, remote-desktop connection to the server might be disconnected, so it's worthwhile to keep an option to reach the server physically. Another thing that's good to keep in mind is that UAG is designed to serve clients connecting from outside the organization, and so using it from "inside" is unsupported and will not work for the most part. Some features can be tested from the internal network, and some can even be tested by launching a browser on the server itself, but we strongly recommend that any organization plan for a "real" test client.

Note

Installing the UAG client components on the UAG server itself, by using Internet Explorer on the UAG server and browsing to a UAG portal and allowing the installation of these components, can lead to undesired results. A real test client would be just a regular computer that is physically connected (either permanently or when needed) to an external NIC on the UAG machine, or to the same switch the Server is connected to on the external interface, and dedicated to being used to test the server, if a need arises. This is pretty easy to accomplish if the UAG server is a Virtual Machine, but even if it isn't and it sounds a little dumb to "waste" a computer or a switch port just for that, do it! It could save you hours and hours of frustration if the server experiences a problem. For example, if the organization decides to place an external Load Balancer in front of the server, you might have a tough time knowing to which server your test clients are connecting, but such a standalone client could eliminate that problem easily. If you are able to dedicate a reasonably strong machine for this, it would be even better to run several client Virtual Machine guest OSs on it, and thus be able to quickly test various scenarios.

From a networking perspective, placing is even more important. Most organizations place the server in their DMZ, and have one firewall in front of it, and another behind it. This is not a bad idea, even though UAG does include its own robust firewall – TMG. Regardless, if any additional networking hardware is in the picture, care must be taken to allow the right traffic to flow. The frontend firewall needs to allow traffic to the UAG server's external IP from any IP, and allow ports 443 for Secure portal trunks, and port 80 for non-secure trunks or HTTP to HTTPS redirection trunk (those are used when the portal is on HTTPS, but you want to avoid forcing your users to type the elusive 'https' prefix to the URL).

The backend firewall needs to be configured to allow UAG to communicate with whatever servers it needs to publish, as well as traffic to its domain controllers, and to the authentication servers used by UAG to authenticate end-users. In some scenarios that require the use of digital certificates, access to a Certificate Authority is also required. Keep in mind that if UAG is used to publish non-HTTP or non-HTTPS servers, additional ports may need to be opened. For example, if RDP access to internal servers is required, port 3389 needs to be allowed.

If load balancers are to be part of this dance, it introduces quite a few other considerations. For example, how is stickiness going to be preserved? Different load balancers have different mechanisms, and those need to be accounted for to make sure that once a user has connected to a UAG array member, they will not be handed off to another one, mid-session. UAG's session information is not shared across members of a UAG array, so if that happens, the user will be redirected to login again, and depending on what they were doing, may lose data.

Another important consideration to take into account is DNS. Clients that are connecting to UAG from the public internet will need to connect to the server using a host name, and not an IP address. Depending on an organization's DNS hierarchy and server placement, this may affect the deployment. This is especially true if SharePoint servers are to be published, as they require their own additional DNS mapping (more about that in Chapter 4). The UAG server needs to be able to resolve internal hostnames, so Port 53 needs to be open on the internal firewall, if one exists. If load balancing, either front or back, is done, the effect it has needs to be planned as well, to make sure UAG has access to all the relevant internal servers.