Using IPsec to Secure an Internet-based Child Primary Site in SCCM
At first glance, dedicating a whole primary site to running Internet-based client management can seem very attractive when you're deciding on site and server placement in your Configuration Manager hierarchy. Then one look at the Network Diagram for Internet-Based Servers - Scenario 2 with Child Site and you realize that this means two-way SMB traffic, which is not going to fly with your firewall admins or your security folks (and quite rightly so!). However, think again because this configuration might work well with a simple IPsec policy between the site server in the perimeter network, and the site server in the parent site (often the central site). Because you have to run native mode in both sites, both sites are already using PKI. You can take advantage of this and deploy additional certificates on the site servers to support IPsec, and then create IPsec policies that use certificate authentication.
In this scenario, create an IPsec policy for both site servers that requires security, use a PKI certificate, allows any IP protocols for all network connections from "My IP address" to "A specific IP address" (the IP address of the other site server), ensure that the default response rule is not activated, and that the filter is mirrored. The firewall needs UDP port 500 to be open and protocol number 50 (for ESP). If NAT is being used, UDP port 4500 also has to be open on the firewall.
There are a couple of advantages to using this configuration. The first is that you don't have to worry about sending SMB and RPC through the firewall from the site server to the Internet-based site systems for installation and copying packages. You can secure these troublesome ports by using IPsec policies on each of the Internet-based site systems and the site server (and use RPCcfg.exe to narrow the dynamic port range for the second RPC connections), but this can end up being a lot of admin overhead - especially when your Internet-based site systems are distributed over multiple computers.
The second advantage is that you can delay and control when information is passed from the child site to the parent, using the sender address properties. This gives you a window in which to pull the plug if any of the servers in the perimeter network were compromised.
The disadvantage of this approach is that the site server is in the perimeter network (DMZ) and therefore potentially vulnerable to attack. This could result in a denial of service or information disclosure. However, if you can isolate the site before it sends information to the parent site, any damage will be limited to the child site only, and potentially the clients that are assigned to that site - rather than potentially affecting the whole hierarchy (all sites and all clients). Note that this design requires that the Internet-based site does not have a primary site beneath it.
As with many designs that concern security, there are a number of pros and cons to consider. If you're interested in this design, here's a step-by-step to create this IPsec policy on a member server running Windows Server 2003. The steps are very similar for Windows Server 2008 and they can also be easily modified so that the IPsec policy is assigned through Active Directory Group Policy.
To Create a Local IPsec policy for Each of the Site Servers (Windows Server 2003)
Click Start, click Administrator Tools, click Local Security Policy, right-click IP Security Policies on Local Computer, and then click Create IP Security Policy.
In the IP Security Policy Wizard, and in the Welcome page, click Next.
In the IP Security Policy Name page, specify a name for the policy, such as "ConfigMgr Site-to-Site", and then click Next.
In the Requests for Secure Communication page, deselect Activate the default response rule if this is selected, and then click Next.
In the Completing the IP Security Policy Wizard page, ensure that Edit properties is selected, and then click Finish.
In the policy properties dialog box, in the Rules tab, click Add.
In the Welcome to the Create IP Security Rule Wizard page, click Next.
In the Tunnel Endpoint page, ensure the option This rule does not specify a tunnel is selected, and then click Next.
In the Network Type page, ensure that All network connections is selected, and then click Next.
In the IP Filter List dialog box, click Add.
In the second IP Filter List dialog box, type in a name, such as "ConfigMgr IP filter list". Ensure that Use Add Wizard is selected, and then click Add.
In the IP Filter Wizard, in the Welcome page, click Next.
In the IP Filter Description and Mirrored property page, ensure that the option Mirrored. Match packets with the exact opposite source and destination addresses is selected, and then click Next.
In the IP Traffic Source page, select My IP Address if not already selected, and then click Next.
In the IP Traffic Destination page, select A specific IP Address, type in the IP address of the other site server, and then click Next.
In the IP Protocol Type page, ensure that Any is selected, and then click Next.
In the Completing the IP Filter Wizard page, click Finish.
In the IP Filter List dialog box, click OK.
In the second IP filter List dialog box, select the IP filter list that you have just created ("ConfigMgr IP filter list"), and then click Next.
In the Filter Action dialog box, select Require Security, and then click Next.
In the Authentication Method page, select Use a certificate from this certification authority (CA), click Browse, select the CA that you are using for native mode, click OK, and then click Next.
In the Completing the Security Rule Wizard, click Finish.
In the policy properties dialog box, click OK.
In the Local Security Settings console, expand IP Security Policies on Local Computer if necessary, right-click the policy that you have just created ("ConfigMgr Site-to-Site"), and then click Assign.
Note: Check the status of the policy after assigning. If it is being overridden by IPsec policies by Active Directory, it will display "Policy is assigned, but it is being overridden by Active Directory-assigned policy." If that's the case, it's time to check in with your AD admins and assign the required policy through Active Directory.
*Note: This information was originally contributed by *Carol Bailey on the Configuration Manager Team blog: