Big-IP and ADFS Part 5 – “Working with ADFS 3.0 and SNI”
Can you believe it? It’s true, it’s true! There’s a part 5. What can I say? Times change; people change; software changes. Active Directory Federation Services, (ADFS) is no exception. While the BIG-IP with SAML 2.0 can alleviate the need for and ADFS infrastructure in many use cases, there are still organizations that need/want to continue utilizing ADFS. Fortunately, regardless of which way you go, F5 can help. So, in the spirit of free will, collaboration, and serving the greater good, (too much?), let’s talk about load balancing ADFS 3.0 with the BIG-IP. As you may, or may not, recall the previous posts around BIG-IP and ADFS revolved around load balancing ADFS 2.0 and ADFS Proxy, replacing the ADFS Proxy with Access Policy Manager, and replacing the entire ADFS infrastructure with APM and SAML. The good news is that these posts are still relevant with regards to ADFS 3.0 and the ADFS proxy replacement, (WAP); well for the most part anyway. ADFS and SNI While there are numerous differences between ADFS 3.0 and previous versions, the most significant change with respect to providing HA and scalability for the ADFS 3.0 infrastructure is its use of Server Name Indication, (SNI). To Successfully integrate a load balancing solution, ( including full reverse proxy), into the ADFS environment the device must support SNI. The load balancing device must be able to present the server name to the backend host as part of the initial Client Hello. Fortunately, the BIG-IP, (ver. 11.1.0 and later) supports this TLS protocol extension. The rest of this post will provide guidance on enabling SNI support for ADFS 3.0 integration. For overall guidance refer to parts one thru three of this series as well as the recently published ADFS 2.0 Deployment Guide. SNI and the Server Profile The BIG-IP provides a virtual server, (listener), that receives client SSL connections and subsequently intelligently passes traffic into a pool of ADFS/WAP servers. Depending upon the organization’s infrastructure and security requirements, the BIG-IP can simply receive encrypted client connections and pass them through to the backend ADFS farm, (aka SSL tunneling). However, the preferred method, (SSL bridging), receives encrypted clients connections; terminates and decrypts the traffic. The traffic is then re-encrypted and sent to the backend application servers. This method adds an additional layer of security since external traffic never directly connects to the internal domain-joined machines as well affording the ability to perform additional deep packet inspection. SSL bridging back to the ADFS farm requires associating a server SSL profile to the virtual server. Enabling SNI is simply a matter of specifying the server name on the associated server SSL profile, (see below). 1. Navigate to the appropriate profile; 2. Select ‘Advanced’ configuration and enter the FQDN of the backend ADFS service hostname. The hostname will now be provided during the TLS negotiation. In the example below, the server name is ‘fs.f5demo.net’, (refer to the highlighted field). Like I said, simple! Health Monitoring and SNI Effectively monitoring the backend ADFS/WAP farm members is a little trickier but very doable. Since the built-in HTTP monitors do not provide the server name as part of the TLS negotiation, using them will result in the being backend servers being incorrectly marked as down, (not good). You could simply use a non-HTTP monitor, (ICMP being the most common), but that doesn’t provide a reasonable guarantee that the actual ADFS service is functioning. Better than that, what we can do is create an external custom SNI enabled monitor that validates the service metadata and associate it to the pool. It’s as easy as 1,2,3,…..um.. 4,5,6. 1. Download the script: http://www.f5.com/pdf/deployment-guides/sni-eav.zip 2. Upload the previously downloaded file into the BIG-IP via the web interface. Navigate to ‘System’ –> ‘External Monitor Program List’ –> ‘Import’; IMPORTANT!!! If ADFS proxy server is configured to accept SSL/TLS connections only using TLSv1.1 or better , the monitor will not work. If have come up with this one-liner to replace the “curl” based command in the script. Thanks to Jerry Tower for helping fix the actual HTTP request as well as testing the script. (echo -e "GET $URI HTTP/1.1\r\nHost: $HOST\r\nConnection: Close\r\n\r\n"; sleep 2) | openssl s_client –quiet –servername $HOST -connect $NODE:$PORT 2> /dev/null| grep -i "$RECV" 2>&1> /dev/null The script line that this one-liner should replace is the following: curl-apd -k -v -i --resolve $HOST:$PORT:$NODE https://$HOST$URI | grep -i "${RECV}" 2>&1 > /dev/null 3. Browse to and select the file. Provide a name for the file and select ‘Import’; 4. Create a new external monitor utilizing the associate external file. Navigate to ‘Local Traffic’ –> ‘+’ sign; 5. Provide a name and select ‘External’ for the type. Select the previously created external program. The script provided requires three, (3) variables entered as name/value pairs. The variables are listed below. Select ‘Finished’; Name Value RECV HTTP/1.1 200 URI /FederationMetadata/2007-06/FederationMetadata.xml HOST 6. Associate the newly created monitor to the ADFS pool and/or the WAP pool. Select ‘Local Traffic’ –> ‘Pools’ –> ‘Pool List’. Move the monitor into the active pane and select ‘Update’. 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 and ADFS Part 4 – “What about Single Sign-Out?” BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki Active Directory Federation Services 3.0 OverviewBig-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 Feed
APM Cookbook: SAML IdP Chaining
As an APM subject mater expert at F5 I often find myself in situations where a customer or colleague needs an example of a particular configuration. While most of these requests are easily handled with a call or WebEx I'm a firm believer in sharing knowledge through documentation.. and I don't like getting calls at 3 AM. If you're like me you grew up with the O'Reilly Cookbook series which served as a great reference document for various development or server configuration tasks. My goal is to create a similar reference resource here on DevCentral for those one-off scenarios where a visual example may help your complete your task. For the first APM Cookbook series I'll discuss SAML IdP chaining. Overview Security Assertion Markup Language, more commonly known as SAML, is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember... or in my experience as a security engineer the number of passwords written on a post-it note stuck to their monitor. There are two major services in a SAML environment: IdP - Identity Provider SP - Service Provider The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user's identity. F5's APM performs both IdP and SP services and allows customers to easily deploy federated authentication in their environment. In more complex scenarios you may run across a requirement where multiple SAML IdPs need to be chained together. This comes up from time to time when customers have contractors that utilize federated authentication for authorization to corporate resources. Example For our configuration we have the Globex Corporation that uses APM to authenticate uses to Office 365. Globex hire contractors from Acme Corp. who authenticate using the Acme Corp. ADFS environment. However, since Office 365 is configured to authenticate against the Globex APM we need to convert the Acme Corp. SAML assertion into a Globex SAML assertion, which is known as IdP chaining. The step ladder for this process is shown below: 1. User requests https://outlook.com/globex.com 2 - 3. Office 365 redirects user to idp.globex.com 3 - 4. idp.globex.com determines user is a contractor and redirect user to sts.acme.com 5 - 8. User authenticates using Acme credentials and is then redirect back to idp.globex.com 9. idp.globex.com consumes the Acme SAML assertion and creates a Globex SAML assertion 10. User is redirected back to Office 365 11 - 12. Office 365 consumes the Globex SAML assertion and displays the user's mail Configuration To configure your APM SAML IdP to accept incoming assertion from sts.acme.com we need to create an external SP connector. Under the Access Policy -> SAML -> BIG-IP as SP configuration section: 1. Create a new SAML SP Service 2. Export the SP metadata and configure sts.acme.com accordingly (follow your IdP vendor's documentation) 3. Click the External IdP Connectors menu at the top 4. Click the dropdown arrow on the create button and choose From Metadata (import the metadata from sts.acme.com) 5. Bind the Local SP service to the external IdP connector Now that idp.globex.com and sts.acme.com are configured to trust one another we need to configure the APM IdP to consume the sts.acme.com SAML assertion. The IdP's Visual Policy Editor should look similar to the image below: 1. The Decision Box asks the user what company they're with. This is a simple example but more elaborate home realm discovery techniques can be used. 2. The SAML Auth box is configured to consume the sts.acme.com assertion 3. Since we no longer have a login form on the IdP we need to set a few APM session variables: session.logon.last.username = Session Variable session.saml.last.identity session.logon.last.logonname = Session Variable session.saml.last.identity 4. Create an Advanced Resource Assign that matches your existing IdP Advance Resource Assign. Conclusion This particular post was a little longwinded due to the steps required but overall is a fairly simple configuration. So the next time someone asks if your F5 can do IdP chaining you can confidently reply "Yes and I know how to do that".
ADFS load balancing using CNAME record but against MS guide lines?
We would like to load balance our ADFS using our BigIP load balancer. I'm not a networking guy or expert on BigIP so forgive me for any omissions/inaccuracies. The standard practice to load balance any Windows based service is to: Create a subzone of your DNS domain zone in question, e.g. lb.contoso.com Make the LBs authorative for this zone (i.e. they become the name servers) Within your contoso.com DNS zone, create a CNAME record of adfs.contoso.com mapping it to adfs.lb.contoso.com And finally configure your nodes inside BigIP However, MS explcitly state not to create a CNAME record for ADFS (and some other services too). Here is the snippet from https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements (AD FS 2016 Requirements). It says (see line in bold): DNS Requirements For intranet access, all clients accessing AD FS service within the internal corporate network (intranet) must be able to resolve the AD FS service name to the load balancer for the AD FS servers or the AD FS server. For extranet access, all clients accessing AD FS service from outside the corporate network (extranet/internet) must be able to resolve the AD FS service name to the load balancer for the Web Application Proxy servers or the Web Application Proxy server. Each Web Application Proxy server in the DMZ must be able to resolve AD FS service name to the load balancer for the AD FS servers or the AD FS server. This can be achieved using an alternate DNS server in the DMZ network or by changing local server resolution using the HOSTS file. For Windows Integrated authentication, you must use a DNS A record (not CNAME) for the federation service name. For user certificate authentication on port 443, "certauth.<federation service name>" must be configured in DNS to resolve to the federation server or web application proxy. For device registration or for modern authentication to on premises resources using pre-Windows 10 clients, "enterpriseregistration.<upn suffix>", for each UPN suffix in use in your organization, must be configured to resolve to the federation server or web application proxy. ADFS seems to be a popular and common service that is load balanced by BigIP appliances, but doesn't the method we have to use in BigIP contradict the above MS recommendation? Or is there something happening behind the scene which is transforming the request or performing some other magic to essentially make it look like a non CNAME based request? I would be extremely grateful for any input, thoughts or ideas. Thank youLightboard Lessons: Microsoft AD FS Web Application Proxy Using F5 BIG-IP
Many users and organizations want the flexibility and convenience of identity federation and Single Sign-On (SSO) from the corporate network to intranet, extranet, and cloud applications. Users want touse their corporate login information to access applications outside of the organization...for example, login from the Microsoft/Windows environment and have seamless access to Office 365 and external applications like Salesforce and Concur. Microsoft utlilizes a WebApplication Proxy (WAP) that acts as agateway product to allow external users to access internal applications (behind the firewall), like Active Directory Federation Services (AD FS) for example. The F5 BIG-IP can be used to providehigh availability, performance, and scalability for both AD FS and AD FS Proxy servers using theLocal Traffic Manager (LTM) module. The same BIG-IP can also be usedto secure AD FS traffic without the need for AD FS Proxy servers by using the Access Policy Manager (APM) module. Check out the video below to learn more! Related Resources: Deploying F5 with Microsoft Active Directory Federation Services Active Directory Federation Services Content Map
ADFS Proxy balancing with LTM and Advanced WAF, without APM
Looking to do a new F5 configuration to load balance and protect with Advanced WAF a pair of existing Office 365 ADFS Proxy servers running the 2019 version. I see that F5 is no longer supporting iApps for Office 365. The new supported configuration seems to be using Guided Configuration. All articles I've found so far, recquire using APM. The 'F5 appliances we can use are running version 15.1.x and don't have APM, only LTM and Advanced WAF. Is there an official supported solution to do ADFS Proxy (version 2019 or later) load balancing with Advanced WAF protecions? If there isn't, should we still use the last version of the iApp Templates instead?SSL Bridging and X fwd for ADFS
We currently have a VIP configured for external ADFS that is doing SSL passthrough. We are trying to utilize the X Forwarded for header with SSL bridging however during our change neither the SSL bridging or the x forwarded for option was sucessfull. When applying either or both config that traffic would fail and the web page would show page unreachable. Does anyone have any expereience with this type of changeSliding session for "FedAuth" Persistent cookie delivered by ADFS
Problem this snippet solves: ADFS deliver persistent cookies that allow the user to connect to Sharepoint using WS-Fed. By default, the lifetime is about 12 hours and for security reason, should be changed to a lower value. This irule provide a 12 hours validity for the cookie but add a shorter timeout for inactivity. How to use this snippet: This irule change the default expiration time of the FedAuth cookie to a lower value. The expiration time is reset every time a user make a request until it reach the max expiration time. After the timeout or the max expiration time has been reached, the user is redirected back to the ADFS for authentication. External links Github : https://github.com/e-XpertSolutions/f5 Code : when RULE_INIT { set static::timeout 900 set static::httponly 1 set static::debug 0 set static::irule_name "irule-test-sliding-session" } when HTTP_REQUEST { if { $static::debug } { set event "HTTP_REQUEST" } set hostname [string tolower [HTTP::host]] switch -glob $hostname { "sharepoint1" - "sharepoint2" { set key "" set valid 1 if { [HTTP::cookie exists FedAuth] } { set key [sha1 "$hostname:[HTTP::cookie FedAuth]"] if { [table lookup $key] == "" } { if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: no valid sliding session key found for [IP::client_addr] with session FedAuth:[string range [HTTP::cookie FedAuth] 0 7] on $hostname - Action: redirect user to logout uri" } HTTP::redirect "https://[HTTP::host]/_trust/default.aspx?wa=wsignoutcleanup1.0" } else { if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: a valid key has been found for [IP::client_addr] with session FedAuth:[string range [HTTP::cookie FedAuth] 0 7] on $hostname" } } } } default { set valid 0 } } } when HTTP_RESPONSE { if { $static::debug } { set event "HTTP_RESPONSE" } if {[HTTP::cookie exists FedAuth] and $valid } { if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: set-cookie header found with FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) for [IP::client_addr]" } set key [sha1 "$hostname:[HTTP::cookie FedAuth]"] if { [table lookup $key] != "" } { if { [table lifetime -remaining $key] >= $static::timeout } { table timeout $key $static::timeout HTTP::cookie expires FedAuth $static::timeout relative if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : cookie expiration set to 300 seconds" } } else { HTTP::cookie expires FedAuth [table lifetime -remaining $key] relative if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : cookie expiration set to remaining lifetime" } } } else { table add $key [HTTP::cookie FedAuth] $static::timeout [HTTP::cookie expires FedAuth] if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : Add cookie to the sliding session table for [HTTP::cookie expires FedAuth] seconds" } #HTTP::cookie expires FedAuth $static::timeout relative if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : set cookie to expires within 300 seconds" } } } elseif { $key != "" } { if { [table lookup $key] != "" } { if { [table lifetime -remaining $key] >= $static::timeout } { table timeout $key $static::timeout if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : insert FedAuth session cookie with 300 seconds expiration time" } HTTP::cookie insert name FedAuth value [table lookup $key] path / HTTP::cookie expires FedAuth $static::timeout relative HTTP::cookie secure FedAuth enable if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : insert FedAuth session cookie with 300 seconds expiration time" } } else { HTTP::cookie insert name FedAuth value [table lookup $key] path / HTTP::cookie expires FedAuth [table lifetime -remaining $key] relative HTTP::cookie secure FedAuth enable if { $static::debug } { log local0. "$static::irule_name - [string map -nocase {"/common/" ""} [virtual name]]: FedAuth cookie ([string range [HTTP::cookie FedAuth] 0 7]) valid for [table lifetime -remaining $key] seconds - Action : insert FedAuth session cookie" } } # # insert httponly flag to FedAuth Cookie # if { $static::httponly } { set value [HTTP::cookie value FedAuth] set testvalue [string tolower $value] set valuelen [string length $value] switch -glob $testvalue { "*;httponly*" - "*; httponly*" { } default { set value "$value; HttpOnly"; } } if { [string length $value] > $valuelen} { HTTP::cookie value FedAuth "${value}" } } } } } Tested this on version: 11.5Big-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-out
