Public-facing on-premises SharePoint with NTLM authentication

Question

I've been searching for authentication best practices for public-facing SharePoint site but I didn't find any useful resources on the issue that is troubling me.

Assume I set up a web application with Classic NTLM authentication. On that web application I enable Anonymous access. This means that users inside organization's network will be able to authenticate (actually use SSO) using organization's DC. They will be able to access and administer all content. All other anonymous users will be able to see published content only i.e. content which is permitted to anonymous users.

My question is: Is this kind of setup a security issue because if a potential attacker hacks a WFE then he has direct access to DC?

Is FBA maybe a better solution for public-facing sites? Or maybe use NTLM, but create a separate domain with one-way trust to organization's domain?

Answer 1

There are many variations you can take with this - and really you need to consider more than just your content. For true separation:

I would have a dedicated DC to manage service accounts.

I would break up my DMZ behind firewall contexts with a reverse proxy publishing SharePoint at the edge.

proxy/firewall -- SP Server -- Firewall -- SQL/DC

For true separation you don't want to share any underlying infrastructure with internal either, although in reality logical separation is usually enough.

Now you have to deal with internal user authentication and how to handle that. The first thing is I would have at minimum two webs available, your primary for editing and the extended version for public access.

While a one way trust would work - you still do expose user info out to the public which you may not want. With this configuration you could configure people picker to only select from a particular OU to minimize this.

Another option however is to look at using ADFS between your domains and create the trust there. You would have to configure the farm for claims auth to make this work, but this would eliminate the possibility of probing all the users in AD or the OU you expose.

With the ADFS method when you update documents you user name is still tagged to content - however if you don't populate the user profiles this will be the only information available about any internal user.

You may even want to go a step further and when you extend the public site, use forms authentication but don't provide any users. Then there is no authenticated access from the public URL. And with ADFS/Reverse Proxy may you even be able to configure some pre authentication for your internal users before they can even reach the internal SharePoint pages.

I would strongly consider moving to SharePoint 2013 and looking at the cross site publishing (2010 and below have the content publishing - but stay away from that, when it works it's great, but when it doesn't it's a PITA to get back in sync). with cross site publishing you have an editing site and the publishing site pulls from the Search index and the permissions are completely separate.