This post is second in a series by David Pracht and Steve Martin. To read the first post, click here.
Developing a plan...
We started by brainstorming about what we might need to consider in the environment.
For example – Does the Forest or Domain level matter? What exceptions will we need? Do we need to consider what OS we configure polices from? What machines will we need?
Our first consideration was how to implement the environment. We decided to implement the simplest possible configuration that a novice user might envision - Domain Isolation using the Microsoft Default policies that look, from their descriptions, like they should work without much modification. So for example, the servers and clients in the Secure network would need to have an IPsec policy of Secure Server - Require Security. The Servers and clients in the Boundary network would need to have an IPsec policy of Server - Request Security, and the DC’s and the untrusted servers and clients would need to have an IPsec policy of Client – Respond Only.
Last, all these settings would most likely be set via Group Policy from the DC.
Figure: Basic IPsec Domain Isolation scenario
Along the way the following questions arose.
Q: Does the Forest Level affect IPSec?
A: No the Forest Level does not affect IPSec even when using AuthIP with Windows Server 2008 and Vista as there are no schema extensions.
Q: Does the Domain level affect IPsec?
A: IPSec is not affected by the Domain Level but a 2008 domain level will require all 2008 Domain Controllers. This is not a likely scenario as most people will need to do a migration for Windows Server 2003 and not be able to use a 2008 Domain Level yet.
Q: What do we need to consider concerning Group Policy Management?
A: Group Policy management does have one caveat. Group Policy only requires that the policy be configured from a Windows Vista or Windows Server 2008 machine if you need support for the new features provided with AuthIP.
Our plan is a Windows Server 2003 Domain with 2003 Forest and Domain levels using XP/Windows Server 2003 IPsec policed managed from the DC.
The following machines are used with this plan:
2003 Domain Controller as untrusted 2008 Domain Controller as untrusted 2003 Member Server in the Secure domain 2003 Member Server in the Boundary domain XP client in the Secure domain
After implementing the above “All Default” plan we experienced the following. Servers and clients in the Secure zone could not communicate with any other machines. This means that they could not: Resolve names via DNS Obtain an IP address from DHCP Request Kerberos tickets for authentication or much of anything else except ICMP
Have we forgotten something? Maybe we need this hotfix:
914841 How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP
The Windows Server 2003 update and the Windows XP hotfix add functionality to Windows that enables you to use an IPsec "Simple Policy." For most environments, the installation of this update and hotfix lets you reduce the number of IPsec filters that are required for a Server Isolation deployment or for a Domain Isolation deployment. You can reduce the number of IPsec filters from many hundreds of filters to only two filters.
We added the hotfix to make sure that the timing was correct for connections but still couldn't make any of the connections work even though it was supposed to allow a configuration with fewer (if any) filters/exceptions.
What was left out of the plan on purpose was something we felt like many customers might not plan for: Exceptions.
So why did our initial set up not work? There is a hint in the points above and we will let you in on the solution with our next post.
- David Pracht
- Steve Martin
PingBack from http://windows2008security.com/network-security/ipsec-domain-isolation-a-test-study-developing-a-plan/