none
Allowing https to internal farm via an exernal domain

    Question

  • I am trying to accommodate a client’s requirements for a new SharePoint 2013 intranet I am building as they want  external https access through a different (domain) URL  .  

    Internally,  users and servers reside on a local domain: client-domain.local

    • intranet.client-domain.local
    • mysites.client-domain.local
    • projects.client-domain.local
    • apps.client-domain.local

    I am leaning towards a single web app and provisioning HNC as I think this will simplify the overall architecture.   Now my issue: If my client say has a hosted domain:   client-external-domain.co.uk on a Name Server of say an external web site host which could be on Linux or windows.  They want to use client-external-domain.co.uk as the mechanism for secure access to the above SharePoint Intranet e.g. https://intranet.client-external-domain.co.uk.  I am struggling to see how I can do this, unless I can add a cert to the IIS running on my farm that maps to client-external-domain.co.uk and have the appropriate Alternate Access Mapping set in SharePoint.  A hosted Name Server , would simply route all the relevant client-external-domain IP  traffic to the client's firewall and on to the farm

      

    Any thoughts other than Reverse Proxies as apparently I am not getting one of those anytime soon ;-(

    Daniel   


    • Edited by DanTheManXX Tuesday, April 01, 2014 4:58 PM
    Tuesday, April 01, 2014 4:53 PM

Answers

  • That is correct. Using internal DNS servers (e.g. Active Directory DCs) create a new DNS Zone named client-external-domain.co.uk. Create A records appropriately for internal assets pointing to internal IP addresses, and duplicate records used for external assets (let's say the client has a website of www.client-external-domain.co.uk hosted by a hosting provider, they would create an A record of "www" pointing to that external IP address).

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by DanTheManXX Wednesday, April 02, 2014 8:22 AM
    Tuesday, April 01, 2014 5:55 PM

All replies

  • This is fairly simple. Get an SSL cert (wildcard or SAN, SAN is typically more expensive) that covers the domain in question. Add it to the SharePoint server(s).

    Next, host the DNS namespace internally and create A records that point to internal IP addresses. Externally hosted DNS is business "as usual". This is often called split DNS, split-brain DNS, and there are a few other names for it -- fairly common.


    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, April 01, 2014 5:16 PM
  • Trevor

    Thanks as this is reassuring.  Just to clarify:  "host DNS internally" you are referring to the client-external-domain.co.uk .

    Thanks again.

    Daniel

    Tuesday, April 01, 2014 5:53 PM
  • That is correct. Using internal DNS servers (e.g. Active Directory DCs) create a new DNS Zone named client-external-domain.co.uk. Create A records appropriately for internal assets pointing to internal IP addresses, and duplicate records used for external assets (let's say the client has a website of www.client-external-domain.co.uk hosted by a hosting provider, they would create an A record of "www" pointing to that external IP address).

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by DanTheManXX Wednesday, April 02, 2014 8:22 AM
    Tuesday, April 01, 2014 5:55 PM
  • Trevor

    Thanks for these details. I am briefing the IT team on the required network changes  this morning will give an update on here.

    Wednesday, April 02, 2014 8:23 AM
  • Trevor 

    Had some feedback,

    Current architecture   though could go down the single web app many HNCs route

      • intranet.client-domain.local (root)
      • mysites.client-domain.local  (host header)
      • projects.client-domain.local (HNC)

    On the internal side, I ( we) understand what is required.  The issue is resolving the external addresses for the urls shown above. I guess there will need be one or more A records on the Hosted NS.  I think the team are concerned about how many of these records will be created and if the firewall strips out stuff such as the host header.

    Note, I believe we are "hijacking" a existing site so  www.external-domain.com will still resolve outside SharePoint .

    Wednesday, April 02, 2014 3:20 PM
  • Why is MySites on its own Web App (assuming that is what you mean by 'host header')? I'd just combine it into the HNSC Web App.

    Yes, you'll need to essentially duplicate A records for assets -- one internal, one external. The firewall cannot strip out host headers, otherwise IIS/SharePoint wouldn't know what the inbound client is asking for.


    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, April 02, 2014 3:33 PM
  • Hmmmmm I have been wondering that myself!  In terms of local and externally duplicated DNS entries, it is really a slightly different URL path. I don't think making the MYSites and HNC changes the number I define. Reducing the number of Web Apps certainly is the recommendation on TechNet.

    I can keep my root site and root site collection as is,  just create Mysites with the same web app and loose the Host Header. 

    Thanks again. Daniel

    Wednesday, April 02, 2014 8:18 PM
  • Trevor

    I appreciate that replying to this thread may border on the tedious ;-) but this is generating a lot of discussion at my end and I have to present my recommendations to head of service tomorrow.

    The questions I will be asked.

    1. Why can't we expose a single IP Address:  intranet.external-domain.co.uk  and everything will be found on managed paths so /projects and even /mysites  ( yep that was suggested to be on the main web app.)
    2. A record of type www.external-domain.co.uk is already in use for non-sharepoint to only the individual subdomain a records for each of my intranet, my, or project urls

    Decided to knock up a quick diagram to illustrate a split dns which hopefully shows what you described earlier


    • Edited by DanTheManXX Sunday, April 06, 2014 10:04 PM
    Sunday, April 06, 2014 10:03 PM
  • There is no reason you can't do #1. You would use a path-based site instead of HNSC, in this case.

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, April 06, 2014 10:05 PM
  • Man that was a speed of light reply! Yes so one external IP address for everything  and managed paths as you say.  I have to admit I did have the same thought as the end of the day all we are talking about is site collections. 

    Oh well that would scupper the idea of getting them to think the Office 365 way so HNSCs..
    • Edited by DanTheManXX Sunday, April 06, 2014 10:11 PM
    Sunday, April 06, 2014 10:09 PM
  • As long as they're all under the same domain (that is, external-domain.uk.co), you can use the same IP address/SSL certificate. It'll work, I've done it on a quite a few farms and treat this as SOP. If I introduce another domain to the farm, I add an IP address.

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, April 06, 2014 10:11 PM
  • Ok  I am happy to go with this (SOP) in my presentation tomorrow and get sign off . Thanks for a really useful discussion . Daniel.

    Sunday, April 06, 2014 10:36 PM
  • Trevor

    I have been asked for some pros and cons for the "SOP" Architecture.  Here is my starter

    Pro

    • Reduces number of web applications which is recommended my Microsoft
    • Allows Alternate Access Mapping as well as multiple host headers against the same web application  

    Con

    • site collections do not have their unique URL since all are managed paths that reside under the main web application
    •  Cannot use Alternate Access Mapping since all in the same default zone
    Monday, April 07, 2014 10:00 AM
  • I do not see being unable to use multiple AAMs as a con. From a user perspective, it is much more simple to have a single AAM for all forms of access.

    By using a single Web Application, you also lose granularity for User Policies and other Web Application-specific settings (e.g. disabling the use of SharePoint Designer, for example if you wanted to do that with MySites vs. other Site Collections). Of course, regardless if you use HNSC or Path-based within a single Web App, these issues apply. You'd have to break out into multiple Web Applications, which you can do, but you should avoid it if at all possible.  


    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, April 07, 2014 3:52 PM
  • Trevor

    I agree. Most of this limitations can be enforced through governance.  I did the have meeting and presented the "SOP" architecture via a revamped VISIO diagram. Since the IT team suggested this,  and I have stated that this is what I will implement in live, they are now falling over themselves to assist me:  certificates ordered, Web App Servers and more , starting  appearing appearing at breakneck speed. Go figure!

    Thanks for your help.

    Daniel


    Monday, April 07, 2014 4:14 PM