Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
Just like the early settlers who migrated en masse across the country by wagon train along the Oregon Trail, enterprises are migrating up into the cloud. Well okay, maybe not exactly like the early settlers. But, although there may not be a mass migration to the cloud, it is true that more and more enterprises are moving to cloud-based services like Office 365. So how do you provide seamless, or at least relatively seamless, access to resources outside of the enterprise? Well, one answer is federation and if you are a Microsoft shop then the current solution is ADFS, (Active Directory Federation Services). The ADFS server role is a security token service that extends the single sign-on, (SSO) experience for directory-authenticated clients to resources outside of the organization’s boundaries. As cloud-based application access and federation in general becomes more prevalent, the role of ADFS has become equally important. Below, is a typical deployment scenario of the ADFS Server farm and the ADFS Proxy server farm, (recommended for external access to the internally hosted ADFS farm). Warning…. If the ADFS server farm is unavailable then access to federated resources will be limited if not completely inaccessible. To ensure high-availability, performance, and scalability the F5 Big-IP with LTM, (Local Traffic Manager), can be deployed to load balance the ADFS and ADFS Proxy server farms. Yes! When it comes to a load balancing and application delivery, F5’s Big-IP is an excellent choice. Just had to get that out there. So let’s get technical! Part one of this blog series addresses deploying and configuring the Big-IP’s LTM module for load balancing the ADFS Server farm and Proxy server farm. In part two I’m going to show how we can greatly simplify and improve this deployment by utilizing Big-IP’s APM, (Access Policy Manager) so stay tuned. Load Balancing the Internal ADFS Server Farm Assumptions and Product Deployment Documentation - This deployment scenario assumes an ADFS server farm has been installed and configured per the deployment guide including appropriate trust relationships with relevant claims providers and relying parties. In addition, the reader is assumed to have general administrative knowledge of the BIG-IP LTM module. If you want more information or guidance please check out F5’s support site, ASKF5. The following diagram shows a typical, (albeit simplified) process flow of the Big-IP load balanced ADFS farm. Client attempts to access the ADFS-enabled external resource; Client is redirected to the resource’s applicable federation service; Client is redirected to its organization’s internal federation service, (assuming the resource’s federation service is configured as trusted partner); The ADFS server authenticates the client to active directory; The ADFS server provides the client with an authorization cookie containing the signed security token and set of claims for the resource partner; The client connects to the resource partner federation service where the token and claims are verified. If appropriate, the resource partner provides the client with a new security token; and The client presents the new authorization cookie with included security token to the resource for access. VIRTUAL SERVER AND MEMBER POOL – A virtual server, (aka VIP) is configured to listen on port 443, (https). In the event that the Big-IP will be used for SSL bridging, (decryption and re-encryption), the public facing SSL certificate and associated private key must be installed on the BIG-IP and associated client SSL profile created. However, as will be discussed later SSL bridging is not the preferred method for this type of deployment. Rather, SSL tunneling, (pass-thru) will be utilized. ADFS requires Transport Layer Security and Secure Sockets Layer (TLS/SSL). Therefore pool members are configured to listen on port 443, (https). LOAD BALANCING METHOD – The ‘Least Connections (member)’ method is utilized. POOL MONITOR – To ensure the AD FS service is responding as well as the web site itself, a customized monitor can be used. The monitor ensures the AD FS federation service is responding. Additionally, the monitor utilizes increased interval and timeout settings. The custom https monitor requires domain credentials to validate the service status. A standard https monitor can be utilized as an alternative. PERSISTENCE – In this AD FS scenario, clients establish a single TCP connection with the AD FS server to request and receive a security token. Therefore, specifying a persistence profile is not necessary. SSL TUNNELING, (preferred method) – When SSL tunneling is utilized, encrypted traffic flows from the client directly to the endpoint farm member. Additionally, SSL profiles are not used nor are SSL certificates required to be installed on the Big-IP. In this instance Big-IP profiles requiring packet analysis and/or modification, (ex. compression, web acceleration) will not be relevant. To further boost the performance, a Fast L4 virtual server will be used. Load Balancing the ADFS Proxy Server Farm Assumptions and Product Deployment Documentation - This deployment scenario assumes an ADFS Proxy server farm has been installed and configured per the deployment guide including appropriate trust relationships with relevant claims providers and relying parties. In addition, the reader is assumed to have general administrative knowledge of the BIG-IP LTM module. If you want more information or guidance please check out F5’s support site, ASKF5. In the previous section we configure load balancing for an internal AD FS Server farm. That scenario works well for providing federated SSO access to internal users. However, it does not address the need of the external end-user who is trying to access federated resources. This is where the AD FS proxy server comes into play. The AD FS proxy server provides external end-user SSO access to both internal federation-enabled resources as well as partner resources like Microsoft Office 365. Client attempts to access the AD FS-enabled internal or external resource; Client is redirected to the resource’s applicable federation service; Client is redirected to its organization’s internal federation service, (assuming the resource’s federation service is configured as trusted partner); The AD FS proxy server presents the client with a customizable sign-on page; The AD FS proxy presents the end-user credentials to the AD FS server for authentication; The AD FS server authenticates the client to active directory; The AD FS server provides the client, (via the AD FS proxy server) with an authorization cookie containing the signed security token and set of claims for the resource partner; The client connects to the resource partner federation service where the token and claims are verified. If appropriate, the resource partner provides the client with a new security token; and The client presents the new authorization cookie with included security token to the resource for access. VIRTUAL SERVER AND MEMBER POOL – A virtual server is configured to listen on port 443, (https). In the event that the Big-IP will be used for SSL bridging, (decryption and re-encryption), the public facing SSL certificate and associated private key must be installed on the BIG-IP and associated client SSL profile created. ADFS requires Transport Layer Security and Secure Sockets Layer (TLS/SSL). Therefore pool members are configured to listen on port 443, (https). LOAD BALANCING METHOD – The ‘Least Connections (member)’ method is utilized. POOL MONITOR – To ensure the web servers are responding, a customized ‘HTTPS’ monitor is associated with the AD FS proxy pool. The monitor utilizes increased interval and timeout settings. "To SSL Tunnel or Not to SSL Tunnel” When SSL tunneling is utilized, encrypted traffic flows from the client directly to the endpoint farm member. Additionally, SSL profiles are not used nor are SSL certificates required to be installed on the Big-IP. However, some advanced optimizations including HTTP compression and web acceleration are not possible when tunneling. Depending upon variables such as client connectivity and customization of ADFS sign-on pages, an ADFS proxy deployment may benefit from these HTTP optimization features. The following two options, (SSL Tunneling and SSL Bridging) are provided. SSL TUNNELING - In this instance Big-IP profiles requiring packet analysis and/or modification, (ex. compression, web acceleration) will not be relevant. To further boost the performance, a Fast L4 virtual server will be used. Below is an example of the Fast L4 Big-IP Virtual server configuration in SSL tunneling mode. SSL BRIDGING – When SSL bridging is utilized, traffic is decrypted and then re-encrypted at the Big-IP device. This allows for additional features to be applied to the traffic on both client-facing and pool member-facing sides of the connection. Below is an example of the standard Big-IP Virtual server configuration in SSL bridging mode. Standard Virtual Server Profiles - The following list of profiles is associated with the AD FS proxy virtual server. Well that’s it for Part 1. Along with the F5 business development team for the Microsoft global partnership I want to give a big thanks to the guys at Ensynch, an Insight Company - Kevin James, David Lundell, and Lutz Mueller Hipper for reviewing and providing feedback. Stay tuned for Big-IP and ADFS Part 2 – “APM – An Alternative to the ADFS Proxy”. Additional Links: Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy” Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients”Big-IP and ADFS Part 2 - APM: An Alternative to the ADFS Proxy
So let’s talk Application Delivery Controllers, (ADC). In part one of this series we deployed both an internal ADFS farm as well as a perimeter ADFS proxy farm using the Big-IP’s exceptional load balancing capabilities to provide HA and scalability. But there’s much more the Big-IP can provide to the application delivery experience. Here in part 2 we’ll utilize the Access Policy Manager, (APM) module as a replacement for the ADFS Proxy layer. To illustrate this approach, we’ll address one of the most common use cases; ADFS deployment to federate with and enable single sign-on to Microsoft Office 365 web-based applications. The purpose of the ADFS Proxy server is to receive and forward requests to ADFS servers that are not accessible from the Internet. As noted in part one, for high availability this typically requires a minimum of two proxy servers as well as an additional load balancing solution, (F5 Big-IPs of course). By implementing APM on the F5 appliance(s) we not only eliminate the need for these additional servers but, by implementing pre-authentication at the perimeter and advanced features such as client-side checks, (antivirus validation, firewall verification, etc.), arguably provide for a more secure deployment. Assumptions and Product Deployment Documentation - This deployment scenario assumes the reader is assumed to have general administrative knowledge of the BIG-IP LTM module and basic understanding of the APM module. If you want more information or guidance please check out F5’s support site, ASKF5. The following diagram shows a typical internal and external client access AD FS to Office 365 Process Flow, (used for passive-protocol, “web-based” access). Both clients attempts to access the Office 365 resource; Both clients are redirected to the resource’s applicable federation service, (Note: This step may be skipped with active clients such as Microsoft Outlook); Both client are redirected to their organization’s internal federation service; The AD FS server authenticates the client to active directory; * Internal clients are load balanced directly to an ADFS server farm member; and * External clients are: * Pre-authenticated to Active Directory via APM’s customizable sign-on page; *Authenticated users are directed to an AD FS server farm member. The ADFS server provides the client with an authorization cookie containing the signed security token and set of claims for the resource partner; The client connects to the Microsoft Federation Gateway where the token and claims are verified. The Microsoft Federation Gateway provides the client with a new service token; and The client presents the new cookie with included service token to the Office 365 resource for access. Virtual Servers and Member Pool – Although all users, (both internal and external) will access the ADFS server farm via the same Big-IP(s), the requirements and subsequent user experience differ. While internal authenticated users are load balanced directly to the ADFS farm, external users must first be pre-authenticated, (via APM) prior to be allowed access to an ADFS farm member. To accomplish this two, (2) virtual servers are used; one for the internal access and another dedicated for external access. Both the internal and external virtual servers are associated with the same internal ADFS server farm pool. INTERNAL VIRTUAL SERVER – Refer to Part 1 of this guidance for configuration settings for the internal ADFS farm virtual server. EXTERNAL VIRTUAL SERVER – The configuration for the external virtual server is similar to that of the virtual server described in Part 1 of this guidance. In addition an APM Access Profile, (see highlighted section and settings below) is assigned to the virtual server. APM Configuration – The following Access Policy Manager, (APM) configuration is created and associated with the external virtual server to provide for pre-authentication of external users prior to being granted access to the internal ADFS farm. As I mentioned earlier, the APM module provides advanced features such as client-side checks and single sign-on, (SSO) in addition to pre-authentication. Of course this is just the tip of the iceberg. Take a deeper look at client-side checks at AskF5. AAA SERVER - The ADFS access profile utilizes an Active Directory AAA server. ACCESS POLICY - The following access policy is associated with the ADFS access profile. * Prior to presenting the logon page client machines are checked for the existence of updated antivirus. If the client lacks either antivirus software or does not have updated, (within 30 days) virus definitions the user is redirected to a mitigation site. * An AD query and simple iRule is used to provide single-url OWA access for both on-premise and Office365 Exchange users. SSO CONFIGURATION - The ADFS access portal uses an NTLM v1 SSO profile with multiple authentication domains, (see below). By utilizing multiple SSO domains, clients are required to authenticate only once to gain access to both hosted applications such as Exchange Online and SharePoint Online as well as on-premise hosted applications. To facilitate this we deploy multiple virtual servers, (ADFS, Exchange, SharePoint) utilizing the same SSO configuration. CONNECTIVITY PROFILE – A connectivity profile based upon the default connectivity profile is associated with the external virtual server. Whoa! That’s a lot to digest. But if nothing else, I hope this inspires you to further investigate APM and some of the cool things you can do with the Big-IP beyond load balancing. Additional Links: Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm” Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients” BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki Latest F5 Information F5 News Articles F5 Press Releases F5 Events F5 Web Media F5 Technology Alliance Partners F5 YouTube FeedTo 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 FeedBig-IP and ADFS Part 4 – “What about Single Sign-Out?”
Why stop at 3 when you can go to 4? Over the past few posts on this ever-expanding topic, we’ve discussed using ADFS to provide single sign-on access to Office 365. But what about single sign-out? A customer turned me onto Tristan Watkins’ blog post that discusses the challenges of single sign-out for browser-based, (WS-Federation) applications when fronting ADFS with a reverse-proxy. It’s a great blog post and covers the topic quite well so I won’t bother re-hashing it here. However, I would definitely recommend reading his post if you want a deeper dive. Here’s the sign-out process: 1. User selects ‘Sign Out’ or ‘Sign in as Different User’, (if using SharePoint Online); 2. The user is signed out of the application; 3. The user is redirected to the ADFS sign out page; and 4. The user is redirected back to the Microsoft Federation Gateway and the user’s tokens are invalidated. In a nutshell, claims-unaware proxies, (Microsoft ISA and TMG servers for example) are unable to determine when this process has occurred and subsequently the proxy session remains active. This in turn will allow access to ADFS, (and subsequently Office 365) without be prompted for new credentials, (not good!). Here’s where I come clean with you dear readers. While the F5 Big-IP with APM is a recognized replacement for the AD FS 2.0 Federation Server Proxy this particular topic was not even on my radar. But now that it is…… Single Sign-Out with Access Policy Manager You’ll may have noticed that although the Big-IP with APM is a claims-unaware proxy I did not include it in the list above. Why you ask? Well, although the Big-IP is currently “claims-unaware”, it certainly is “aware” of traffic that passes through. With the ability to analyze traffic as it flows from both the client and the server side, the Big-IP can look for triggers and act upon them. In the case of the ADFS sign-out process, we’ll use the MSISSignOut cookie as our trigger to terminate the proxy session accordingly. During the WS-Federation sign out process, (used by browser-based applications) the MSISSignOut cookie is cleared out by the ADFS server, (refer to the HttpWatch example below). Once this has been completed, we need to terminate the proxy session. Fortunately, there’s an iRule for that. The iRule below analyzes the HTTP response back from the ADFS server and keys off of the MSISSignOut cookie. If the cookie’s value has been cleared, the APM session will be terminated. To allow for a clean sign-out process with the Microsoft Federation Gateway, the APM session termination is delayed long enough for the ADFS server to respond. Now, APM’s termination can act in concert with the ADFS sign-out process. 1: when HTTP_RESPONSE { 2: # Review server-side responses for reset of WS-Federation sign-out cookie - MSISSignOut. 3: # If found assign ADFS sign-out session variable and close HTTP connection 4: if {[HTTP::header "Set-Cookie"] contains "MSISSignOut=;"} { 5: ACCESS::session data set session.user.adfssignout 1 6: HTTP::close 7: } 8: } 9: 10: when CLIENT_CLOSED { 11: # Remove APM session if ADFS sign-out variable exists 12: if {[ACCESS::session data get session.user.adfssignout] eq 1} { 13: after 5000 14: ACCESS::session remove 15: } 16: } What? Another iRule? Actually, the above snippet can be combined with the iRule we implemented in Part 3 creating a single iRule addressing all the ADFS/Office 365 scenarios. 1: when HTTP_REQUEST { 2: # For external Lync client access all external requests to the 3: # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI 4: # where appropriate 5: HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]] 6: 7: # Analyze the HTTP request and disable access policy enforcement WS-Trust calls 8: if {[HTTP::uri] contains "/adfs/services/trust"} { 9: ACCESS::disable 10: } 11: 12: # OPTIONAL ---- To allow publishing of the federation service metadata 13: if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} { 14: ACCESS::disable 15: } 16: } 17: 18: when HTTP_RESPONSE { 19: # Review serverside responses for reset of WS-Federation sign-out cookie - MSISSignOut. 20: # If found assign ADFS sign-out session variable and close HTTP connection 21: if {[HTTP::header "Set-Cookie"] contains "MSISSignOut=;"} { 22: ACCESS::session data set session.user.adfssignout 1 23: HTTP::close 24: } 25: } 26: 27: when CLIENT_CLOSED { 28: # Remove APM session if ADFS sign-out variable exists 29: if {[ACCESS::session data get session.user.adfssignout] eq 1} { 30: after 5000 31: ACCESS::session remove 32: } 33: } Gotta love them iRules! That’s all for now. Additional Links: Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm” Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy” Big-IP and ADFS Part 3 – “ADFS, APM, and the Office 365 Thick Clients” BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki AD FS 2.0 - Interoperability with Non-Microsoft Products MS TechNet - AD FS: How to Invoke a WS-Federation Sign-Out Tristan Watkins - Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy Technorati Tags: load balancer,ADFS,Office365,active directory,F5,federation,exchange,microsoft,network,blog,APM,LTM,Coward,SSO,single sign-on,single sign-outMicrosoft Exchange Server
F5 works closely with Microsoft to ensure we are delivering the best possible technology and deployment guidance to support highly available and scalable Exchange Server deployments. F5 performs extensive internal engineering and testing to develop deployment guides and associated iApp templates for Microsoft Exchange Server. The guides and templates enable organizations to easily provide additional performance, security and availability for Exchange Server deployments, ensuring maximum ROI with the minimum amount of work. The following simple, logical configuration example shows one of the ways you can configure the BIG-IP system for Microsoft Exchange Server. For specific information on Microsoft Exchange 2016, see https://devcentral.f5.com/s/articles/exchange-2016and for Exchange 2013/2010, see https://devcentral.f5.com/s/articles/microsoft-exchange-2010-and-2013-iapp-template. Go to https://f5.com/solutions/deployment-guidesto find the appropriate deployment guide for quickly and accurately configuring the BIG-IP system for Microsoft Exchange Server. If you have any feedback on these or other F5 guides or iApp templates, leave it in the comment section below or email us at solutionsfeedback@f5.com. We use your feedback to help shape our new iApps and deployment guides.Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients”
Okay, so I never mentioned a part 3. But, the topic is just too much fun to let go. Besides, we have one more important section to cover. First, let’s recap parts one and two. In part one we discussed load balancing the ADFS and ADFS proxy farms providing for a highly-available and scalable deployment. Part two focused on utilizing the Access Policy Manager, (APM) module as a replacement for the ADFS proxy layer. This not only creates a more secure and flexible solution but simplifies the infrastructure. As you may recall, (if you’ve been following along), Office 365 was the use case for part two as we showed how the Big-IP with APM could provide pre-authentication and SSO sign-on for Outlook Web Access, (OWA). However, when it comes to accessing Office 365 resources from thick clients, (aka active protocols and active profiles), including Outlook and the Lync client things become a little more complicated. Let’s take a look. Passive Protocol – (Outlook Web App) Clients using the WS-Federation passive protocol, (primarily browser-based) process is as follows: The client attempts to access the Office 365 resource; The client is redirected to the Microsoft Federation Gateway The client is redirected to their organization’s internal federation service, (AD FS); The AD FS server authenticates the client to active directory; The AD FS server provides the client with an authorization cookie containing the signed security token and set of claims for the resource partner; The client connects to the Microsoft Federation Gateway where the token and claims are verified. The Microsoft Federation Gateway provides the client with a new service token; and The client presents the new cookie with included service token to the Office 365 resource for access. In the above case AD FS is using the WS-Federation protocol and SAML. This type of connection can be greatly enhanced by using the Big-IP’s APM to proxy the connections to AD FS. Active Protocol – (Outlook & Lync Clients) The interaction of clients like Outlook and Lync, (external client), is slightly different. In this case, the process utilizes the active protocol, WS-Trust, and SOAP. The client attempts to access the Office 365 resource and provides credentials; Office 365 looks to the Microsoft Federation Gateway for authentication; Microsoft Federation Gateway contacts the AD FS service on behalf of the client and presents the credentials; The AD FS authenticates the client credentials with active directory; AD FS provides the Microsoft Federation Gateway with a token; and The Microsoft Federation Gateway provides the Office 365 resource with the token allowing the client to access the resource. In simple terms, rather than the client doing the leg-work required to request and get the token from AD FS, the Microsoft Federation Gateway interacts directly with AD FS. Since the client is not connecting to AD FS itself APM, (or any proxy service) cannot be used. So, here’s the challenge. How do we allow the Microsoft Federation Gateway direct access for authentication of the thick clients, (Outlook and Lync) when deploying AD FS behind the Big-IP and APM while still pre-authenticating the passive connections, (browser-based and internal Lync)? It’s simple really; we’ll use an iRule. APM Bypass iRule To allow for direct access by the MS Federation Gateway, an iRule is created and assigned to the ADFS virtual server created in part two of this series. The iRule uses the HTTP_REQUEST event, (triggered when the system parses the HTTP request) and analyzes the URI. When a relevant request is received, the ACCESS::disable command is called disabling access policy enforcement and allowing the request through. For additional guidance on the third party proxy requirements, please refer to Microsoft’s guidance. Create and assign the following basic iRule to the external AD FS virtual server. 1: when HTTP_REQUEST { 2: 3: # For external Lync client access all external requests to the 4: # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI 5: # where appropriate 6: HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]] 7: 8: # Analyze the HTTP request and disable access policy enforcement WS-Trust calls 9: if {[HTTP::uri] contains "/adfs/services/trust"} { 10: ACCESS::disable 11: } 12: 13: # OPTIONAL ---- To allow publishing of the federation service metadata 14: if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} { 15: ACCESS::disable 16: } 17: } That’s it! Pretty straightforward right? Give it a try and let me know how it goes. Since we are working with external access I did not address AD FS 2.0 support for identifying and blocking external access. But, if you're interested in this advanced feature, please refer to Microsoft’s guidance. Additional Links: Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm” Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy” BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki Technorati Tags: load balancer,ADFS,Office365,active directory,F5,federation,exchange,microsoft,network,blog,APM,LTM,Coward
F5 Friday: Lessons from (IT) Geese
Birds migrate in flocks, which means every individual has the support of others. IT often migrates alone – but it doesn’t have to. “Lessons from Geese” has been around a long time. It is often cited and referenced, particularly with respect to teamwork and collaboration. The very first “lesson” learned from geese migrations applied to human collaboration is this: Fact #1: As each goose flaps its wings, it creates an uplift for the others behind it. By flying in a "V" formation, the whole flock adds 71% greater flying range than if each bird flew alone. Lesson: People who share a common direction and sense of community can get where they are going quicker and easier because they are traveling on the thrust of another. That’s probably not surprising at all and the basic lesson is one we’re all familiar with, no doubt. Fact #3: When the lead goose tires, it rotates back into the formation and another goose flies to the point position. Lesson: It pays to take turns doing the hard tasks and sharing leadership, as with geese, people are interdependent on each other’s skill, capabilities and unique arrangement of gifts, talents or resources. This lesson works well, if everyone is a goose is similarly talented at flying. But within IT there are myriad skill sets being used that must come together to migrate implementations from one version to another. It’s not just software – it’s data stores, identity stores, switches, and application delivery systems. There’s a lot of different skills required to successfully migrate large, business critical systems. And we can’t just pick a random goose to lead when it comes to migrating specific subsets and components; we need experts in various systems to assist. And sometimes, we don’t have the right goose. So we have to find one. “A Plan-Net survey found that 87% of organizations are currently using Exchange 2003 or earlier. There has been a reluctance to adopt the 2007 version, often considered to be the Vista of the server platform — faulty and dispensable.” -- 10 reasons to migrate to Exchange 2010 This doesn’t explain a reluctance to move to Exchange 2010. With larger mailboxes, virtualization support, voicemail transcription, and higher availability, what’s not to like? Significant changes in the underlying architecture – which cascade into the infrastructure – may be one of them. Upgrading a business critical service like Exchange requires more planning and forethought than upgrading to the latest version of Angry Birds, after all. Continuity of service is required even as the new version is put in place. And while there are plenty of experts who can help with the migration of Exchange, there are fewer that can help with the migration of its supporting infrastructure services. F5 has an answer for that, a skilled goose, if you will, who can take the lead and keep the organization on track. Introducing: F5 Architecture Design for Microsoft Exchange Service The F5 Architecture Design for Microsoft Exchange service comprises an intense three days of discussion, information gathering, analysis and knowledge-sharing of network considerations for the optimal deployment of Microsoft Exchange in an F5 network environment. F5 Professional Services consultants with Exchange expertise conduct assessments during which they review your current network and future needs to streamline your new implementation, upgrade or migration to your preferred version of Microsoft Exchange. Plan During the project kick-off call, F5 Professional Services consultants make sure to understand your overall project goals, flag dependencies, and validate that all questionnaires and information requirements have been addressed prior to the initiation of the engagement. Analyze The F5 Architecture Design for Microsoft Exchange Service facilitates the discussion, analysis and development of the network architecture requirements that best support your Exchange deployment. The engagement starts with an overview and whiteboard discussion of F5 technology, focusing on topics of high availability, scalability, security and performance. Next, the consultants engage in conversations about mail deployment for legacy mail systems or new deployments, touching on sizing, security and service-level agreements. Finally, they review the architectural components specific to your environment, including network flows, client access, unified messaging, and considerations of single vs. multisite deployments. Design and Report The F5 Professional Services consultants consolidate the results from the analysis phase and deliver a Proposed Microsoft Exchange Network Architecture and a Proposed Network Migration Plan report detailing the recommendations. F5 consultants intimately understand F5 BIG-IP ® systems and their operation, and can draw on the F5 Solutions for Microsoft Exchange Server. You can be assured of the thoroughness and relevance of their recommendations. The consultants’ reports provide you with the blueprint for flexible and cost-effective communication and collaboration in your organization. For more information about the F5 Architecture Design for Microsoft Exchange service, use the search function on f5.com or contact consulting@f5.com Additional Resources: Microsoft Exchange 2010: HELO New Architecture Deploying F5 with Microsoft Exchange 2010 F5 solution for Microsoft Exchange Microsoft Exchange 2010: HELO New Architecture F5 Friday: BIG-IP Solutions for Microsoft Private Cloud Webcast - BIG-IP v11 and Microsoft Technologies Social Forums - F5/Microsoft Solutions Eliminating Data Center Vertigo with F5 and Microsoft F5 Friday: Microsoft and F5 Lync Up on Unified Communications F5 Friday: Playing in the Infrastructure Orchestra(tion)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 LTMiApp – And the audience gasped!
#iApp #v11 Time for some customer evidence! Last week F5 hosted our International Sales Conference. The whole company is invited to the general session at which our senior execs talk about the year in review and our vision for the future. iApp was discussed multiple times, but my favorite part was during the Product Development demonstration that showed how in just a few easy steps our device was configured to accelerate, secure and provide availability for an application. The whole thing took under two minutes and when complete, the audience gasped and burst into applause! The PME team hosted multiple iApp technical training sessions at the conference. Each session filled up quick. The interest and response was overwhelming! Unfortunately I was not able to attend the training this time, but I heard it went very well. iApp has only been available for a short while, but in each session there was at least one person that had an example of a customer that was upgrading to leverage it to increase their efficiency. One customer had spent a week trying to get their Exchange environment running before they downloaded v11 and ran through the iApp. They were up and running in under five minutes! There was even an example of a customer opening a support case when they were running into issues with deploying a new application. The support engineer removed their broken application configuration, provided them the iApp and the customer was up and running. It is so rewarding to see how the hard work and innovation of folks in our organization can make such huge positive impacts to our customers!F5 Friday: Enhancing Microsoft Exchange 2013
#Microsoft #Exchange load balancing is just the beginning… Throughout the years, F5 BIG-IP has been a critical component supporting Microsoft Exchange to implement a variety of performance, security, and architectural requirements. During that time, we've seen Microsoft Exchange evolve itself from a fairly simple, small business solution to a robust enterprise-class solution with an integrated ecosystem of services providing for communication, collaboration, and cooperation. As Microsoft prepares to launch its latest version of Exchange, again we're seeing some evolutionary changes in its architecture. Most prominent is the elimination of a requirement for persistence; the Client Access Server (CAS) component is now a stateless proxy. For those paying attention through the years, the implementation of persistence within Microsoft Exchange deployments was more often than not architecturally designated to an F5 BIG-IP. Does the elimination of the requirement render BIG-IP obsolete? Of course not. While there's been some conjecture that layer 4 load balancing services will suffice for CAS 2013 (and for simple load balancing scenarios, it will) such statements are short-sighted in recognizing the increasing role of mobile and roaming clients, and the need to address core performance and security of public-facing applications (of which Exchange is certainly one). The delegation of persistence management to BIG-IP was often deemed most efficient because BIG-IP was a part of the architecture for other application delivery services – perimeter security, performance, server efficiency, multi-site resiliency, and, of course, scalability. Scale and multi-site resiliency are imperatives today, with growth of users and devices and locations from which e-mail needs to and will be accessed. A distributed workforce can't afford to lose productivity due to slow delivery of e-mail or inability to readily access important content via any access medium, regardless of location. These are the kinds of challenges F5 BIG-IP addresses over and above routine tasks like load balancing. These challenges have not been eliminated with Microsoft's most recent version of Exchange, and BIG-IP is still the ADC of choice for providing these services for deployments large and small. BIG-IP does layer 4 load balancing just as well as layer 7, after all, but also offers a robust set of delivery services that go well beyond either function. Ryan Korock, Technical Director focusing on Microsoft-partner initiatives, has a great list of 8 reasons why an ADC remains invaluable to Microsoft Exchange implementations that goes into more detail on what BIG-IP has – and continues – to offer Microsoft Exchange deployments.
