Apples to Apples - Comparing an APM Deployment to TMG
Okay, okay, I drank the Kool-aid. I’m a big fan of Access Policy Manager, (APM) and, full disclosure, an F5 employee. With that said, being a “Windows guy” and coming from a background of working with Threat Management Gateway, (TMG) I have historically been skeptical with regards to the ease at which one can deploy an application, (MS Exchange for example) behind the F5 Big-IP as opposed to TMG. After all, the Big-IP is a “network device” and can be complex with many knobs to turn and levers to pull. Counter that with TMG; a windows-based product that comes with deployment wizards for two of Microsoft’s most popular applications, Exchange and SharePoint. Of course, TMG is easier to configure! Right?….Well, that was before iApps. With the advent of iApps, the process of deploying applications behind the Big-IP has gone from hours to minutes. As organizations start looking for suitable replacements for TMG, F5’s Access Policy Manager is an excellent choice. Aside from providing more advanced features, (hardware-based SSL offloading, layer-7 health monitoring utilizing synthetic transactions, multi-factor authentication, endpoint inspection, etc.), publishing and securing applications, (like MS Exchange) are comparatively easy. So there you have it. Right? No? Okay, so maybe a little convincing is in order. To illustrate my point, let’s take a look at a typical Exchange 2010 deployment process behind TMG as well as the Big-IP with APM. Just a little sip of Kool-Aid, (grape’s my favorite), and away we go. The Playing Field For this side-by-side comparison, I’ve deployed a simple Exchange 2010 environment with a single mailbox server and two Client Access Servers, (CAS). We’ll be providing external access to Outlook Web Access, ActiveSync, and Outlook Anywhere, (RPC over HTTP). To keep it simple and allow TMG to use a single listener and external URL, (APM can handle multiple authentication methods on the same VIP), all three of the services have been configured in Exchange for Basic authentication and the public SSL certificate has been imported into both systems. In addition, both the TMG as well as the Big-IP reside in the perimeter and are not domain-joined. Exchange 2010 Publishing with TMG The following process utilizes TMG’s Exchange Web Client Access publishing wizard. Steps 1 through 6 - Select which client access service to publish, (only one service can be published at a time) and configure connectivity, (load balancing, SSL offload, health monitoring, etc.). With regards to health monitoring, you are limited to one of three options, (HTTP GET, PING request, or a TCP connection). Steps 7 through 12 - Configure the public side of the deployment. This includes the public FQDN, associated IP address(es), and the listener. Since TMG is in the perimeter and not joined to the domain, “LDAP, (Active Directory)” authentication is used. Steps 13 through 15 – Finish up by configuring SSO and authentication delegation. The previous steps are followed to publish Outlook Web Access. You’ll notice on the first step, (see above), each service, (OWA, OA, ActiveSync) must be published separately. In our side-by-side comparison the above wizard was ran three times, (once for each of the three web-based client access methods). The three, (3) completed publishing rules are shown below. Exchange 2010 Publishing with the Big-IP iApp Rather than presenting a series of configuration screens, the Big-IP iApp, (web-based GUI) presents a list of questions. Where appropriate, instructions and commentary are included. All services, (MAPI, OWA, Outlook Anywhere, ActiveSync, Autodiscover, POP3, and IMAP4) can be deployed quickly and simultaneously from one single form. Sections 1 through 3 - Select the Big-IP’s role in the deployment, APM pre-authentication settings, SSL offloading, and routing information. In addition, you may select whether to publish all services on one or multiple virtual servers. Note: The Big-IP VIP, (virtual IPs) and associated virtual servers are equivalent to TMG’s web listener and access rule. Sections 4 and 5 - Select the published IP address, services to be published, identify the CAS servers, and configure health monitoring. As previously mentioned, the Big-IP has the ability to perform synthetic L7 transactions as a part of it’s health monitoring. This ensures that not only is the service reachable but is functioning as well. Sections 6 – Finish by selecting the public FQDN for the deployment after which the completed virtual server and all related elements are created, (including an HTTP redirect virtual server). Final Thoughts While I am biased, (c’mon I work for F5) it’s not my intent to persuade you the reader to select the Big-IP with APM over TMG. Rather, the goal has been to illustrate the ease at which you can publish applications with the Big-IP. With the recent announcement of TMG’s imminent demise administrators are going to need to identify alternatives; coupled with the fact that the Big-IP is already in many environments, Access Policy Manager, (APM) is an excellent choice. Dare I say it? Yes, I dare; APM is the best choice. Additional Links TMG2F5 Series: Publishing Microsoft Exchange Using F5 To Pre-authenticate or Not to Pre-authenticate Pre-authentication with F5 LTMTo Pre-authenticate or Not to Pre-authenticate
I’m bouncing around in the friendly skies, (turbulence sucks!) on my way back from the Microsoft Exchange conference and one question keeps rolling around in my head; how important is pre-authentication? Granted, it may not be a very compelling topic to most but with the recent announcement of TMG’s end-of-life, it’s at least relevant. Along with other remote access / pre-authentication solutions, including F5’s Access Policy Manager, (APM) many organizations from SMBs to large enterprises have utilized Microsoft’s TMG, (Threat Management Gateway) to provide external pre-authentication for a variety of applications such as MS Exchange and SharePoint. In a nutshell, reverse-proxy with pre-authentication, (aka remote access) solutions act as a secure doorway on the perimeter of the organization and prevent un-authenticated and un-trusted traffic from accessing resources residing on the private internal corporate network. Now to be honest, there’s not much debate in my mind around the value provided by pre-authentication at the edge of the Network. However, discontinuing the use of pre-authentication entirely in the light of TMG’s demise was proposed as a possible solution. Disclaimer --> This is not an official Microsoft recommendation but rather the opinion expressed by an individual presenter. It’s also important to mention that while TMG will no longer be offered as a product after December 1, 2012, mainstream support will still continue into 2015 which should give current users sufficient time to investigate and implement alternative solutions, (such as APM). Now with that said, I think it would behoove us all to quickly review some of what remote access solutions provide the organization before we tear the door off its hinges. Isolation of Internal Domain-joined Resources As I already mentioned pre-authentication resides at the perimeter of the organization’s network and provides a layer of security further isolating internal resources from external access. Rather than allowing direct access to the internal resource, (an Exchange CAS server for example), only authenticated and authorized user connections will be able to pass into the corporate LAN. To provide a multi-layered perimeter security solution this functionality can be combined with other security systems such as IPS and layer 7 firewalls. Multi-factor Authentication I’ll leave it up to you the reader to determine the value of multi-factor authentication. Regardless, whether it’s username and password, certificates, hard/soft tokens, pre-defined security questions, adaptive auth, or any of the other various flavors of authentication methods available; many remote access solutions provide a much more secure authentication mechanism than what can be natively found on most applications. This is especially critical when we consider the vast and ever-growing number of devices organizations need to provide access for as a part of doing business. Endpoint Inspection To dovetail onto the previous comment, providing a username and password is simply not enough. In the age of BYOD, (Bring Your Own Device), an organization should not only have confidence in who the user is that’s accessing the corporate resource, (Exchange via ActiveSync for example) but have confidence that the device used to connect, (smartphone, corporate laptop, personal tablet, etc.) adheres to corporate policies. Some remote access solutions provide a means to identify and evaluate the client endpoint as part of the authentication/authorization process. For example, (here comes a shameless plug), utilizing APM on the F5 Big-IP with LTM can provide a means to manage access to corporate resources based upon the device trying to connect as well as ensuring the approved device adheres to corporate policies for such things as AV status, OS versions, patch levels, etc.. A Strategic Point of Control for Application Delivery Pre-authentication / reverse-proxies provide a central point to administer access to multiple applications. Consider the alternatives. Without a reverse-proxy / pre-authentication solution access must be configured and controlled separately at each internal resource. All too often these internal resources, (such as Microsoft Exchange and SharePoint), are administered by different individuals or groups. What’s more, independent access control makes applying corporate security policy consistently a challenge to say the least. On the contrary, implementing an application delivery controller like the F5 Big-IP with Access Policy Manager provides a strategic point of control where corporate applications can be deployed in a secure and consistent manner. End-User Experience It’s not all about security. An application delivery controller that provides, among other things, pre-authentication can improve the user experience. Deploying applications behind the Big-IP with APM can provide single sign-on access as well as advanced application delivery. For example, once authenticated at the Big-IP users can access various corporate applications such as SharePoint and Exchange, often from a single namespace, while only needing to provide credentials once and often from a single namespace. Latest F5 Information F5 News Articles F5 Press Releases F5 Events F5 Web Media F5 Technology Alliance Partners F5 YouTube Feed
New Deployment Guides
#devops #iApps #v11 Traffic flow diagrams, worksheets, checkpoints, next steps, oh my! F5 was first in the industry to offer our customers deployment guidance for mission critical applications based on vendor best practices, and we have continued to do so for nearly a decade. To complement our iApp templates, we have been busy updating these deployment guides to provide users with more detailed solution information to help them succeed in planning, troubleshooting and deploying their applications. The first change is the addition of traffic flow diagrams. Below is an example from our SharePoint 2010 guide that illustrates a step by step end-user transaction. This information is not only helpful to put the solution into context; it also provides valuable information to administrators for provisioning other networking services and troubleshooting. The next change to our guides is the inclusion of a preparation worksheet. The worksheet outlines application information, unique to each environment that is required to complete the iApp template. These allow the administrator to more easily plan and gather needed information from other groups prior to configuration, resulting in faster deployment. Configuration checkpoints and troubleshooting steps have also been added for more complicated deployments. With these, we instruct the administrator to validate their configuration at critical points to ensure they have been successful and provide troubleshooting steps to resolve common errors. And finally we have added a Next Steps section to our guides that remind the administrator of details outside their ADC configuration that may be necessary to complete their installation.
