SharePoint 2013 - Can't access the site externally in Internet Explorer ("Page cannot be displayed")
Synopsis
Before we start talking about the problem let's understand the setup here. We have a SharePoint 2013 intranet site that is also configured for access outside of the corporate network. Employees use the same URL to visit the site both internally and externally via standard ports (80 and 443).| Internal URL: | http://sharepoint.domain.com |
| Public URL: | https://sharepoint.domain.com |
The site URL has been added to the Local Intranet zone in Internet Explorer for passing domain credentials.
Alternate Access Mappings have been configured in such a way that if a user requests the site over HTTP they are automatically re-directed to HTTPS.
| Internal URL | Zone | Public URL for Zone |
| https://sharepoint.domain.com | Default | https://sharepoint.domain.com |
| http://sharepoint.domain.com | Default | https://sharepoint.domain.com |
Web application has been configured to use Kerberos protocol for authenticating incoming client requests (default zone).
It is also important to note that external access to the site is provided by configuring 1-to-1 NAT on the firewall, and by creating an entry in the external domain registry (DNS).
TIP: Allowing access to internal network assets from outside the corporate network is best approached by configuring a Web App Proxy (now a role in Windows Server 2012 R2), or making use of FIM based products such as Forefront Unified Access Gateway (UAG). Configuring external access solely via NAT in the firewall opens up your network to potential security threats.
The Problem
Users have reported that they aren't able to access the site externally, unless of course they are on VPN. To be more specific, if a user is trying to access the site from outside the corporate network, using their (domain-joined) machine, they get this:
What makes it even more interesting is that this happens only when using Internet Explorer, which is a company approved browser. The site is accessible via Chrome, Firefox, Safari, etc. I know what you're thinking; "this smells like an issue with a Group Policy", which is applied to a company-standard browser. Not so fast. Countless hours into reviewing GPOs, not a single lead that this could possibly be the culprit.
Furthermore, if the site URL is added to the Trusted Sites zone in IE, problem solved! However, that automatically prompts users for credentials inside the corporate network, which is what we do NOT want.
Furthermore, if the site URL is added to the Trusted Sites zone in IE, problem solved! However, that automatically prompts users for credentials inside the corporate network, which is what we do NOT want.
The Solution
Enough rambling, let's get down to business. With integrated windows authentication, the client browser will first attempt to access the resource anonymously (HTTP GET request). Anonymous access isn't configured for the site in question, therefore the server responds with a 401.2 error.
The client browser will then move on and try authenticating via Kerberos or NTLM channels to negotiate a connection with SharePoint. This is where things begin to crumble, as the client can't seem to contact Key Distribution Center (KDC) which grants client a ticket to access a network resource. The only way this succeeds is if the site URL is added to Trusted Sites which, if you remember from earlier, does not pass credentials internally for authentication.
To make this finally work, we must change the precedence of authentication providers in IIS. Perform the following steps on each SharePoint front-end server:
1. Open Internet Information Services (IIS) Manager
2. Expand the Sites node and select the site in question
The client browser will then move on and try authenticating via Kerberos or NTLM channels to negotiate a connection with SharePoint. This is where things begin to crumble, as the client can't seem to contact Key Distribution Center (KDC) which grants client a ticket to access a network resource. The only way this succeeds is if the site URL is added to Trusted Sites which, if you remember from earlier, does not pass credentials internally for authentication.
To make this finally work, we must change the precedence of authentication providers in IIS. Perform the following steps on each SharePoint front-end server:
2. Expand the Sites node and select the site in question
3. In the IIS section double-click on Authentication
4. Highlight Windows Authentication and select Providers form the Actions menu.
5. Select NTLM from the list of enabled providers and click Move Up
6. Perform an IISRESET
7. Try accessing your site externally from a domain-joined machine, using Internet Explorer
7. Try accessing your site externally from a domain-joined machine, using Internet Explorer
NOTE: Keep in mind that this changes precedence of how the incoming requests will authenticate (NTLM first).
Good day,
ReplyDeleteWe are currently experiencing a problem where the pop-up appears to login when connecting from externally, but it does not authenticate.
It keeps popping up.
Could it be the firewall (apache) that does not allow NTLM schema to authenticate?
Thank you
Hello Eugene,
DeleteThe fact that you are getting a credentials challenge is a good sign. I doubt your request is getting blocked by the firewall, otherwise you may have been presented with an error page.
If you are only experiencing this behavior while attempting to access externally, I would take a closer look at a couple of things. First make sure you are accessing SharePoint using the correct fully qualified public URL. This solely depends on how your Alternate Access Mappings and external DNS are currently set up (i.e., http://sharepoint vs. https://sharepoint.com).
Second, ensure that your browser security settings are set up correctly. Navigate to Internet Options and check if your site is in the Trusted Sites zone. If so, remove it from there and try placing it inside the Local Intranet zone.
Hope that shines some light on the issue.
Cheers.
Can I just say that I have been struggling with this issue for almost a year to no avail.
ReplyDeleteThis solution you've provided has finally fixed it!!!
Thank you so much. My users can now access XML files using excel whilst out of the office.
I love you.
Hello Haydn. Glad you found this useful. :)
DeleteThanks for the feedback!
Ćao,
ReplyDeleteKako omogućiti pristup preko Internet Explorera SharePoint serveru interno?
Preko mozille mogu otvoriti Sharepoint Central Administration, a preko IE ne mogu... ali na IE mogu otvoriti sites...
Sve je lokalna mreža... hvala unaprijed
Cao Rebel,
DeleteTaj problem se veoma cesto desava u ovim okolnostima. Ima nekoliko poteza koji se mogu preuzeti u ovom slucaju:
1. Prvo provjeri interni DNS. Dali postoji A-Record za Central Administration site? Ovo predlazem ako je namjera da se Central Administration otvara preko client kompjutera. Ako se otvara samo preko servera, nije potrebno.
2. Pokusaj dodati URL od Central Administration u "Local Intranet" zonu za IE.
3. Disable Loopback Check na svakom SharePoint serveru. To se moze omoguciti preko PowerShell: New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name DisableLoopbackCheck -Value 1 -PropertyType DWORD
Ako ni jedan od ovih ne pomogne, moj savjet je da se pogleda ULS i Event Log u toku vremenskog perioda kad pokusavas da otvoris CA preko IE.
Sretno!
Hvala puno ! Provjerit ću
Delete