asked on
Sharepoint Foundation 2010 Configuring External Access
Hello experts,
We are currently rebuilding and redesigning our intranet, moving from a Joomla based CMS to Sharepoint Foundation 2010. I've been all over Google and read numerous articles on Forms-Based Authentication and such. We have a need to "extend" the web applications of SP to external users in our company, that are not on the main domains. We have our SP set up in the following way:
2 Win 2008R2 servers
Primary server: SP Foundation 2010, MSSQL 2008, main SP database and site collections
Secondary server: SP Foundation 2010 (same farm), content pages. (These are not online yet.)
Sharepoint itself works fine internally. Also, I've been able to successfully set up forms based authentication on a test site collection and it also works fine internally.
Now, at this point, we'd like to extend the main web application (Sharepoint - 8080) to the outside with a custom domain name (http://mysite.mydomain.com, for example).
I have taken the following steps:
1. Converted the original web app from Windows authentication to Claims authentication.
2. Extended the web app through the following process:
a. From Manage Web Applications in Central Admin, I clicked on the main site, and clicked "Extend.
b. I followed the screen, creating a new site, using the my external URL as the name, port 80 for the default port, the external url as the host header, Yes to Allow Anonymous, No to SSL (testing for now), checked both Enable Windows Auth and Enable FBA, filled in my provider name and manager name from the working config, and accepted all other defaults.
3. FBA was previously configured through a test site and is confirmed to be working on that site, but I cannot test on the new site.
I am unable to access the new extended site internally to test FBA, I get a 404 error on that site.
I've been spending a lot of time on this and I'm pretty fried. Hoping someone can help me out here.
Thanks!
We are currently rebuilding and redesigning our intranet, moving from a Joomla based CMS to Sharepoint Foundation 2010. I've been all over Google and read numerous articles on Forms-Based Authentication and such. We have a need to "extend" the web applications of SP to external users in our company, that are not on the main domains. We have our SP set up in the following way:
2 Win 2008R2 servers
Primary server: SP Foundation 2010, MSSQL 2008, main SP database and site collections
Secondary server: SP Foundation 2010 (same farm), content pages. (These are not online yet.)
Sharepoint itself works fine internally. Also, I've been able to successfully set up forms based authentication on a test site collection and it also works fine internally.
Now, at this point, we'd like to extend the main web application (Sharepoint - 8080) to the outside with a custom domain name (http://mysite.mydomain.com, for example).
I have taken the following steps:
1. Converted the original web app from Windows authentication to Claims authentication.
2. Extended the web app through the following process:
a. From Manage Web Applications in Central Admin, I clicked on the main site, and clicked "Extend.
b. I followed the screen, creating a new site, using the my external URL as the name, port 80 for the default port, the external url as the host header, Yes to Allow Anonymous, No to SSL (testing for now), checked both Enable Windows Auth and Enable FBA, filled in my provider name and manager name from the working config, and accepted all other defaults.
3. FBA was previously configured through a test site and is confirmed to be working on that site, but I cannot test on the new site.
I am unable to access the new extended site internally to test FBA, I get a 404 error on that site.
I've been spending a lot of time on this and I'm pretty fried. Hoping someone can help me out here.
Thanks!
Microsoft Server AppsMicrosoft SharePointMicrosoft Server OS
Last Comment
dossaviation
ASKER
vaderj,
First, thank you for taking a moment to help me.
Answers, in order:
The environment is not load balanced yet. It is still in testing. We do plan to implement this as we move into production.
The DNS does not resolve internally, and I suspect that is because we have not created an internal zone for it yet. However, I can't reach the extended site via IP address either. Also, our external DNS provider (network solutions) does not resolve the new name to IP yet.
Yes. IIS has the host headers correct, external address of skyXXX.XXXXX.net (name purposely hidden) and IP of the internal server. (I think that's correct?)
I cannot access the front end of the newly extended site, so I can't test the user store. I can't access that by IP or by name. The successful test of the user store can be done on another site collection that is not connected to the extended site. Sorry for any confusion there.
The web application is currently in the Default and Internet zones. The extended one, of course, is the Internet zone. Both are set to Claims Based Authentication. The Internet zone has Enable Windows Authentication, Integrated Windows Authentication with NTLM, Enable Forms Based Authentication, with an ASP.NET membership name of LDAPMembers. Like I said, I have no way to test this authentication. It does work on the other test site, so I think it's a good configuration.
That being said, I'm not 100% sure that these settings are correct. I freely admit to being a little Sharepoint dumb.
Thanks again for your help!
First, thank you for taking a moment to help me.
Answers, in order:
The environment is not load balanced yet. It is still in testing. We do plan to implement this as we move into production.
The DNS does not resolve internally, and I suspect that is because we have not created an internal zone for it yet. However, I can't reach the extended site via IP address either. Also, our external DNS provider (network solutions) does not resolve the new name to IP yet.
Yes. IIS has the host headers correct, external address of skyXXX.XXXXX.net (name purposely hidden) and IP of the internal server. (I think that's correct?)
I cannot access the front end of the newly extended site, so I can't test the user store. I can't access that by IP or by name. The successful test of the user store can be done on another site collection that is not connected to the extended site. Sorry for any confusion there.
The web application is currently in the Default and Internet zones. The extended one, of course, is the Internet zone. Both are set to Claims Based Authentication. The Internet zone has Enable Windows Authentication, Integrated Windows Authentication with NTLM, Enable Forms Based Authentication, with an ASP.NET membership name of LDAPMembers. Like I said, I have no way to test this authentication. It does work on the other test site, so I think it's a good configuration.
That being said, I'm not 100% sure that these settings are correct. I freely admit to being a little Sharepoint dumb.
Thanks again for your help!
So lets step back and get the external site in an accessible state:
1.) Try disabling your FBA providers so that only NTLM is enabled
2.) in your IIS binding for the extended web app, remove the IP from the binding definition such that only the host header is present.
Your test servers do not have an external IP they are directly associated with correct? Is there some form of reverse proxy between your WFE (web front end) and the internet? Is your RevProxy configured to correctly forward all requests for the particular host header over to your WFE?
For testing purposes as well, it may be benificial to grab a VM in the same domain as the test WFE and insert a HOSTS file entry (c:\windows\system32\drive
1.) Try disabling your FBA providers so that only NTLM is enabled
2.) in your IIS binding for the extended web app, remove the IP from the binding definition such that only the host header is present.
Your test servers do not have an external IP they are directly associated with correct? Is there some form of reverse proxy between your WFE (web front end) and the internet? Is your RevProxy configured to correctly forward all requests for the particular host header over to your WFE?
For testing purposes as well, it may be benificial to grab a VM in the same domain as the test WFE and insert a HOSTS file entry (c:\windows\system32\drive
ASKER
OK. Let me try your suggestions. I'll post back ASAP. Thanks!
ASKER
Also, there are no proxies in between. I have not yet forwarded the ports from our Cisco ASA to the servers as I wanted to get this working internally first.
ASKER
OK, I was able to perform all the steps you asked for, and I'm still unable to access the site internally. I expect my network guys to have the external ports open today that we need, so I'll try testing from the outside as well. Do you have any other suggestions?
One other thing I was thinking...do you think I should extend the app again into the Intranet zone for internal access? Right now its only in two zones, Default and Internet.
Thanks!
One other thing I was thinking...do you think I should extend the app again into the Intranet zone for internal access? Right now its only in two zones, Default and Internet.
Thanks!
that should not be necessary.
Do the alternate access mappings correspond with the Authentication Providers?
Can you even ping the server?
Do the alternate access mappings correspond with the Authentication Providers?
Can you even ping the server?
ASKER
Hmmm...I did not check the AAM yet. Let me do that. Yes, I can ping the server.
ASKER
Well, I think I may just start over. I've actually succeeded in rendering the entire site collection unavailable now. I'm going to delete it and try again. I'll keep you posted on our progress. Thanks.
ASKER
So I've recreated a new site, and extended it per the instructions. I can browse internally just fine via the new outside address (http://sharepoint.company.net) but that same address does not work externally. I set up a record in DNS so that internal users would use the external address.
I can ping sharepoint.company.net from an external machine and it resolves just fine. Ping replies as well. My firewall is configured correctly and is pointing that external IP to the internal server address.
My AAMs are set for:
Default Zone: Internal URL is http://server:8080. Public URL is http://server:8080.
Extranet Zone: Internal URL is http://sharepoint.company.net. Public URL is http://sharepoint.company.net.
Yet I cannot browse the external site from outside.
This is so frustrating.
Thanks.
I can ping sharepoint.company.net from an external machine and it resolves just fine. Ping replies as well. My firewall is configured correctly and is pointing that external IP to the internal server address.
My AAMs are set for:
Default Zone: Internal URL is http://server:8080. Public URL is http://server:8080.
Extranet Zone: Internal URL is http://sharepoint.company.net. Public URL is http://sharepoint.company.net.
Yet I cannot browse the external site from outside.
This is so frustrating.
Thanks.
what are you getting? 404? server responding at all?
Have you ran an IISReset?
Maybe restart everything between your SharePoint WFE and the internet connection?
Have you ran an IISReset?
Maybe restart everything between your SharePoint WFE and the internet connection?
ASKER
Getting a blank page. No 404 or response at all.
Chrome says Server Sent No Data.
I did run an iisreset. I restarted everything, even the server itself. I have a Cisco ASA, and I'm not going to bounce that one.
Thanks!
Chrome says Server Sent No Data.
I did run an iisreset. I restarted everything, even the server itself. I have a Cisco ASA, and I'm not going to bounce that one.
Thanks!
oh dear - I have had multiple nightmarish experiences with ASA's (5505's) - Do you have any other sites behind the ASA that you are able to access externally?
From my experience, ASA's do not have any reverse proxy functionality - what are you using to translate the external subdomain and forward the request to the proper server?
Fortunately, there should be absolutely no reason to restart the ASA - if there is anything to be said about them, its that they are stable!
From my experience, ASA's do not have any reverse proxy functionality - what are you using to translate the external subdomain and forward the request to the proper server?
Fortunately, there should be absolutely no reason to restart the ASA - if there is anything to be said about them, its that they are stable!
ASKER
Yeah, we've had our fair share of ASA issues as well...but we have two other sites that translate through it and work fine.
No other devices stand between the gateway and the server. It's all on the ASA.
No other devices stand between the gateway and the server. It's all on the ASA.
can you try this - can you disable the SHarePoint IIS site in IIS Manager, enable the default site and attempt to access it externally?
ASKER
I must be doing something wrong...I now get a 404 page internally, still same condition externally...no data received.
ASKER
Apologies...I had not started the default site. I have an IIS7 splash page internally, nothing externally. Same condition.
OK so it sounds as though somthing is preventing the completion of the request. Can you try completely disabling the Windows Firewall for just a moment to do a test? It sounds like its beyond SharePoint since the prior test also failed.
ASKER
Already disabled it. None of our servers run the Windows Firewall.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Got it. I just finished running a packet tracer from my ASDM...and I show a dropped NAT packet. I'm working on that now to see what I can do. I'll keep you posted.
ASKER
vaderj,
It was indeed my ASA. We had recently upgraded our ASA from version 8.2 to version 9. You may or may not be aware of all the changes in the code to the new version, but in a nutshell, all of our NAT statements were incorrect for the new server. All is fine now and we were able to successfully browse our test sites from an external computer.
Not really a solution, I know, but I'm awarding you the points for your help and patience.
Thank you very much!
It was indeed my ASA. We had recently upgraded our ASA from version 8.2 to version 9. You may or may not be aware of all the changes in the code to the new version, but in a nutshell, all of our NAT statements were incorrect for the new server. All is fine now and we were able to successfully browse our test sites from an external computer.
Not really a solution, I know, but I'm awarding you the points for your help and patience.
Thank you very much!
ASKER
Ultimately, our external Cisco ASA was not configured correctly for static NAT. vaderj was on the right track with looking at external requests. I'm awarding points based on his/her help and patience.
Is this environment load balanced?
When you resolve the DNS address, does it resolve to the same IP internally as it does externally?
Does the IIS site (on all of your web front ends) for your newly extended web app contain in the IIS bindings, the host header?
From your web front end, can you directly access your user store? (whether that be the SQL DB, the AD-LDS instance, or otherwise)
What are the zones that you extended your web application to, along with their associated Authentication Provider settings? (I know you mentioned this, this is more to spur you to just make sure that they are associated correctly for your environment)