This topic came when there were policies in some organizations that require SharePoint to comply with the “three-tier architecture” requirement, meaning WFE, APP and DB should be in three network zones, and WFEs CANNOT connect to the DBs directly! It is common to see SharePoint farms servers placed in three zones, but most of the time WFEs are allowed to connect to the DB Server. However, this is not acceptable to the organizations that has the “three-tier” policy in place.
I saw in some projects a proxy server is implemented in the APP zone to bridge WFE and DB. It works. However, that proxy can easily become a bottleneck in larger implementations. So far the most common way of implementation is to place one or multiple reverse proxies in the Web zone as the web layer, shifting the SharePoint WFEs to the App zone together with the App servers.
{update April 2018} What I propose in this post is an alternative using technologies on SharePoint. However, based on practical experiences, this approach is more theoretical than practical. So far, there is no production implementation yet. {/update April 2018}
This alternative approach leverages the Request Management of SharePoint. With that you may say SharePoint actually supports the 3-tier requirement. How Request Manager works is elaborated on TechNet. The design here is to:
- Put the WFEs in the APP Zone so they can connect to the databases directly.
- Put a dedicated request management farm in the Web Zone in between the Load Balancer and the WFEs, with databases in the same zone.
This way, the Request Management layer serves as the web layer interacting with user requests. The WFEs in the APP Zone become the content serving components that retrieve data from the databases at the back end, while they are in the secure internal APP network zone.
Q: is it OK to place a database server of the Request Management farm in the web zone?
A: Yes, there is no user data stored in the database, only farm service configuration data. And the firewall rules should be restricting network traffic to the DB server to come only from the Request Management Farm servers.
Q: When the actual WFEs in the APP zone servers content back to the users, do they transfer it directly to the users?
A: No, it responds back to the users through the Request Management farm. This is actually the key part that makes the architecture above possible as users are not able to reach the App Zone.
Q: Should Office Web Apps Server be placed in the Web Zone or the same zone as the actual WFEs?
A: It must be reachable by the end users directly, so it should be more suitable to be in the Web Zone.
PS: The diagram below shows a bad design example that uses a proxy:
Blogging Tom 
That’s not true and just theory Tom. I know what you aim to build but Request Management is not designed to replace front-end processing engine which SharePoint Foundation Web Application Service (SPFWAS) actually does. Request Management handle routing in case you’d like to handle large internal incoming request (which is passed from SPFWAS to). It does not guarantee 3-tier from physical architecture point of view. Moreover, if you really experience with Request Management, you will soon realize number of different conflicts and limitations (eg. load balancing, custom web handler…) which can only be solved by stopping this service.
By the way I do know where you are from, and where the 3-tier requirement comes from as well (e.g. Government policy). This policy is kind of heck for sure but this is still beneficial to cybersecurity today. I used to be a SharePoint enterprise architect working with over 20 government agencies for full SharePoint design and implementation within 4 years. I also worked with Microsoft consulting service to come out the government architecture pattern for SharePoint. I also worked with AvePoint for a few SharePoint opportunities (around Storage Manager).
LikeLiked by 1 person
Hi, you’ve hidden your identity well so I am not sure if you can see this reply. 🙂 You are correct that Request Management layer cannot replace the SPFWAS. We always need the WFEs even if there is the Request Management layer. You are also correct in that the scenario discussed in the post is more theoretical than practical. All of my customers who had the physical three-tier architecture concern ended up using reverse proxies in the Web layer with WFEs hidden in the App network zone to comply with the policy.
What I would like to learn from you is about Request Manager routing internal incoming request passed from the SPFWAS and that it does not guarantee physical 3-tier. Please correct me if I have misunderstood it. It sounds like the incoming requests may hit the WFEs first before being passed to the Request Manager for processing. This sounds different from how I understand Request Manager which is the first layer that receives the incoming requests from a Network Load Balancer, and routes them to the WFEs which host the SPFWAS.
I would really appreciate it if you could share things that I have missed.
LikeLike
Hi Tom,
The problem is that the government policy requires 3-tier from physical perspective. While Request Manager is indeed run within SPFWAS under SPRequestModule. From logical perspective, you’d safely say 3-tier would be achievable with RM because requests are handled two times (RM and SPFWAS) before hitting to the destination (whether database or another service application instance).
If you already have an LB (I’m sure almost F5 is mentioned in government), 3-tier doesn’t have to be proved because the LB is part of the team (in case LB has WAF module).
In the case there is not any web proxy supported (in LB for example), normally people choose to implement a reverse proxy (and you mostly see IIS Rewrite URL module deployed in a dedicated Windows Server running IIS). I don’t advocate for this solution but this is completely a 3-tier for sure.
Incoming request > Web RP (1) > SharePoint Front-End machine (where SPFWAS is started) (2)> wherever (3).
Another thing is that RM in practice is not something people are interested. There are only few camedemic articles in the Internet to guide you how to control request routing. The problem is that you have no feasible way to verify if RM works completely in every case. That’s why the safest way is to turn it off.
Achieving 3-tier in SharePoint is always a unexpected and uncomfortable debate in the government project. Sometimes you win case and sometimes you MUST follow the rule without any technical explanation :).
Btw I used to work in Singapore but left and moved to the State. I’d NOT like to expose my identity since then (for no reason :))
LikeLiked by 1 person
haha, cool! Yes, a debate is inevitable in each project with that policy, which is fine. We just work with the customer and find the best solution for their case. In the cases where they have to stay with the policy, so far the end result of the debates is to use either reverse proxies or the LB as the first layer just as you have mentioned. Thanks for sharing!
I intend not to confuse my readers, so I have updated the post indicating the approach is not too much more than a theory. 🙂
LikeLike
3-tier architecture in SharePoint is an amazing journey of mine during time working with government. Not only working with direct government agencies, I engaged to work with G-Cloud architect team and had countless discussions around 3-tier :). To me, such a principle is bullsh*t and is not considered a security countermeasure today. I left Singapore last year so I’m unsure if today this 3-tier principle is still required. And don’t know which kind of reverse proxy replacing a horrible IIS Rewrite module which is designed for obsolete ASP.NET version. Perhaps I’d prefer Web Application Proxy (in Windows Server)
I did PoC cases on RM and showed how cool it was to folks in government but then I came to realize it was dangerous to have RM in a production environment. You would use it for a specific case, such as implementing a pure document management system on top of SharePoint. However, for long-term investment, in the future the platform would be utilized for another application (workflow, intranet portal..) which RM would break your SharePoint. Otherwise you’d invest to a dedicated team of 2-3 people working to customize your Http Request routing to work with RM for every new deployment. Who’d pay?
LikeLiked by 1 person
Right, it might be possible if the environment is huge enough, let’s say a farm with 20+ servers servicing tens of thousands of users. It might make sense to invest in a Request Management layer as well as a dedicated team maintaining it. You have chances of running into that type of customers in the US I guess. In Singapore, that does not exist, hahaha
LikeLike