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”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.
Office 365 SAML token rejection
I have configured the Office 365 SAML iApp for authentication, and to all intents and purposes it looks as though APM is successfully authenticating a user and issuing a token. However when the token is submitted to Office 365 I receive the response: Sorry but we're having trouble signing you in. We've received a bad response. AADSTS50000 there was an error issuing a token. I'm using a URI as an identified as opposed to a URN. I've investigated as much as I can (but by no means and expert) confirming certificate thumbprints are uploaded to O365, time is in sync. I have dug into the http requests with Fiddler. I can see the SAML request and response. I see it submitted in the header to O365. Verified users are synchronised to Azure AD. Furthermore I've checked for additional proceeding slashes in the configuration between APM & O365. Really struggling to understand the problem. Any suggestions/ help would be greatly appreciated.
Office 365's new "Modern Auth"
Hi All, We've just heard a rumor that Microsoft have released a new authentication model for Office 365 which they are using with Exchange Online and Skype for Business to start with. Now we have been told that with this new authentication model that ADFS being fronted by APM for authentication/acting as an ADFS proxy is not and will not be supported due to the change in the way authentication works. From what we can tell, it will only break application clients (ActiveSync/Office/Skype) that aren't just a web page, but we really don't have much detail. Does anyone have any experience with Office 365 off-prem setups and the new Modern Authentication model? Can anyone confirm that it doesn't in fact work? Is there anyone from F5 who has advice on if it's on the road map for being fixed/addressed/investigated? Thanks in advanced.
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)Office 365 Hybrid "thick" clients, totally replace ADFS (not just ADFS Proxy)
Goal: Hybrid Setup with Office 365, no p/w in cloud. Status. Set up (w/Big IP APM) and works great except for thick clients. Does the most recent iApp for ADFS or iApp for office 365 allow thick clients to authenticate, or is the iApp for ADFS at the point where it can replace ADFS (and not just ADFS proxy) ? Or if must be done manually, is there guidance for what info the big ip needs from O365 and what O365 is looking for from Big IP (and where to enter this config info)?APM: Office365 Skype for Business On-Premise Authentication
I've spent a few days working on an Office 365 lab hybrid deployment and have been unable to get Skype for business to authenticate or work properly. Is this supported? In my configuration I am attempting to use the F5 as the IDP. Azure AD connect is syncing properly and is not syncing password hashes to Azure. According to this document, Rich client application such as Lync or authenticating an Office subscription are not supported: Azure AD federation compatibility list However I am able to authenticate other thick-clients like Word, Excel, Outlook, etc without issue. A window with the APM login screen is displayed when authenticating--I would expect similar behavior for the Skype client. This makes me believe maybe this document is incorrect? I have gathered SSLdumps and see the authentication request reach the VIP: 1 10 1472838567.6975 (0.0018) C>SV3.3(448) application_data --------------------------------------------------------------- POST /saml/idp/profile/ecp/sso HTTP/1.0 Connection: Keep-Alive Content-Type: application/soap+xml Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 10.0; WOW64; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; MSOIDCR L 7.250.4556.0; App lync.exe, 16.0.7167.2040, {12B07E85-1B47-41C4-A4E2-43XXXXXXXXXX}) Content-Length: 1583 Host: idp.xxxxx.xxx --------------------------------------------------------------- 1 11 1472838567.6975 (0.0000) C>SV3.3(1632) application_data --------------------------------------------------------------- http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issuehttps://idp.xxxxx.xxxx:443/saml/idp/profile/ecp /sso1472838xxx xxxx@xxxx.xxxxxxxxxxxxxx 2016-09-02T17:52:11Z2016-09-02T17:57:11Z http://schemas.xmlsoap.org/ws/2005/02/trust/ Issueurn:federation:MicrosoftOnline http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey --------------------------------- ------------------------------ 1 12 1472838567.7042 (0.0067) S>CV3.3(336) application_data --------------------------------------------------------------- HTTP/1.0 302 Found Server: BigIP Connection: Close Content-Length: 0 Location: /my.policy Set-Cookie: LastMRH_Session=9c7be893;path=/;secure Set-Cookie: MRHSession=xxxxxxxxxxxxxxxxxxxxxxxxxxx;path=/;secure Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/ --------------------------------------------------------------- 1 1472838567.7042 (0.0000) S>C TCP FIN 1 13 1472838567.7046 (0.0003) C>SV3.3(48) Alert I would expect that the APM should be responding to the request rather than closing the connection as seen above. To me the soap envelope looks OK, or maybe I'm missing something simple? I'm running 12.1.1, and have also tried 11.6.1. I have no on-premise Skype/Lync environment and have validated that all DNS entries for Skype are correct. Microsoft's Connectivity Analyzer succeeds on all tests. The Skype client produces a generic failure on login: "Cannot sign in because the server is temporarily unavailable". Any guidance would be appreciated, thanks!SAML APM with Office 365
Hello, Armed with all good intentions, i have been trying to setup for days a lab for testing SAML with O365. I have a O365 subscriptions with my private live.com account, but not sure how it would work with that, as the domain part of the email address should be used to redirect to the IdP. Then, I tried with my own private domain (which points to my ADSL router via dyn.com), but then I dont have a O365 subscription with that domain, so catch 22. Does anybody have a detailed step by step guide how to setup such a lab? So far i found plenty of general information about SAML, how it works and how easy is supposed to be, but no step by step guide. SAML deployment guide using iApp is quite cryptic too. maybe somebdoy can post agility 2016 lab, i heard somebody did a lab there? or how does it work in practice? Thanks in advance and happy 2017!!
APM OTP not being received
We're investigating an issue where OTP isn't being recieved by users. The logging just seems to to suggest a black hole. User confirms not in junk etc. This doesn't happen all the time, it is quite sporadic. Apr 6 10:46:19 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:82caf589: Username '*removed*' Apr 6 10:46:39 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:82caf589: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr 6 10:52:54 BIGIP1 notice tmm2[22524]: 01490502:5: /Common/Citrix_XenDesktop:Common:82caf589: Session deleted due to user inactivity. A successful one reads as: Apr7 05:03:48 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Username '*removed*' Apr7 05:04:21 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Successful' from item 'OTP Verify' to terminalout 'Success' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490220:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Pool '/Common/Pool_A' assigned Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490005:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'fallback' from item 'Pool Assign ALGCTXA' to ending 'Allow' Is there any additional logging that can be put on to see what is going on with sending the OTP email? Thanks in advance
