SharePoint External Architecture & Implementation - Part 5

Previous Post :- Part 4
One of the major problem for a DMZ environment is that it’s a strictly controlled network enclave. In most of the scenarios you can’t access internet. Your organization might provide proxy as an interface to internet, however it could be a cumbersome process especially if it requires registration of each URL to be accessed.
Why am I talking about access to internet? As it turns out that SharePoint uses its own self created certificate for communication between many of its services. Also if you are using external domain certificates, these certificates will  contact CRLs (certificate revocation list) for certificate validation. Most probably these CRLs are on internet.
Whenever these certificates are invoked, that would be every time somebody connects, authenticates or services need them, these certificates would go online for validation. SharePoint would try to connect to internet to contact CRLs. If a CRL is not accessible, SharePoint would continue to try to access them. This would result in a degraded performance for end users. In fact it could be unacceptable performance. Fortunately there is a setting available in windows that could be used to work around this issue.
Open “Local Security Policy” on all SharePoint servers – type secpol.msc in run prompt.

Select “Public Key Policies” from left tree menu and open “Certificate Path Validation Settings” from right pane.

Select “Network Retrieval” tab. Check “Define these policy settings” checkbox if its not checked.
Removed check from “Automatically update certificates in the Microsoft Root Certificate Program (recommended)”.
Set 1 second for both “Default URL retrieval timeout” and “Default path validation cumulative retrieval timeout”.
Above setting would cause CRL validation event to timeout in 1 second hence saving a lot of time and performance.

SharePoint External Architecture & Implementation - Part 4

Previous Blog : SharePoint External Architecture & Implementation - Part 3
In previous blogs I talked about architecture and authentication for an external facing SharePoint environment. However in an enterprise setup, access control would be required to ensure that data is delivered only on need to know basis. Primary issue for an external facing environment is, that it may not have an active directory based user and group store to pick those users and groups for permission assignment. White SharePoint works seamlessly with an active directory, in absence of it a customized solution is required to attach a user and group store for assigning permissions. Because SharePoint uses claims for its internal working, any custom authorization process must provide user and group credentials through claims, hence the name custom claim provider.
Fire command get-spclaimprovider on SharePoint server and you will see a few inbuilt claim providers.
a custom claim provider is a .wsp solution for SharePoint, to be created in Visual Studio. SharePoint provides a few methods, which need to be implemented to attach a custom user and group store. It could be any database such as a SQL Server, file, SharePoint list etc…
Besides providing claims to SharePoint for assigning permissions, custom claim provider can also augment incoming user claims. What it means that you can provide or learn more information about a user is accessing the environment.
There are numerous resources available online to explain how to build a custom claims provider. Some useful that I found are given below.
http://www.codeproject.com/Articles/506023/Understanding-SharePoint-Custom-Claims-Provider
http://blog.podrezo.com/sharepoint-custom-claims-provider/
http://www.titus.com/blog/2012/03/building-a-custom-claim-provider-to-manage-security-clearances/
for Microsoft BI environment, here’s a very useful document.
http://social.technet.microsoft.com/wiki/contents/articles/15274.using-claims-authentication-across-the-microsoft-bi-stack.aspx
Note:- Custom Claim Provider creates issue with SSRS subscriptions if you are planning to use it for BI. I worked with Microsoft to find a solution to this, but even they are unable to pin point the reasons of this problem. For BI environment, you can come up with an alternate approach of creating sharepoing groups through a .wsp solution.

SharePoint External Architecture & Implementation - Part 2

SharePoint External Architecture & Implementation - Part 1

In part 1 I talked about architecture for a SharePoint external environment. Lets see how to implement such an environment.

Network/Data Flow

It is important to understand network flow for a SharePoint environment to be able to implement it without hitches.

A nicely compiled list of required network ports.: Click Here

source: http://blogs.msdn.com/b/uksharepoint/archive/2013/01/21/sharepoint-2013-ports-proxies-and-protocols-an-overview-of-farm-communications.aspx

All the mentioned ports are default as used by applications. Change them as per your organizational requirements. If you don't have more than 10,000 users; don't bother setting up separate Distributed Cache servers. You can run Distributed Cache on your WFEs.

If you have decided to host all Farm servers in single network subnet then it shouldn't be much of a problem to allow ports except for non-Farm servers such as SMTP host, external content servers etc...

In case you are hosting WFE and application servers in separate network segments, you will have to make sure all required network ports are open among them.

Some organizations take network security very seriously. They like to keep their DMZ alienated from other corporate networks. I came across a similar situation where WFEs were in DMZ but application servers were to be hosted in HTZ so that app servers can connect to data warehouse in GNZ. Most importantly, a blanket connectivity on specific ports between DMZ and HTZ was not allowed. The only way to connect WFE with application servers was to configure communication through a web service security appliance. This poses unique challenges because SharePoint farm servers communicate directly on specified ports. All internal communication happens using NetBIOS names.

In order to configure Web Service Security Appliance, we must know exact web service endpoints that initiate connection from WFE to App servers. Each of the SharePoint service application have its own set of web services. All these web services are SOAP, but Microsoft uses custom SOAP format. In order to find out exact web service end points for the service application, check application server IIS Manager on server where that service is installed.

Lets take an example of SSRS (SharePoint integrated mode).

Open IIS Manager on SSRS application server. Under "SharePoint Web Services" expand web application for SSRS. In case there are multiple web applications, best way to identify correct web application is to check its application pool. It is a good practice to keep separate service accounts for different services. The application pool configured with SSRS service account is correct app pool; and the web application using that app pool is the web app used for SSRS. Click on web app and check Content View.

These WCF Web services ending with .svc. You will have to configure following web services for SSRS.

1. AlertingWebService.svc
2. ReportExecution.svc
3. ReportingWebService.svc
4. ReportServiceBackgroundProcessing.svc
5. ReportStreaming.svc

Because all network communication from WFE to App servers should pass through Web Service Security Appliance, hosts file on WFE should reflect changes for IP - App Server name. Make following changes in hosts file on WFE.

<web service security appliance IP>      <App server NetBIOS name>

If your web service security appliance requires app server name to forward traffic, always use app server NetBIOS name; NO FQDN. In case your web service security appliance validates soap service, its going to stop all traffic as SharePoint web services don't follow standard soap format. Best way to avoid this problem is to configure web service security appliance with REST.

SharePoint External Architecture & Implementation - Part 1

Designing and Implementing an external architecture for SharePoint farm could be a challenging job especially if not done right. In this series I'll talk about implementing a SharePoint external Farm, with BI stack in mind; i.e. a complete Microsoft BI Stack for external presence.

Below are the ingredients of a typical Microsoft BI Stack.

1. SharePoint as front end
2. SQL Server Analysis Services Server for Cube DB
3. Corporate Data warehouse/data marts for application data

Critical considerations should be given to placement of these services within organizational network. Not all segments of this stack should be hosted externally in DMZ for security’s sake. Careful approach should be taken to expose only enough components which requires external presence.

Let’s understand the process step-wise. Most of the organizations have clearly defined network segments for internal as well external presence. At times organizations have special security zones for sensitive data. In case there is no special zone for sensitive data, it merges with GNZ.

Because SharePoint is going to be the front-end it ends up in DMZ. SharePoint gives us a flexibility to host difference component services on separate servers. Let’s see two scenarios for SharePoint external presence to understand their usage.

1. SharePoint as a standalone content management system 
2. SharePoint as front-end of a data driven stack (example: Business Intelligence Application)

SharePoint as a standalone content management system

This is a bare bones scenario where SharePoint is used with its basic functionality to host static content. The SharePoint content has no dependency on any corporate database. This is simple design, and the entire SharePoint farm can reside inside the DMZ, downside being, that it cannot host any sensitive data as it is prone to any malicious attack from internet.

SharePoint as front-end for a data driven stack (example: Business Intelligence Application)

This is where the complexity starts because SharePoint feeds on data hosted in the corporate network. A good and policy driven network architecture would not allow direct connectivity between DMZ and GNZ. To overcome this kind of problem, network architects usually build HTZ. They provide a staging area which sits between DMZ and GNZ. HTZ contains strong firewalling to deflect any external attack. Below picture explains how a Microsoft BI Stack would look like in an external presence.

The architecture looks simple but its very complex to implement. In next post we will see how to implement this architecture.

Next: Click Here