Skip to main content

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.

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
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

NOTE: Keep in mind that this changes precedence of how the incoming requests will authenticate (NTLM first).

Comments

  1. UnknownJanuary 5, 2016 at 6:59 AM

    Good day,

    We 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

    ReplyDelete
    Replies
    1. Ismar AlikadicJanuary 11, 2016 at 9:15 AM

      Hello Eugene,

      The 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.

      Delete
  2. FlyMay 25, 2016 at 6:22 AM

    Can I just say that I have been struggling with this issue for almost a year to no avail.

    This 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.

    ReplyDelete
    Replies
    1. Ismar AlikadicMay 26, 2016 at 2:04 AM

      Hello Haydn. Glad you found this useful. :)
      Thanks for the feedback!

      Delete
  3. UnknownJune 3, 2016 at 4:17 AM

    Ćao,

    Kako 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

    ReplyDelete
    Replies
    1. Ismar AlikadicJune 3, 2016 at 12:45 PM

      Cao Rebel,

      Taj 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!

      Delete
    2. UnknownJune 6, 2016 at 9:37 AM

      Hvala puno ! Provjerit ću

      Delete

Post a Comment

Popular posts from this blog

SharePoint Server Search - Error Starting

Problem I recently ran into this snag at a client site while setting up the Search Service Application.  I was able to create the service application without a problem however when I attempted to start the SharePoint Server Search service (Manage services on server page) I kept getting Error Starting . After taking a peak at the logs I found the following: An attempt to start/stop instance of service SharePoint Server Search on server did not succeed. Re-run the action via UI or command line on the specified server. Additional information is below. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) I double/triple checked the permissions and made sure that my Farm Administrator account was a member of WSS_WPG and WSS_ADMIN_WPG groups, and that those groups had full control permissions to the C:\Windows\Tasks and C:\Windows\Temp folders. Resolution I nearly lost hope when I remembered my old lost friend called STSADM.EXE. Just like in the old da...
Post a Comment
Read more

SharePoint 2013 - Creating and Applying Composed Looks (PowerShell)

If you are a SharePoint administrator looking to quickly apply some basic branding to a site-collection in your SharePoint 2013 environment then you've come to the right spot. Before we begin I assume you have a basic understanding of what Composed Looks are, and perhaps you spent some time playing around with this concept in SharePoint 2013. If not, then don't worry.  Here is a basic primer: Composed Look is basically a package which contains elements used for controlling the overall look and feel of a SharePoint site.  This includes but not limited to Colors, Fonts, Background Image, CSS files, and Master Page files. Once created, Composed Look can be packaged by using the Design Manager feature, or we can use PowerShell to apply it across one or multiple site collections. NOTE: In this post we will be focusing on creating a composed look from an .spcolor file then using PowerShell to apply the design to a site-site collection of our choice.  We wil...
2 comments
Read more