Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
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
954412 The IPsec remote management registry value is not preserved when you upgrade your computer to Windows Server 2008 or to a Server Core installation of Windows Server 2008
954408 Dynamic updates do not work on the standard primary DNS zone in Windows Server 2008
954396 The BITS client upload job fails when you use two virtual directories that share the same physical folder on a Windows Server 2008-based computer
954395 An additional cleanup task remains after you upgrade a server that is running BITS from Windows Server 2003 to Windows Server 2008
954423 A Windows Server 2008-based DNS server stops responding, and event ID 7023 is logged in the DNS server event log
- Mike Platts
In recent weeks we have seen a number of cases with intermittent file sharing connectivity to Windows Server 2008 servers. I wanted to get this information out so that people who may be experiencing the issue won't have to spend a lot of time tracking down the problem.
The issue generally manifests in one of two ways:
Network traces look similar in both cases. After the TCP 3-way handshake the client sends an SMB Negotiate Dialect but the server doesn't respond.
Eventually the TCP session times out and is reset as seen in this example:
Two things are currently known to address the issue:
Most of these cases involved older anti-virus software versions but we have also seen the issue with current versions that are supported on Windows Server 2008.
While there is not currently a complete resolution, I hope providing this information will help some people identify this issue quickly so they can resolve it and minimize the disruption to their environment.
We have been hearing of an issue since the recent release of an update to address a DNS spoofing vulnerability, MS08-037, discussed in KB951748. After application of the update, affected systems can experience problems with applications that rely on DNS name resolution. For example, a user on an affected system would not be able to browse the Internet.
The cases we have seen so far have involve ZoneAlarm software and Check Point Endpoint Security (previously named Check Point Integrity).
There are updates available for the ZoneAlarm products affected as well as interim workarounds posted at the following link at the ZoneAlarm site:
Workaround to Sudden Loss of Internet Access Problem
Check Point has updates available for its Endpoint Security and Integrity products as well. These updates and additional information may be found at this link:
Installing Microsoft security update for Windows (KB951748) might prevent Secure Access, Endpoint Security (Integrity) and ZoneAlarm users from accessing the Internet
We recommend updating the Check Point or ZoneAlarm software to correct the problem. We do not recommend not installing or uninstalling the update described in security bulletin MS08-037. Please read the bulletin to learn more about this vulnerability:
Microsoft Security Bulletin MS08-037 - Important
More information about the vulnerabilities corrected in this update may be found here:
CVE-2008-1447
CVE-2008-1454
Security Vulnerability Research & Defense - MS-08-037: More entropy for the DNS resolver
953730 The netsh command cannot start the PNRP Machine Name Publication Service on a Windows Server 2008-based computer
952899 Event IDs 1018 and 1020 appear in the Application log after you remove the SNMP service on a Windows Server 2008-based computer
953828 The NLB host does not converge as expected on Windows Server 2008 Hyper-V virtual machines
954425 Error message when you use the Bitsadmin.exe tool to try to upload files to a Windows Server 2008-based server that is running Internet Information Services 7.0: "The requested URL does not exist on the server"
952131 Piggybacked data on a TCP Acknowledgement (ACK) package may bypass the WFP inspection process in Windows Vista
952709 A reliability and performance update is available for Windows Vista SP1-based computers
954370 Error message when you try to connect to a domain controller for remote administration from a Windows Vista SP1-based computer that has Remote Server Administration Tools (RSAT) installed: "The RPC server is unavailable"
953609 Error message when you try to add a wireless network to a Windows XP-based computer that has hotfix 917021 applied: "At least one of your changes was not applied successfully to the wireless configuration"
952790 An application is unable to obtain an exclusive lock to a volume after the system runs for several hours in Windows Server 2008 or in Windows Vista Service Pack 1
953270 After a Windows Vista-based computer resumes from hibernation, the computer waits 30 seconds before it starts connecting to a new wireless network
952876 The TCP/IP Registry Compatibility service may stop responding when a computer that is running Windows Vista or Windows Server 2008 is under high stress
953650 You cannot connect to an 802.1X wired network after you upgrade to Windows XP Service Pack 3
953761 Some DHCP Options are not recognized on a Windows XP SP3-based client computer when the DHCP server offer includes option 43
The DHCP database can be moved or migrated from a Windows Server 2003 server to a Windows Server 2008 server, or from one Windows Server 2008 server to another. The information below details the necessary steps.
To move a DHCP database and configuration from a server that is running Windows Server 2003 or Windows Server 2008 to another server that is running Windows Server 2008:
1. Log on to the source DHCP server by using an account that is a member of the local Administrators group.
2. Click Start, click Run, type cmd in the Open box, and then click OK.
3. Type netsh dhcp server export C:\dhcp.txt all , and then press ENTER.
Note: You must have local administrator permissions to export the data.
1. Click Start, click Administrative Tools, click Server Manager. If needed acknowledge User Account Control.
2. In Roles Summary click Add Roles, click Next, check DHCP server, and then click Next.
1. Log on as a user who is an explicit member of the local Administrators group. A user account in a group that is a member of the local Administrators group will not work. If a local Administrators account does not exist for the domain controller, restart the computer in Directory Services Restore Mode, and use the administrator account to import the database as described later in this section.
2. Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer.
3. Verify that the DHCP service is started on the Windows Server 2008-based computer.
4. Click Start, click Run, type cmd in the Open box, and then click OK.
5. At the command prompt, type netsh dhcp server import c:\dhcpdatabase.txt all , and then press ENTER, where c:\dhcpdatabase.txt is the full path and file name of the database file that you copied to the server.
Note When you try to export a DHCP database from a Windows 2000/2003 domain controller to a Windows Server 2008 member server of the domain, you may receive the following error message:
Error initializing and reading the service configuration - Access Denied
Note You must have local administrator permissions to import the data.
6. To resolve this issue, add the Windows Server 2008 DHCP server computer to the DHCP Admins group at the Enterprise level and redo steps 4 & 5.
7. If the "access is denied" error message occurs after you add the Windows Server 2008 DCHP server computer to the DHCP Admins group at the Enterprise level that is mentioned in step 6, verify that the user account that is currently used to import belongs to the local Administrators group. If the account does not belong to this group, add the account to that group, or log on as a local administrator to complete the import and redo steps 4 & 5.
1. Click Start, point to All Programs, point to Administrative Tools, and then click DHCP.
Note You must be logged on to the server by using an account that is a member of the Administrators group. In an Active Directory domain, you must be logged on to the server by using an account that is a member of the Enterprise Administrators group.
2. In the console tree of the DHCP snap-in, expand the new DHCP server. If there is a red arrow in the lower-right corner of the server object, the server has not yet been authorized.
3. Right-click the server object, and then click Authorize.
4. After several moments, right-click the server again, and then click Refresh. A green arrow indicates that the DHCP server is authorized.
- Wayne Melvin
This is just an overview; I am including several links with more detail on Windows Vista and Windows Server 2008 networking. You can take this as far as you like; it is a very deep rabbit hole.
For simplicity I am going to compare Windows XP and Windows Vista. Please remember that Windows Server 2008 contains the updated networking stack that was introduced in Windows Vista so the comparison is still valid.
We have had a few support calls in Networking Support lately where people are comparing network performance between operating systems and they want to know two things:
Actually, the second question is usually asked more along the line of "why is my Windows XP computer broken and what can I do to "fix" it?" but I think you get the point.
Let me start by saying that there is nothing "wrong" with Windows XP. It is not "broken" and does not need to be "fixed".
To answer question 2 first, you will never get Windows XP to perform exactly like Windows Vista from a networking perspective; the network stack is very different between the two. There are some changes that can be made to Windows XP that may affect performance. Notice that I said "changes". This is because in some of these changes there are potential tradeoffs to resources on the local system that could negatively impact overall system performance and could change the behavior of TCP in a way that may actually decrease performance on the network. In some instances making these changes on a large scale to several clients could even negatively impact the overall performance of your entire network.
I recently had a call from a customer who was seeing up to a 7 times performance improvement when transferring files between two systems running Windows Vista, compared to transferring the same files between two Windows XP systems. I found this fairly impressive since in the testing and studies I have read about the expected improvement was generally about 3.5 times. So I agreed to investigate to ensure that there was in fact not a problem with Windows XP. After reviewing much data and testing some changes on the Windows XP system we concluded that he was in fact seeing that much better performance across the wire for his Windows Vista systems.
To answer question one, what changed that could explain such a difference in performance? Well, a lot. Starting with Windows Vista we have a new network stack. The Cable Guy, aka Joe Davies (you may have noticed his name on the cover of some of the MS Press books), has written some good overviews of the new network stack, you can find them at the following links.
Next Generation TCP/IP Stack in Windows Vista and Windows Server 2008 http://technet.microsoft.com/en-us/library/bb878108.aspx Performance Enhancements in the Next Generation TCP/IP Stack http://technet.microsoft.com/en-us/library/bb878127.aspx
Some of the really cool stuff that has been added to the new network stack is:
I hope everyone reading this can appreciate how huge this is. More aggressive send and receive and more intelligent congestion avoidance! If you’re a network admin and you didn't already know about this and your still in your chair, check your pulse, you should be dancing about and people should be looking at you like you have lost your mind. This is part of the "magic" that will allow for more throughput while also avoiding congestion so fewer retransmitted packets. Yay!
But then you have to sit down and realize that these are changes to the very core of the networking stack and these changes which involve large amounts of code changes can never be made to Windows XP, the new stack is just too different.
So besides the network stack there is another improvement. This is more at an application layer but very important for things like file copies.
Let me point out again that the better performance we saw was doing a file copy between Windows Vista or Windows Server 2008 connecting to another Windows Vista or Windows 2008 system. One reason this is significant is something called SMB2. SMB2 is only available starting with Windows Vista so even if you are on a Windows Vista client, if you connect to a Windows XP or Windows Server 2003 system you will not be able to take advantage of the improvements made in SMB2.
A good quick overview of SMB2 is actually on the Performance Team blog. http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx
Some of the changes made in SMB2 include;
So this also translates to a much improved user experience for anything using SMB 2, such as file copies.
As I mentioned this was just an overview but I wanted to make sure everyone understands why they may be seeing some difference in the performance of legacy systems and Windows Vista and Windows server 2008 and also help explain why these changes won't be back ported to the legacy systems.
References:
For a comparison of Windows XP and Windows Vista networking performance, see the results of the the analysis done by The Tolly Group. This can be downloaded from the following link. http://www.microsoft.com/downloads/details.aspx?FamilyID=04cad8b9-9f9f-453a-893a-458d22dbb3c5&DisplayLang=en Mark Russinovich's blog "Inside Vista SP1 File Copy Improvements." http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx Next Generation TCP/IP Stack in Windows Vista and Windows Server 2008 http://technet.microsoft.com/en-us/library/bb878108.aspx Performance Enhancements in the Next Generation TCP/IP Stack http://technet.microsoft.com/en-us/library/bb878127.aspx SMB2 Two Minute Drill on the Performance Team blog. http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx
- Clark Satter
IPSec is becoming increasingly popular and as a result we are seeing more support calls on it. I wanted to give a brief overview of the IPSec wizard in the Windows Firewall with Advanced Security as well as provide some additional references. IPSec is a great tool that can help in securing your network, however many people find it difficult and confusing to deploy. If you are new to IPSec and just wanting to know more about it or are preparing for your first deployment, I suggest skipping to the additional references at the end of this blog post. If you are already familiar with the legacy IPSec wizard in Windows XP and Windows Server 2003, then my hope is that this blog post will help you in getting more comfortable with the new Windows Firewall with Advanced Security console for creating your IPSec rules in Windows Vista and Windows Server 2008.
When creating IPSec rules for Windows Vista and Windows Server 2008 on a Windows Vista or Windows Server 2008 server, you should now be using the Windows Firewall with Advanced Security console. While the legacy IPSec policy console does still exist, this is not the preferred method. Also the legacy wizard presents the option to select the Default Response Rule (DRR); this rule is no longer supported in Windows Vista or Windows Server 2008 and should not be selected when creating rules for these operating systems, as noted in KB article 942964.
In the legacy IPSec console shown below, you would right click on "IP Security Policies on Local Computer" to start the IP Security Policy Wizard. This wizard still exists in Windows Vista and Windows Server 2008 for the creation IPSec policies in mixed environments.
Note: As mentioned earlier the Legacy wizard presents the Requests for Secure Communication page. While this wizard can be used to creates IPSec policies for all Windows operating systems it is best to get in the habit of not selecting the Activate the default response rule in this wizard, since Windows Vista and Windows Server 2008 no longer support this rule. The Default Response Rule can be enabled in the IPSec Management console after the rule is created.
When you open the Windows Firewall with Advanced Security console you will see an option for Connection Security Rules. If you select this you will see a list of the currently configured rules.
In the Windows Firewall with Advanced Security console a new IPSec rule is created by right clicking on Connection Security Rules and selecting New Rule. This will bring up the New Connection Security Rule Wizard.
There are various rule types that can be selected. All rules include the Profile and Name Steps in the wizard.
The Isolation rule includes the Requirements and Authentication Method.
The Authentication exemption rule adds the Exempt computers option.
The Server-to-Server and Custom rules include the Endpoint option.
The Tunnel rule adds the Tunnel Endpoint option. It is important to note that the Tunnel Endpoint and Endpoint options are slightly different.
Notice that you can move through the wizard by selecting Next or you can skip to different parts of the wizard by using the Steps menu on the left. Also, the Steps menu on the left will change depending on the type of connection you select in the wizard.
It is also important to realize that different rule types will change options in other parts of the wizard. For example, while the Authentication Method will be displayed in the menu on the left for both the Isolation and the Server to server rules, the available Authentication Methods will change. This is to be expected as different options are appropriate depending on the type of rules being selected.
The advanced option allows for more granular control of the authentication methods that will be used in the IPSec negotiation.
Below are the options that will be available to add. Notice that the available authentication methods are not identical. It is important to note, as mentioned in the dialog on the first authentication method, that if you select the Preshared key you cannot select a second authentication method. The Preshared key is considered less secure and really is only supported for testing.
Once the authentication method is selected you will need to select the profile that the rule will apply to.
For the Tunnel rule type you will see the following options.
Notice how this differs from the Server-to-server Endpoints.
As I mentioned this is just an overview of the IPSec portion of the Windows Firewall with Advanced Security console and what it contains. My hope is this will make administrators more comfortable with this interface as we move from the legacy wizard to the new Windows Firewall with Advanced Security console.
For additional information see the following links:
TechNet article - Security: Managing the Windows Vista Firewall
This article has a description of the Profiles and a little more depth on rules and filtering.
http://technet.microsoft.com/en-us/magazine/cc510323(TechNet.10).aspx
Security rules for Windows Firewall and for IPsec-based connections in Windows Vista and in Windows Server 2008 http://support.microsoft.com/default.aspx?scid=KB;EN-US;942957
How IPSec Works http://technet2.microsoft.com/windowsserver/en/library/8fbd7659-ca23-4320-a350-6890049086bc1033.mspx?mfr=true
948745 MS08-034: Vulnerability in WINS could allow elevation of privilege
951376 MS08-030: Vulnerability in Bluetooth stack could allow remote code execution
953979 Device Manager may not show any devices and Network Connections may not show any network connections after you install Windows XP Service Pack 3 (SP3)
Our friends over at the Network Monitor Blog have information on how to get the beta for Netmon 3.2. There are some really cool new features in this release. Find more information here:
http://blogs.technet.com/netmon/archive/2008/06/12/network-monitor-3-2-beta-has-released.aspx
951851 The WebClient service stop responding when you try to map a network drive to a WebDAV shared folder from a Windows Server 2003-based computer
950092 Third-party vendors may be unable to achieve IPv6 Ready Logo Phase-2 certification in Windows Server 2003
949429 The virtual IP address of a Windows Server 2008 NLB cluster is bound to the NetBIOS host name of a particular server or of multiple servers
947028 How to restrict SSTP connections to a specific IP address in Windows Server 2008
950826 You cannot establish an IPsec connection between a Linux operating system and a Windows Vista operating system when you initiate the connection from the Linux operating system
950319 On a multiprocessor computer that is running Windows Vista or Windows Server 2008, a network connectivity failure occurs randomly when you run certain utilities
953791 Device Manager and Network Connections may be blank after you install Windows XP Service Pack 3
949821 Two options in the “Customize Advanced Key Exchange Settings” dialog box are truncated on a computer that is running the Russian version of Windows Vista Service Pack 1 (SP1) or the Russian version of Windows Server 2008
949825 The Notify window in the DNS Manager is clipped in the Italian version of Windows Server 2008
949796 If you are running the Czech version of Windows Server 2008, you cannot locate the "Add" and "Remove" buttons on the "Server Farm" tab in the TS Gateway Manager component
942835 When client computers try to access resources on a Windows Server 2003-based file server, the Server service on the file server may stop responding
Hello,
Our names are David Pracht and Steve Martin. As Networking Support Professionals at Microsoft we support IPSec but historically it has not been a high call generator. We designed this lab to explore an increasingly popular scenario – IPSec Domain Isolation. While it can be the most difficult scenario to deploy it is also very tempting to have the ability to protect all the traffic in your network without requiring specific application support. The reality is somewhere in between and we wanted to see if we could identify where people might encounter issues and document in a series of posts any problems we uncover while attempting to setup this scenario.
IPSec provides technological support to implement a number of scenarios that improve enterprise network security:
■ Secure Server to Server: IPSec can be used to encrypt traffic between two servers. An example of this is Outlook Web Access and Exchange. All communications between the OWA server and the Exchange server could be authenticated and encrypted.
■ Server Isolation: IPSec can be used to isolate a server from unauthenticated (and possibly rogue) clients. A good example of this is a line of business application server. The application server would only grant access to machines that belong to the domain. All other clients would not be able to even establish a TCP connection; guaranteeing the application server is isolated from the unknown clients.
■ Domain isolation: IPSec can be used to isolate domain members from non-domain members. All domain members would be able to connect to each other securely. Non-domain members would not be able to connect to any domain machine, as they are not successfully authenticated. However, domain members may be able to connect to non-domain servers.
Despite the historical difficulties in deploying an administering IPSec it has some compelling features and is becoming easier to implement.
Here are some of the benefits provided by IPSec:
■ Defense-in-depth against vulnerabilities in upper-layer protocols and applications.
IPSec protects upper layer protocols, services, and applications. With IPSec enabled, initial communication packets to access an application or service running on a server, for example, will not be passed to the application or service until trust has been established through IPSec authentication and the configured protection on packets for the application or service have been applied. Therefore, attempts to attack applications or services on servers must first penetrate IPSec protection.
■ Requiring peer authentication prevents communication with untrusted or unknown computers.
IPSec security requires peers to authenticate their computer-level credentials prior to sending any IP-based data. By requiring peer authentication using credentials based on a common trust model, such as membership in an Active Directory domain, untrusted or unknown computers cannot communicate with domain members. This helps protect domain member computers from the spread of some types of viruses and worms being propagated by untrusted or unknown computers.
■ IP-based network traffic is cryptographically protected.
IPSec provides a set of cryptographic protections for IP-based traffic based on your choice of AH, ESP without encryption, or ESP with encryption. Your IP-based network traffic is either tamper proofed (using AH or ESP with no encryption), or tamper proofed and encrypted (with ESP and encryption). Requiring cryptographic protection of IP traffic helps prevent many types of network attacks.
■ Applications do not need to be changed to support IPSec.
IPSec is integrated at the Internet layer of the TCP/IP protocol suite, providing security for all IP-based protocols in the TCP/IP suite. With IPSec, there is no need to configure separate security for each application that uses TCP/IP. Instead, applications that use TCP/IP pass the data to IP in the Internet layer, where IPSec can secure it. By eliminating the need to modify applications, IPSec can save application development time and costs.
In short if you need security IPSec is the way to protect you network.
In the past with Windows Server 2003 and Windows XP, all these scenarios rely on machine-level authentication, which is what the IKE protocol that is supported by these operating systems supports.
Note: In addition to IKE Windows Vista and Windows Server 2008 support a new keying protocol called AuthIP.
IPSec policy configuration in many scenarios, such as server isolation and domain isolation, consists of a set of rules to protect most of the traffic on the network and another set of rules for protected traffic exceptions.
Exceptions are needed for unprotected communication with network infrastructure servers such as DHCP, DNS, and Domain Controllers. For example: When a computer is starting, it must be able to obtain an IP address, use DNS to find a domain controller, and then log in to its domain before it can begin to use Kerberos authentication to authenticate itself as an IPSec peer.
In some cases, there are dozens or even hundreds of exceptions, which makes it difficult to deploy IPSec protection on a private network and to maintain it over time. There is an optional feature called “Fallback to Clear” but the 3 second delay it introduced was often too long for networking scenarios like obtaining an IP address to complete.
Note: In Windows Server 2003 and XP this was addressed by the Simplified IPSec Policy Configuration update.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;914841
That sums up why we are taking on this adventure and hopefully we will be able to provide some insight for other people planning to implement IPSec Domain Isolation.
Next post – We will define our scenario and see what issues come up that we will need to address.
David Pracht – Support Escalation Engineer
Steve Martin – Support Engineer