Configuring an Extranet with SharePoint Foundation 2013
As a thought experiment, I wondered how one would go about setting up an Extranet environment in a highly secure fashion. To make it even harder, I wanted to see whether a SharePoint Foundation 2013 environment would be able to be set up in a secure way, that would allow an organisation to publish internal content to an external site without having to expose their Intranet. As a further restraint, I wanted to see how making a close to totally isolated environment that would mimic a real world one would behave.
The first thing I did, of course, was to Google for a solution. Either my google-foo was bad, or there simply is no decent, well documented examples of how to configure such a topology. Bear in mind here, that I am not after some simple "press button x" explanation. I was after a full description along with any security gotchas, configuration gotchas, variations, and how to trouble shoot these.
ASIDE: SharePoint seems to be one of those systems that defies any sort of coherent and dedicated system documentation from the vendor. Whenever you are looking for solutions to a problem (usually from looking at your ULS logs), the only answers one seems to find are in un-official blog posts, and never, ever ever from an official Technet document. To me, this is one of the reasons that SharePoint is "hard", in that it defies any sort of systems documentation or resolution docs.
So, for my experiment, I wanted to be able to achieve the following:
- Have an isolated DMZ environment that had it's own domain - A one-way trust between the DMZ AD forest and the Corporate/internal AD forest (i.e. DMZ forest trusts the Corporate forest, but not the other way around) - SQL server is not domain joined (there are valid reasons for this, but I appreciated that this is an edge case)
I will not go into the step-by-step instructions on how to set this sort of environment up. I am going to assume that you know enough about networks, VM's, SQL server installs, server installs etc. to be able to do those.
How I thought it Would Work
- Install SharePoint foundation using SQL Authentication
- Allow Corporate/Internal accounts access to the DMZ SharePoint site, since we have a 1-way trust
- I *thought* that since there is a trust, that simply querying the DMZ AD server would delegate the request back to the corporate/internal domain on the initial requests behalf, and that SharePoint would be smart enough to do this. (I can hear your laughter from here - I know, my naiveté is refreshing)
What Actually Ensued
It turns out that the People Picker in SharePoint 2013 requires (at a minimum) ports 389 to the corporate/internal domain controller. To me this just seemed crazy, since it is another potential attack route that could be used, and lessens security of the DMZ. (NOTE: Even finding that this is the case was an exercise in and of itself - seems that this is NOT documented ANYWHERE officially that I can find)
So, to make all this work, you have to either adopt the topology shown below, create AD groups in the DMZ domain that contain the people from the trusted domain and then assign those to the SharePoint environment, or abandon the idea totally. From a security perspective, I would put these in the following order:
- Create AD groups in the DMZ domain that contain the people from the trusted domain and then assign those to the SharePoint environment
- Abandon the idea totally.
If you decide on the third option (i.e. open the ports), note that you will need to run the following command on one Front End server:
STSADM -o setproperty -url [Extranet URL] -pn peoplepicker-searchadforests -pv "domain:[domain where Extranet is installed];domain:[internal/corporate domain name],[corporate domain\user],[password]"
There are plenty of better explanations for this, so I will leave that as an exercise for the reader to
TODO: Put Diagram Here
Perimeter (DMZ) network with the following:
- Windows Server 2012 R2 server joined to DMZ domain + SharePoint 2013 Foundation installed and configured (SPF 2013 Install) SQL Server (2008 R2) non-domain joined with SP1 minimum and MAXDOP set to 1
- 1 way trust between DMZ domain and Corporate domain (i.e. DMZ trusts Corporate domain, but corporate does NOT trust DMZ domain)
- Firewalls block all traffic except as follows
- DMZ AD Server to Corporate AD Server
- Standard AD Trust ports
- TCP/UDP 135, 137, 138, 139 (RPC)
- TCP/UDP 389 by default, customizable (LDAP)
- TCP 636 by default, customizable (LDAP SSL)
- TCP 3268 (LDAP GC)
- TCP 3269 (LDAP GC SSL)
- TCP/UDP 53 (DNS)
- TCP/UDP 88 (Kerberos)
- TCP/UDP 445 (Directory Services)
- TCP/UDP 749 (Kerberos-Adm)
- TCP port 750 (Kerberos-IV)
- DMZ AD Server to Corporate AD Server
Some Other Gotchas
SQL Log On errors
- You will keep getting event ID 5586 in the Event Log (as well as a corresponding error in the SQL ,logs)
Unknown SQL Exception 18452 occurred. Additional error information from SQL Server is included below.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
- I have yet to find a solution for this