How to Deploy Microsoft Dynamics CRM and SharePoint in Security Zones

Begin by considering what the customer wants to achieve from the perspective of security/risk versus cost/complexity. Fewer zones means fewer firewalls, less configuration, lower costs, and so on, while not necessarily leading to a lower level of security,
primarily on the lower layers (OS, and so on).

Analyze the “zones” defined by network segments between two firewalls – or those that are directly connected to a leg of a three-way firewall. A zone with Internet- or extranet-facing servers is often referred to a de-militarized zone, or DMZ. Note that if there
are no components in between two firewalls, there normally is no zone serving as an efficient additional layer of defense; two firewalls connected directly do not create a zone that provides a good defense-in-depth strategy. In this case, each zone only complements the missing features of the associated zone, such that one may be a reverse-proxy while the other performs address/port filtering.

In these types of scenarios, consider if the layout of zones and use of firewalls provides optional security and manageability; a high number of firewalls itself will not necessarily improve security but certainly add complexity.

Unless there are very special reasons to maintain four separate DMZs, create additional barriers rather than building
parallel zones:

1. First, consider combining Microsoft Dynamics CRM with applications such as SharePoint at each zone/layer. These types of applications normally do not disturb or threaten each other, instead conforming to same layered architecture.
2. Next, consider combining extranet zone (authenticated?) and internet zone (anonymous?). If this is feasible and recommended will depend on CRM instances and their sensitivity; if gross data sets are identical you anyway rely on the CRM application to
   secure differentiated access, while separate instances can be separated into zones for also network-level security.

The architectures listed in product documentation (for example in the MSDN topic Middle Tier Architecture) defines almost all Microsoft Dynamics CRM servers together in Zone 2, but is less clear on Zone 1 – if Zone 1 is “bypassed,” Zone 1 is not a zone. In general, front-end servers should always be a zone nearer to the user than are the application servers. For a more general and appropriate zone recommendation, see the MSDN topic Network Segmentation.

For the best division of zones, put as few components as possible in Zones 1 and 2:

• The best solution is to publish Microsoft Dynamics CRM (and SharePoint) through an application-aware reverse-proxy, such as Microsoft Unified Access Gateway (UAG) or Threat Management Gateway (TMG).
• A good alternative is to place Microsoft Dynamics CRM (and SharePoint) front-end servers in Zone 2 with the operating system and Application layers as hardened as possible, because more protocols with fewer control enter Zone 2.

For Zone 2/3 or 3/4 (other whatever numbering is used for last two), many enterprises just use a single “trusted LAN”. Applications such as Microsoft Dynamics CRM require access from front-end to the database, so regardless of the numbering scheme, you will need a direct
access to SQL on port 1433.

A summary of this information is presented in the following table.

Bernt Bisgaard Caspersen

Dynamics Solutions Architect  |  Microsoft Center of Excellence