The network path is as follows:
Browser ---https---> load balancer ---http---> SharePoint servers
However, it turns out to be not an easy task. We found that the URLs embedded in http responses (such as form action link) from SharePoint are in http. Since SharePoint never knows that the traffic was originally https (as you can see from the network path above), of course it would embed URLs in http. It kind of makes sense.
I searched all over the places to see if someone had already found a solution.
One suggestion was to use the stream profile of the load balancer as workaround:
- On the BigIP load balancer, under Local Traffic | Virtual Servers | Profiles, choose Others | Stream.
- Create a Stream profile with Settings:
Source http://sp.domain.com
Target https://sp.domain.com
It does work. All "http://sp.domain.com" in the http responses from SharePoint would be replaced by "https://sp.domain.com". If you decide to purse this approach, you must read AskF5 knowledge base article SOL6422: Using the Stream profile with HTTP traffic may prevent the client from displaying all of the data. It documents a known issue of Stream profile, and the workaround.
But I am persistence, and kept pursuing further for the real fix in SharePoint. The following two articles had been very useful in helping me derive my own solution using BigIP load balancers.
- F5's Deployment Guide Microsft SharePoint Portal Server 2003 (BIG-IP v9.x)
- Microsoft SharePoint Team Blog What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3)
It took me a day, and I think I figured it out:
- First you create a Sharepoint site in default zone, and port
spsite port 8888 - Sharepoint will create the web application, content database accordingly.
- Then, extend this web application to a new SharePoint web site with your internal host name, port, and no SSL
http://sp.domain.com port 80 - In the Load Balanced URL field, use https://sp.domain.com (yes, https here!).
- Put this site in Internet zone.
- Then, go to Operations | Alternate Access Mapping. You will see that the following entries:
Internal URL Zone Public URL for Zone http://spsite:8888 Default http://spsite:8888 https://sp.domain.com Internet https://sp.domain.com
- Now, click on Add Internal URLs. Add your internal non-SSL url as Internet Zone.
http://sp.domain.com Internet - Then, go back to Operations | Alternate Access Mapping screen. You will see that the following entries:
Internal URL Zone Public URL for Zone http://spsite:8888 Default http://spsite:8888 https://sp.domain.com Internet https://sp.domain.com http://sp.domain.com Internet https://sp.domain.com
21 comments:
Hello
I am in a similar situation, and after setting the appropriate configuraitons, it still did not worked for me.
May I ask if you have any iRules set on the load balancer, and if SSL Client side profile was enforced?
The problem that I have having is that the authentication windows does not even popup (using Windows NTLM to access the sharepoint site)
Please help. Thanks.
I have two iRules, one listening on port 80. It redirects all traffic to the https 443 virtual server.
The other iRules listens on port 443. It only checks the host header to make sure it is calling our sharepoint web application by hostname (basically, screening out attacks/scannings that use IP address to connect to our server).
I have SSL Profile (Client) enabled on the virtual server that listen on 443 port. It points to our SSL key/ certificate pair of our sharepint web application.
One thing you might look at is.... if you remote desktop to your sharepoint frontend node directly (ie. behind load balancer), and access your sharepoint web application in the default zone with a browser (in the example above, it will be http://spsite:8888)... do you get the authentication prompt (assuming you do not put http://spsite in IE trusted zone) ?
Thanks for the reply, and to answer your question when I Remote desktop to my Sharepoint application server, browse to the default zone, it works fine.
I am trying to achieve what is describe in the article, using HTTPS from Client to the Load Balancer and only HTTP from the Load Balancer to the Sharepoint App Server.
I have set up the AAM rules as required, the web application is a "http" extended from the original web application.
However we are having trouble with the iRules. Could you share your iRules code? We are using the iRule to go from HTTPS -> HTTP
Virtual Server settings
- SSL Profile (Client) enable
Is your Virtual Server, members pool, which points to the Sharepoint App Server via port 80?
Thanks for your help. Having been pulling hairs out for the past few days.
This is the iRule for the virtual server listening on port 80. What it does is to redirect all traffic to port 443.
ie. if users access our sharepoint site using http, load balancer always redirects it to https. And all subsequent traffic between client and load balancer are all https.
But the traffic between load balancer and our sharepoint servers are always http.
-------------------------
when HTTP_REQUEST {
if { ([string compare -nocase -length 20 [HTTP::host] "teamsite.oue.wsu.edu"] == 0) } {
HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}
else {
log user.notice "[IP::remote_addr] accessing [HTTP::host] [HTTP::uri] redirected to outage"
HTTP::redirect "http://outage.ctlt.wsu.edu"
}
}
-------------------------
This is the iRule for the virtual server listening on port 443. It seems long, but when you examine it, it just does some url redirection for users to go to the right place.
-------------------------
when HTTP_REQUEST {
if { ([string compare -nocase -length 20 [HTTP::host] "teamsite.oue.wsu.edu"] == 0) } {
set uri [HTTP::uri]
if { ([string compare -nocase -length 19 $uri "/_layouts/help.aspx"] == 0) } {
log user.notice "[IP::remote_addr] accessing [HTTP::host] [HTTP::uri] [HTTP::method] Sharepoint 2007 vulnerability"
HTTP::redirect "http://outage.ctlt.wsu.edu/sharepoint_help.html"
}
elseif { ([string compare -nocase [HTTP::uri] "/ctlt"]==0) or ([string compare -nocase [HTTP::uri] "/ctlt/"]==0)} {
HTTP::redirect "https://[HTTP::host]/ctlt/home"
}
elseif { ([string compare -nocase -length 17 [HTTP::uri] "/progeval/EECSCap"]==0) and (not ([string compare -nocase -length 22 [HTTP::uri] "/progeval/EECSCapstone"]==0)) } {
set uri [HTTP::uri]
set urilength [string length $uri]
set uripath [string range $uri 18 $urilength]
HTTP::redirect "https://[HTTP::host]/progeval/EECSCapstone/$uripath"
}
else {
pool TeamSite
}
}
else {
log user.notice "[IP::remote_addr] accessing [HTTP::host] [HTTP::uri] redirected to outage"
HTTP::redirect "http://outage.ctlt.wsu.edu"
}
}
-------------------------
We just retired our departmental teamsite.oue.wsu.edu and so it is not up, unfortunately. But these iRules are our working ones.
Thanks for the info, I will look into the irules coding.
Hello
I had a look at the code and coded something similar to use on the Load Balancer for testing but I am getting "weird" results.
Looking at the HTTP::redirect bits, after using them, I notice that my web browser is displaying the non http URLs, and it seems that the browser on my machine is now "talking" directly to the MOSS App server, without going through the Load Balancer. The reason why I am saying this is because in the IIS logs on the MOSS App server, I could see my machine's IP address and the packet sniffer says that packets are coming from my machine and not from the Load Balancer. Is it meant to be that way?
Maybe I got this wrong or understood something wrong, but this is what I have on my MOSS App Server AAM
In the Default Zone (Internal URLs -> Public URL)
http://moss.server.com -> http://moss.server.com
In the Internet Zone (Internal URLs -> Public URL)
https://devext.server.com -> https://devext.server.com
http://devext-server.server.com -> https://devext.server.com
My iRule is a simple redirect
HTTP::redirect "http://devext-server.server.com"
Is there something wrong with my settings? I read somewhere about setting ReChunck on the Load balancer. Do you use that?
Hello
After looking at the code and tried using it on our Load Balancer here it does not seems to work.
What it did was that the HTTP::redirect, redirect to the MOSS App server, and my web browser displays links in non HTTP. I thought that they were all suppose to be HTTPS links.
My AAM setup is as follows
Internal -> Public URL
Default Zone
http://moss.server.com -> http://moss.server.com
Internet Zone
https://devext.server.com -> https://devext.server.com
http://devext-server.server.com ->
https://devext.server.com
Now I am using the iRule
HTTP:redirect "http://devext-server.server.com"
The requests goes to the load balancer, then goes to the MOSS App server but after that it seems my web browser is "communicating" with the MOSS App server directly without going to the Load balancer any longer.
All the links in my web browser is displaying as http://devext-server.server.com instead of https://devext.server.com
Am I missing some settings or steps?
Werid, my comments seems to have disappeared!
Hello
After looking at the code and applying it in my Load Balancer, it seems to have the following effects.
In my web browser, browsing to the URL on the load balancer, it "redirects" me to my MOSS App server (my iRule is HTTP::redirect "http://devext-server.server.com")
After this it seems that all links in my web browser is displayed with the URL from my MOSS App server and not the HTTPS URL from the load balancer.
Looking at the IIS logs it seems that the browser has now established a direct connection to the MOSS App server.
I was under the impression that all communications would go through the Load balancer.
Am I missing something here?
Thanks,
Ok, so we are trying to prove this configuration in our test environment. We are content deploying from http://business-dev.mydomain.com to http://business-test.mydomain.com and we are try to set up SSL termination on the F5. So far, I've extended the http://business-test.mydomain.com application as http://business.mydomain.com. Our guys have not configured the F5 yet but I notice that when try to access http://business.suddenlink.com, I get no response. I did this by remoting into the Central Admin/Index server that has the host entry for loop back configured. I've also verified that the web application exists IIS. Is there something I'm missing? Neither https://business.mydomain.com nor http://business.mydomain.com serve back content while the original http://business-test.mydomain.com does.
FYI, http://business-dev.mydomain.com is in a different farm than http://business-test.mydomain.com
hi, Michael
I'm trying to understand your test environment.
I suppose you mean http://business-test.mydomain.com is in the default zone. And you extend it to http://business.mydomain.com in the internet zone.
What is the IP address this business.mydomain.com being resolved to? If it is resolved into the subnet that belongs to the external side of the load balancer, then you cannot test this in the central administration/ index server (presuming it is in local network behind the load balancer).
Or do you mean you have the hosts file on your sharepoint central admin/index server with business.mydomain.com resolve into the loopback IP 127.0.0.1? And you are trying to test the access of http://business.mydomain.com from there? Then is the sharepoint web frontend running on the central admin server, or on another node? I presume it is on a different server (otherwise you would have said you are testing on the web frontend server). Then it won't work since the loopback IP is only local to the central admin/index server.
You can try by using (or adding if needed) a local IP on the sharepoint web frontend server, and configure the host file on a machine behind load balancer to resolve business.mydomain.com into that local IP. Make sure you do not have SSL when you extend the site. No https in this test since you are not using load balancer + SSL yet. If it still does not work, check your sharepoint web frontend IIS settinga (e.g. host header, IP, and port need to match). Resist changing the settings there in IIS directly. Changes need to be done in sharepoint and populate down into IIS. Hope this helps!
I tested it on all the servers. I added an entry in my machines host file. I tried each server and still nothing. For some reason, this extended web application isn't serving up any content. I see that you put the original site on port 8888... what was the specific reason for that? http://business-test.mydomain.com was already on port 80 and I assumed that I would be fine extending business.mydomain.com on port 80 as well. That's pretty much the only difference I have from what you described in the article.
Thanks, I appreciate your help.
hi, Michael
You can use either different port numbers, or host headers.
In my case, I choose to use port number because it is clear to me. First, it is easy to test behind load balancer. When I specify the port number in the URL, I know exactly which IIS website should be serving my requests. And when I put that in the load balancing pool in load balancer, I again know exactly which IIS website will be serving the http requests to sharepoint from the internet.
Ok... So I guess I should explain our problem here. We have many public faced sites in our SharePoint enviroment and we have once site that is using SSL on port 443 using a wildcard cert *.mydomain2.com. This is creating a problem because now we have a site that needs to be secured using our wildcard cert *.mydomain.com. This is a problem since we can't have both certs on port 443. We've tried to use your configuration to offload the cert onto the load balancer but we were unable to get it to work.
New solution:
So I've extended http://business-test.mydomain.com to https://business.mydomain.com:1443 (using https://business.mydomain.com as the load balanced url) so I can bind the *.mydomain.com cert to 1443. We've configured the load balancer to take requests at https://business.mydomain.com:443 and forward to the SharePoint front ends https://business.mydomain.com:1443. Everything seems to be working fine, except for the fact that https://business.mydomain.com will not return the default page unless you put in the full path https://business.mydomain.com/pages/default.aspx. Also, when I click to sign in, it takes me to https://business.mydomain.com:1443/authenticate.aspx
Errr.. I know it's a AAM problem, but I'm so lost in understanding how it works with ports. Any ideas?
hi, Michael
I'm not sure why your latest comment disappeared from this post. I got that via the from google.
To answer your question:
You need to have two entries in the **Internet Zone** in AAM. I believe it should look like this in your case:
https://business.mydomain.com Internet https://business.mydomain.com
http://business.mydomain.com:1443 Internet https://business.mydomain.com
Also, the wildcard certificate *.mydomain.com does not need to bind to the IIS site. In fact, IIS never needs to have the private key/ certificate. It never needs to handle SSL at all. It is all done at the load balancer (if it is BigIP, then it is the "SSL Profile (Client)" setting in the virtual server).
The process is:
browser sends request packet for https://business.mydomain.com
load balancer receives the request packet for https://business.mydomain.com, decrypts it, and forwards the request as http://business.mydomain.com:1443 to sharepoint/IIS.
(Load balancer does not change the host header by default. It just takes out the SSL, forwards it to an local IP address and port number in the load balancing pool. So the routing works even though you may think business.mydomain.com belongs to external IP.)
IIS receives the request as http://business.mydomain.com:1443. Prepare the response to send back. Since this http://business.mydomain.com:1443 is defined as Internal URL in AAM, Sharepoint/IIS then changes all reference to http://business.mydomain.com:1443 in the response payload (content of the response) to https://business.mydomain.com and sends the response back to load balancer.
The load balancer receives the response packet from IIS (in that opened connection in port 1443 between load balancer and IIS). The connection between load balancer to IIS is never encrypted. The load balancer encrypts the response packet and sends it to browser (in the opened connection in port 443 with the browser).
The browser receives the response packet, and shows you the sharepoint page. In that page, you should not see any http://business.mydomain.com:1443 link (such as in form submission) because it should have already been taken care of by the Sharepoint/IIS AAM. They should all be https://business.mydomain.com.
Hope this helps!
You are amazing!!!! I added internal url https://business.mydomain.com:1443 and it fixed everything. Thanks a bunch!!! I want to give you a big hug!
hi, Michael
I'm glad to hear that fixed the problem. Share the "wealth" you now have and Pay it forward!
Cheers!
Corinna, Thank you for your sharing. It solved the issues that bothered me for days. Even I still don't fully understand why need to set up an unrelated web app first then extend to the port 80 one and the trick of AAM but it WORKS. Thank you!
Users are getting multiple prompts of NTLM login. The only person not getting that many was farm admin. Any advises? All users traffic are from Internet.
Corinna,
Would I be able to use this method with Citrix NetScaler load balancer? I have an existing SharePoint 2007 Farm which requires SSL. I am a newbie and will need all the help you can offer!!
Thanks,
Nee
Post a Comment