SSL Orchestrator Advanced Use Cases: Office 365 URL Management
Introduction F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases. If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility. SSL Orchestrator Use Case: Office 365 URL Management If you're reading this article, it's a good bet that your organization relies on Office 365 for your Office productivity, email, and/or collaboration tools. It's also a good bet that you're concerned about encrypted malware, and thus how to deal with malware that sneaks its way into Office 365. Given the shear number of products available to address it, it shouldn't take much to convince you there's a potential threat there. Of course, the service itself is not inherently insecure. But within Office 365, you create, manage and share documents, and send and receive emails with attachments. The issue is that the documents and attachments themselves are malware vectors, and email phishing attacks are hard to catch. Moreover, as the bulk of that traffic is all encrypted, you're faced with a dilemma. Do you rely solely on Microsoft's security to protect your organization, or endpoint security tools? Hopefully your answer is a resounding 'no' to both of these, and that you do indeed decrypt and inspect in active defense against malware and data exfiltration. But therein lies another problem. What and when do you decrypt? What about Office 365 components that don't play well with decryption tools, or where Microsoft recommends to bypass decryption for the sake of performance? At a most recent count, Office 365 encompasses around 350 unique resource URLs, and roughly 160 IPv4 and IPv6 addresses. These URLs represent the different Office 365 services, and are dynamic (i.e. frequently changing). So then I will ask again. What and when do you decrypt and inspect Office 365 traffic based on the revelation that not all Office 365 URLs should be managed the same way, and they're ever-changing. If at this point you're still not completely clear on the complexity of this scenario, that's okay. I'll refer you to a few Microsoft resources that go into great detail on the subject: https://techcommunity.microsoft.com/t5/office-365-blog/announcing-office-365-endpoint-categories-and-office-365-ip/ba-p/177638 https://techcommunity.microsoft.com/t5/office-365-blog/getting-the-best-connectivity-and-performance-in-office-365/ba-p/124694 https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide Microsoft also now tags URLs with an internal category system, as defined here: https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#new-office-365-endpoint-categories Those categories are: Optimized URLs - endpoints required for connectivity to every Office 365 service, and the most sensitive to network performance, latency and availability. Allow URLs - endpoints required for specific Office 365 services, but not as sensitive to latency as the Optimized URLs. Default - endpoints that represent Office 365 services that do not require optimization. Fortunately, F5's SSL Orchestrator can provide an elegant solution to this complex problem. Intelligent traffic classification allows you to define rules that can be used to control availability (allow or block), decryption (intercept or bypass), and steering through dynamic sets of security devices (service chaining). Bypassing TLS decryption on an Office 365 resource can be as simple as a single rule that matches on all Office 365 URLs. Or, you can decrypt some and bypass others, as Microsoft recommends. And you can choose to pass traffic through the service chain of security devices irrespective of decryption. Managing Office 365 URLs To make all of this work, you first need the Office 365 data source. As previously illustrated, Office 365 URLs and IP addresses are dynamic, updating roughly every 30 days. This feed isn't built into the BIG-IP, but there's an easy way to add it with a simple Python script: https://github.com/f5devcentral/sslo-o365-update Basically, a Python script is configured to run periodically on your BIG-IP to keep local custom URL categories and/or data groups in sync with the Office 365 URL source. These collections can then be consumed natively by the SSL Orchestrator security policy. You can then use these new URL categories as you would anything else in the security policy, like bypassing decryption for the set of "optimized" Office 365 URLs, or perhaps bypassing a proxy security device in an SSL Orchestrator decrypted service chain. Figure 1: SSL Orchestrator security policy with O365 category rule The Github repo has all of the instructions, but setup is pretty straightforward: Download the Python script - download on both devices in an HA pair: curl -k https://raw.githubusercontent.com/f5devcentral/sslo-o365-update/main/sslo_o365_update.py -o sslo_o365_update.py Install the script with the --install flag, and provide an interval for the script to run: python sslo_o365_update.py --install 3600 When the installation is complete, edit your SSL Orchestrator security policy and add a traffic condition to match on one of the new Office 365 managed URL categories. That's it. In a HA pair, the script runs independently on each unit. If you need to make adjustments to the configuration, jump on a BIG-IP console/SSH session and edit the json config data as described in the repo: tmsh edit sys file ifile o365_config.json If you mess something up or just want to rebuild, run the script again manually with the --install flag (and time interval). You can configure the script to: Create all or some of the URL categories, for different customer endpoints and different service areas Create just data groups and/or just categories Manage just URLs and/or just IPs Include and exclude URLs and IPs. ** Note that you will also need to configure system DNS and a gateway route on the BIG-IP to access this remote Microsoft content. ** And there you have it. In just a few steps you've configured your SSL Orchestrator security policy to identify and take action on the dynamic set of Office 365 URL/IP resources, and along the way you have hopefully recognized some of the immense flexibility at your command.Enabling SharePoint 2013 Hybrid Search with the BIG-IP
Over my past several blog posts, I’ve talked about federating our on-premise environments with Office 365. Now, that we have that handled, (it’s handled right?) let’s talk about another lesser known piece of the puzzle; hybrid SharePoint environments. With federation and SSO between on-premise applications and Office 365 provided by the BIG-IP and APM, (Access Policy Manager) users can move seamlessly between their on-premise SharePoint and SharePoint online as if they were one integrated application. Cool right? But what about when I need to search for content across environments? Funny I should ask. That’s what this post is all about. Microsoft actually has this figured out. The only piece missing is a device that can act as the reverse proxy for the on-premise environment and facilitate the secure connection between the two environments. Hmmm… What could we use? Configuring Hybrid Search for SharePoint 2013 This post covers the pieces required to use the BIG-IP as a reverse-proxy for a hybrid SharePoint search deployment. For guidance on configuring both your on-premise SharePoint 2013 and SharePoint Online environments refer to the Hybrid for SharePoint 2013 guidance provided by Microsoft. It’s quite thorough and, to be honest a little daunting. Currently, Microsoft’s SharePoint 2013 hybrid capabilities are intended to let users in Office 365 access and search across certain content from an on premises SharePoint farm. For detailed information on architectural recommendations and limitations take a look at the blog post from Microsoft architect, Steve Peschka. Client Certificate authentication is utilized to allow secure access for hybrid search, (SharePoint content located both on-premise and in the cloud) from Office 365 environment. To accomplish this a target application is configured in the SharePoint Online Secure Store where a client certificate, (issued by a public root certificate authority). Figure 1 – SharePoint Online Secure Store & Target application Configuring the BIG-IP for Client Certificate Authentication The following configuration was tested by F5 in collaboration with the Office365 product team. The testing was conducted at the Microsoft Technology Center in Irvine where an environment was provided for hybrid enterprise search & LOB scenarios between O365 and on-premise SharePoint farms. We collaborated with the MTC’s expert staff and took advantage of the alliance partnership between Microsoft and F5, whose solutions were made available as part of their engagement. For the purposes of hybrid search, the BIG-IP and LTM, (Local Traffic Manager) acts as a reverse proxy providing a secure Internet facing endpoint for connections from the SharePoint Online environment. The deployment of SharePoint behind the BIG-IP can either be configured manually or via the BIG-IP iApp configuration. Once SharePoint 2013 has been successfully deployed it is simple matter of modifying the virtual server’s Client SSL Profile. Figure 2 – SharePoint 2013 On-Premise Virtual Server The SSL Profile is configured to require a client certificate for successful access. Additionally, the certificate must be issued from the specified certificate authority whose CA certificate is installed on the BIG-IP. In the example below, (Figure 3) the client certificate presented must be issued by StartCom, Ltd. Figure 3 – Client SSL Profile with Client Authentication Required As long as the certificate installed and configured in the SharePoint Online Secure Store is valid and issued by the appropriate certificate authority, users in O365 will be able to search for and receive results from the on-premise SharePoint environment. Enhancing Security with iRules Ok, the above configuration provides security to the hybrid connection via client certificates. However, it’s still vulnerable. As previously noted, the certificate used must be issued by a public root certificate authority. While this is good, this does not guarantee that the certificate presented is the actual certificate configured in the SharePoint Online environment. Merely, it just guarantees that the certificate was issued from the same place, (StartCom, Ltd. in our example). Fortunately, there’s an iRule for that! The iRule provided below examines the client certificate provided and ensures that the serial number of the certificate matches the SharePoint Online configured certificate. This ensures that not only is the presented certificate issued from a specific and valid certificate authority, but also ensures that the certificate itself is an exact match. Figure 4 – Granular_Cert_Verification iRule validating the Client Certificate Serial Number 1: when CLIENTSSL_CLIENTCERT { 2: 3: # Check if client provided a cert 4: if {[SSL::cert 0] eq ""}{ 5: 6: # Reset the connection 7: reject 8: 9: } else { 10: 11: #Example Subject SN: 01 ED 51 12: set subject_sn [X509::serial_number [SSL::cert 0]] 13: log "Client Certificate Received: $subject_sn" 14: #Check if the client certificate contains the correct serial number 15: if {$subject_sn contains "0c e4 11"} { 16: #Accept the client cert 17: log "Client Certificate Accepted: $subject_sn" 18: } else { 19: log "No Matching Client Certificate Was Found Using: $subject_sn" 20: reject 21: } 22: } 23: } Figure 5 – Client Certificate Subject Name Figure 6 – iRule Assigned to Virtual Server That’s It! Not too bad huh? Of course this is the easy part. We still need to ensure that we have properly configured both environments, (on-premise and Office 365) to enable the hybrid search functionality. Accomplishing that is a little more tricky, but definitely doable. Be sure to refer to the links below for information from Microsoft on how to set this up. In addition, check out Steve Peschka’s blog posts for information. Additional Links: Hybrid for SharePoint Server 2013 Configure hybrid Search for SharePoint Server 2013 F5 and SharePoint 2013 – Deployment Guidance Architecture Design Recommendation for SharePoint 2013 Hybrid Search Features – Steve Peschka Blog Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
Big-IP Access Policy Manager (APM) Identity Federation SAML Documentation
As enterprise customers start to accelerate their cloud Software-as-a-Service (SaaS) deployments their IT staff is observing increased help desk calls and user password fatigue issues. F5’s Big-IP Access Policy Manager (APM) product can address these requirements through its support for SAML 2.0 federation services like Identity Provider (IdP) for popular SaaS services such as Office 365, Salesforce etc. Big-IP APM supports both Service Provider (SP)-initiated and IdP-initiated deployments for identity federation to SaaS services as illustrated below User logs on to the Big-IP APM IdP and is directed to the webtop User selects a Salesforce service from the webtop. Big-IP APM may retrieve attributes from the user data store to pass on to the SaaS service provider. Big-IP APM directs the requests to the SaaS service with the SAML assertion and optional attributes via the user browser. User accesses Salesforce SaaS service. Salesforce redirects the user back to the Big-IP APM SAML IdP with SAML request via the user's browser. Big-IP APM prompts the user to logon with the relevant credentials. At this time Big-IP APM may retrieve attributes from the user data store to pass on with the SaaS service provider (SP). Big-IP APM then sends a SAML response to Salesforce with the authentication information and optional attributes via the user's browser for allowing access to the service. Over the years F5 has been extending its support for identity federation including support for SAML 2.0 OASIS standard features and publishing collateral for administrators to easily deploy Big-IP APM IdP services. Below is a consolidated list of documentation which includes the deployment guides to federate against the following SaaS services Office 365 Salesforce Workday Amazon Web Services Concur Service Now Jive Wombat Zendesk Cisco Webex Box Google Apps The deployment guides mentioned below provide details on setting up the following Big-IP APM objects for above mentioned SaaS applications Profiles, AAA server and Virtual Server IdP Configuration SP Connector Configuration Access Policy Setup using Visual Policy Editor iApps to setup the above configuration is also available in the guide* The deployment guides also have pointers on configuring SaaS SP services based on the SaaS provider documentation. While these deployment guides are provided as a quick reference for configuring the above mentioned SaaS applications, Big-IP APM can be used to setup almost any other SaaS applications that support SAML 2.0 OASIS standard. Deployment Guides Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Common SaaS Applications (For all SaaS applications other than office 365) Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Microsoft Office 365 Please add comments below should you have any feedback for this documentation or need other APM related documentation. * Production version of APM IdP to Office 365 iApp is available in the Office 365 guide. Beta version of iApp for all other SaaS applications is available here (production version will be released soon)Application Availability Between Hybrid Data Centers
Reliable access to mission-critical applications is a key success factor for enterprises. For many organizations, moving applications from physical data centers to the cloud can increase resource capacity and ensure availability while reducing system management and IT infrastructure costs. Achieving this hybrid data center model the right way requires healthy resource pools and the means to distribute them. The F5 Application Availability Between Hybrid Data Centers solution provides core load-balancing, DNS and acceleration services that result in non-disruptive, seamless migration between private and public cloud environments. Check out the new Reference Architecture today along with a new video below! ps Related: Application Availability Between Hybrid Data Centers Reference Architecture Hybrid Data Center Infographic Hybrid Data Center Solution Diagram Technorati Tags: hybrid,data center,cloud,application delivery,office 365,goldengate,reference_architecture,f5,big-ip,silva Connect with Peter: Connect with F5:Collaborate in the Cloud
Employee collaboration and access to communication tools are essential for workplace productivity. Organizations are increasing their use of Microsoft Office 365, a subscription-based service that provides hosted versions of familiar Microsoft applications. Most businesses choose Exchange Online as the first app in Office 365 they adopt. The challenge with any SaaS application such as Office 365 is that user authentication is usually handled by the application itself, so user credentials are typically stored and managed in the cloud by the provider. The challenge for IT is to properly authenticate the employee (whether located inside or outside the corporate network) to a highly available identity provider (such as Active Directory). Authentication without complexity Even though Office 365 runs in a Microsoft-hosted cloud environment, user authentication and authorization are often accomplished by federating on premises Active Directory with Office 365. Organizations subscribing to Office 365 may deploy Active Directory Federation Services (ADFS) on premises, which then authenticates users against Active Directory. Deploying ADFS typically required organizations to deploy, manage, and maintain additional servers onsite, which can complicate or further clutter the infrastructure with more hardware. SAML (security assertion markup language) is often the enabler to identify and authenticate the user. It then directs the user to the appropriate Office 365 service location to access resources. SAML-enabled applications work by accepting user authentication from a trusted third party—an identity provider. In the case of Office 365, the BIG-IP platform acts as the identity provider. For example, when a user requests his or her OWA email URL via a browser using Office 365, that user is redirected to a BIG-IP logon page to validate the request. The BIG-IP system authenticates the user on behalf of Office 365 and then grants access. The Office 365 environment will recognize the individual and provide their unique Office 365 OWA email environment. The BIG-IP platform provides a seamless experience for Office 365 users and with the federated identity that the BIG-IP platform enables, the IT team is able to extend SSO capabilities to other applications. The benefit of using the BIG-IP platform to support Office 365 with SAML is that organizations can reduce the complexity and requirements of deploying ADFS. By default, when enabling Office 365, administrators need to authenticate those users in the cloud. If an IT administrator wants to use the corporate authentication mechanism, ADFS must be put into the corporate infrastructure. With the BIG-IP platform, organizations can support authentication to Office 365 and the ADFS requirement disappears, resulting in centralized access control with improved security. Secure collaboration Because email is a mission-critical application for most organizations, it is typically deployed on premises. Organizations using BIG-IP-enhanced Microsoft Exchange Server and Outlook can make it easier for people to collaborate regardless of their location. For example, if a company wanted to launch a product in Europe that had been successfully launched in the United States, it needs workers and contractors in both locations to be able to communicate and share information. In the past, employees may have emailed plain-text files to each other as attachments or posted them online using a web-based file hosting service. This can create security concerns since potentially confidential information is leaving the organization and being stored on the Internet without any protection or encryption. There are also concerns about ease of use for employees and how the lack of an efficient collaboration tool negatively impacts productivity. Internal and external availability 24/7 To solve these issues, many organizations move from the locally managed Exchange Server deployment to Microsoft Office 365. Office 365 makes it easier for employees to work together no matter where they are in the world. Employees connect to Office 365 using only a browser, and they don’t have to remember multiple usernames and passwords to access email, SharePoint, or other internal-only applications and file shares. In this scenario, an organization would deploy the BIG-IP platform in both the primary and secondary data centers. BIG-IP LTM intelligently manages all traffic across the servers. One pair of BIG-IP devices sits in front of the servers in the core network; another pair sits in front of the directory servers in the perimeter network. By managing traffic to and from both the primary and directory servers, the F5 devices ensure availability of Office 365—for both internal and external (federated) users. Ensuring global access To provide for global application performance and disaster recovery, organizations should also deploy BIG-IP GTM devices in the perimeter network at each data center. BIG-IP GTM scales and secures the DNS infrastructure, provides high-speed DNS query responses, and also reroutes traffic when necessary to the most available application server. Should an organization’s primary data center ever fail, BIG-IP GTM would automatically reroute all traffic to the backup data center. BIG-IP GTM can also load balance the directory servers across data centers to provide cross-site resiliency. The BIG-IP platform provides the federated identity services and application availability to allow organizations to make a quick migration to Office 365, ensuring users worldwide will always have reliable access to email, corporate applications, and data. ps Related: Leveraging BIG-IP APM for seamless client NTLM Authentication Enabling SharePoint 2013 Hybrid Search with the BIG-IP (SCRATCH THAT! Big-IP and SAML) with Office 365 Technorati Tags: office 365,o365,big-ip,owa,exchange,employee,collaborate,email,saml,adfs,silva,saas,cloud Connect with Peter: Connect with F5:
