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”
Sharepoint error - Your session could not be established
Hello, Our SSO for Sharepoint doesn't work anymore. The behavior is: When user trys to log in, no matter of credentials (even left blank) the users gets error: Your session could not be established. The session reference number: 57d6b19a Invalid Session ID. Your session may have expired. Thank you for using BIG-IP. The APM log reveals: \N: Session deleted due to user logout request. right after the login attempt We are using NTMLv1. And Sharepoint iApp v 2010 Here is an extract from our log: Feb 13 11:36:24 br437f5 notice tmm2[9350]: 01490544:5: 2a5f63b5: Received client info - Type: IE Version: 9 Platform: Win7 CPU: WOW64 UI Mode: Full Javascript Support: 1 ActiveX Support: 1 Plugin Support: 0 Feb 13 11:36:24 br437f5 notice tmm2[9350]: 01490500:5: 2a5f63b5: New session from client IP 204.239.152.212 (ST=British Columbia/CC=CA/C=NA) at VIP 10.11.0.23 Listener /Common/MSSP2013_Int_vs (Reputation=Unknown) Feb 13 11:36:28 br437f5 notice tmm2[9350]: 01490501:5: 2a5f63b5: Session deleted due to user logout request. Feb 13 11:36:49 br437f5 debug websso.0[9532]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:49 br437f5 debug websso.2[9746]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:49 br437f5 debug websso.1[9594]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:53 br437f5 debug websso.3[9856]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0
Sharepoint 2013 and browser logout issue
We are using BIGIP LTM & APM 11.6.1 and have set up a Virtual server for our Sharepoint 2013 farm. The issue that we are experiencing is that if the user is using the Chrome browser, no matter whether they select "Sign Out" or just close the browser, their session stays open and the next person to visit that site is logged in with the previous users credentials. Many of our users will be logging onto this Sharepoint site from public computers so this is a huge security risk. Has anyone found a good solution to this problem that still allows users to edit documents on the site using Microsoft Word or Excel.
Sharepoint 2013 Login redirect iRule problems
Hi, I'm having a problem with a Irule applied to a VS loadbalancing a sharepoint site. when HTTP_REQUEST { switch [HTTP::host] { sh.domain.com { if { [active_members SHAREPOINT_2013_HTTPS_pool] < 1 } { HTTP::respond 200 content {some content} } if { ( [string tolower [HTTP::uri]] contains "login.aspx" ) and ( [IP::addr [IP::client_addr] equals 10.0.0.0/8]) } { HTTP::redirect "https://sh.domain.com/_windows/default.aspx?ReturnUrl=/" } pool SHAREPOINT_2013_HTTPS_pool } sh.domain2.com { if { [active_members SHAREPOINT_2013_HTTPS_pool] < 1 } { HTTP::respond 200 content {some content} } if { ( [string tolower [HTTP::uri]] contains "login.aspx" ) and ( [IP::addr [IP::client_addr] equals 10.0.0.0/8] ) } { HTTP::redirect "https://sh.domain2.com/_windows/default.aspx?ReturnUrl=/" } pool SHAREPOINT_2013_HTTPS_pool } } } What happens: Internal users: User wants to access URL: https://sh.domain.com/testguy Without the irule, internal clients connects to the sharepoint site from a ip in the 10.0.0.0/8 subnet, and are automaticly redirected to a sharepoint login page. The user then has to click a link to log inn. Clicking this link does nothing but redirect to https://sh.domain.com/_windows/default/.aspx?ReturnUrl=/testguy With the iRule, internal clients buypass the login screen correctly, but they are riderected to the home page of sharepoint (another redirect that happens when you request https://sh.domain2.com/_windows/default.aspx?ReturnUrl=/) Trying to access the original URL : https://sh.domain.com/testguy again within the same browser now works correctly because the user is never redirected to login page, and therefor just sent straight to the pool. External users: Is currently working as expected. They are sent to login page, and have to click the login button and present credentials, and then redirected to the correct page. How can I have my internal users buypass the login page, and automaticly redirected to the requested URI? Is there a way to append the original URI to https://sh.domain2.com/_windows/default.aspx?ReturnUrl=/[HTTP::uri] without causing a redirection loop? I have tried the above statement, but it creates a loop because the HTTP:uri is now the login page. Appreciate all input!
F5 primary authentication URI - Session Expired issue
The F5 Guide for SharePoint 2013 says: "F5’s APM and AAM modules also support the deployment of host-named site collections. When deploying the SharePoint iApp, you must enter each site collection FQDN in the "What FQDNs will clients use to access the servers?" question of the template. When accessing the web application via BIG-IP APM, the client will be redirected to the primary authentication URI, which is the first host entered in the FQDNs table. After authentication, BIG-IP APM redirects the client to the original request URI." This works when logging in, however I am finding that if my session expires and you then click the "new session" it directs you to login to the primary authentication URI (not the site one was logged into), and if you don't have permissions to that primary authentication URI site then you get an access denied message, moreover if you do have access to the primary authentication URI site you login in to the primary authentication URI site which may not be the site you wanted to login to. Example: I request apple.contoso.com F5 redirects me to the primary authentication URI login.contoso.com I login F5 redirects me back to apple.contoso.com I go for lunch and come back only to find my session has expired and F5 page displaying I click "new session" and it goes back to login.contoso.com I login but get access denied because I do no have access to the login.contoso.com site (or if I have permissions to login.contoso.com site it logs me into that site and not apple.contoso.com the site I was originally on. Does this makes sense? Is this by design or have we configured something incorrectly? Any help appreciated.
Office 2016 + APM protected Sharepoint
Hi All, I am in the process of testing out the use of on-premise Sharepoint 2013, protected by APM, and Office 2016. Particularly on OSX or without the use of Internet Explorer on Windows, as many of my users prefer Chrome or Firefox. I've used the persistent cookies feature in the past, but it seems as though there is a big lack of support for OSX. My question is, is there any way to make the end-user experience better? Many users would like to use locally installed copies of Office when working in Sharepoint, and so far the only way I've found to deal with this is to use something like a user-agent match to trigger the ACCESS::disable function, which I dislike. Looking at the Client for MS Exchange agent seems promising, as it appears to be able to correctly detect the need for clientless mode, and challenge for credentials. Right now users who attempt to open docs on OSX will generally receive the F5's login page as the content of their document. I'm not so concerned with needing single sign-on (would be nice to have), but would prefer that users are properly challenged when using an Office client. I'm going to continue testing alternative methods, but would appreciate any insights anyone may have. Thanks! Josh
SharePoint 2013 Search re-write host
I am trying to solve a SharePoint 2013 search issue using the F5. We are using ADFS for our authentication so we had to extend the web app to enable NTLM authentication to get the search crawl feature working. We setup out Alternative access mappings and things display ok on the page. The issue we have is when you hover over a document the preview points to the search URL (NTLM) instead of the portal URL (ADFS) and the users are prompted to authenticate. I have tried to setup an empty stream profile and an iRule to replace the hostname but it does not appear to be working. I am also not seeing anything in my logs so I am stumped. iRule: when HTTP_REQUEST { Disable the stream filter for requests STREAM::disable Remove this header to prevent server from compression response HTTP::header remove Accept-Encoding } when HTTP_RESPONSE { if { [HTTP::header "Content-Type"] starts_with "text/" } { STREAM::expression "@spcenter-search.domain@spcenter.domain@" STREAM::enable log local0. "[IP::client_addr]:[TCP::client_port]: Enabled stream filter for spcenter-search.domain -> spcenter.domain" } else { log local0. "Replace rule did not trigger" } }How do I disable TLS 1.1 for the SharePoint 2010-2013 IAPP v 1.2.1
I am using the SharePoint IAPP to support our SharePoint farm. We are on 2013. We need to disable TLS 1.0 and 1.1 and I want to do so without breaking our SharePoint implementation. I am not able to change the existing SSL Client Profile because I am using the IAPP. Guidance for the best way to resolve this would be very much appreciated.
3 part redirect irule query. non www to www to https
Hello All We recently moved over to F5's from another load balancer product and have been gradually moving our staging and live services over after testing has been completed. However one issue has come up. On our previous load balancer there was a http redirect in place so that when users tried to access our SharePoint site without the www. prefix it would redirect them to a specific url e.g. https://www.sharepointsite.com/sites/homepage.aspx We have it set in the SharePoint 2013 iApp to redirect http traffic to https but my understanding is to do non www to www. we need a iRule. Is that correct? I realise this may sound a fairly trivial issue but all will become clear shortly. The reason why this isn't trivial is because I won't be able to test this on our staging area, I can only apply it on live, so I have to ensure I get it right. The reason for this is our staging area is https://staging.sharepointsite.com so the iRule wont be the same as if I was redirecting non www to www. I've spent some time searching on here and haven't found anyone else in exactly the same situation but did find a rule that I think will work. Please can you advise if what I've written below will work if I introduce it into a SharePoint 2013 iApp's config as a iRule. Or if not can you offer advice on what will work please. when HTTP_REQUEST { if { [string tolower [HTTP::host]] ends_with "sharepointsite.com" } { HTTP::redirect "https://www.sharepointsite.com[HTTP::uri]" } } That to me looks like it should work but I wondered if that maybe wouldn't be the case when introduced to a iApp. Or if it may take issue with the face theres no dot/fullstop/period before the initial sharepointsite.com Thanks in advance Rhys.SharePoint 2013 functions breaks after Big IP upgraded to version 14.2
We have a SharePoint 2013 On-premise custom application, which lost some functionality after our recent Big-Ip upgrade to version 14.2. The landing page with a few webparts (including a Calendar webpart) will only display if we disable compression, but then all SharePoint List functionality such as filtering on columns, sort, pagination, etc. don't work and when expanding ">" in a List that has been "Grouped by" columns, we see the message "Working on...". For the filtering problem, we see a message about "insecure" pages and have to allow the content to display, the filter then displays the list of selections, but then making a selection does nothing-no filtering occurs. We can fix these List issues with an iRule shown below, but then the webpart page will stop displaying. It seems like this iRule and the decompression are "working against each other". We have tried using iApp template 1.0.0, 1.2.2 and 1.2.3. IRule: when HTTP_REQUEST { tell server not to compress response HTTP::header remove Accept-Encoding disable STREAM for request flow STREAM::disable } when HTTP_RESPONSE { catch and replace redirect headers if { [HTTP::header exists Location] } { HTTP::header replace Location [string map {"; ";} [HTTP::header Location]] } only look at text data if { [HTTP::header Content-Type] contains "text" } { create a STREAM expression to replace any http:// with https:// STREAM::expression {@http://@https://@} enable STREAM STREAM::enable } } Any idea how we can have both functionality working? Thanks!
