Network Security Features in Windows Server 2008

Article
09/08/2016

Special Coverage: Windows Server 2008

Policy-Driven Network Access with Windows Server 2008

Ian Hameroff and Amith Krishnan

At a Glance:

Balancing network access and security
A policy-driven approach to network access
New security technologies in Windows Server 2008

Much has been written about the disappearance of traditional network perimeters brought about by an increasingly mobile workforce and the growing diversity of users and devices requiring

access to an organization's IT resources. To boost productivity, users and line-of-business owners alike are driving demand for a connected experience that is both fluid and free from tedious procedures. Adding to this already complex situation are increasing regulatory compliance burdens, the evolving threat landscape, and the risks associated with the decentralization of data.

This tends to leave Windows® administrators smack-dab in the middle of a challenging security balancing act: how to enable easy access to resources while still meeting ever-increasing information and network security requirements.

Though there may not be a single solution to all these challenges, as Windows administrators you do have a number of tools at your disposal that can help augment the security controls—like edge firewalls—you already have in place. A great way to help strike the appropriate balance between access and security is to shift from traditional connectivity models to one that seeks to define network access in a more logical and policy-centric fashion.

A Policy-Driven Network Access Approach

Networking Resources

Policy-driven network access aims to remove the existing limitations encountered when trying to base trust primarily on network topology edges. For instance, can you really determine that a device is trusted and authorized to connect to the servers that run your Customer Relationship Management (CRM) application, just because it is plugged into one of your Ethernet switch ports behind the corporate firewall?

Instead, the new model drives access decisions by authenticating both the security posture of the device and the identity of the user requesting the access, no matter where he is connecting from. Once authenticated, this same framework can then be used to authorize what information and resources may be accessed.

Making the shift from a defensive posture to one that is more access-focused involves a number of key ingredients, including having in place mechanisms that can validate the identity and policy-compliance of the connecting hosts, issue a trusted user identity, and dynamically control network access based on these attributes. To simplify the management of these various moving parts, a centralized policy store is also an important component.

Adopting a policy-driven approach can help you weave together a number of potentially disparate network access and host security controls into a more comprehensive solution. This in turn enables you to set network access ground rules at a logical layer above the connectivity fabric, thus evolving traditional defense-in-depth best practices.

For example, when a user connects his laptop to the organization's wireless network, the device can be checked for compliance with the latest security configuration requirements. Once it's determined that the laptop has all the current antivirus updates and critical security patches, and has all of its endpoint security controls enabled—like a host firewall—access to the corporate network can be granted. Then, when the user attempts to access a business application, the combination of the laptop's health state and the user's network identity can be used to determine if he is authorized to connect to the resources that host the application. By operating at this logical layer on top of the physical network infrastructure, the policies can be continually enforced, even if the user moves from wireless to a wired or even a remote-access connection.

When implemented, policy-driven network access can deliver a more seamless connected experience for users, without sacrificing security in the process. For administrators, up-leveling network access controls from switch ports or remote access gateway configurations can provide a simpler management experience. In both cases, the end result is increased productivity and an overall improvement of the health of the organization's network, even when the networks may play host to parties with differing access rights, such as guests (invited or otherwise), vendors, partners, and employees.

As with any security project, the first step in implementing policy-driven network access means developing a set of holistic operational policies. This normally includes guidelines for:

Device security compliance—what does it mean for a device to be healthy?
Logical network zoning—how will you segment unhealthy devices from authorized ones?
Information risk management—how is sensitive data classified and protected from compromise?

Luckily, a variety of policy-development resources are available at the Microsoft® TechNet Security Center (microsoft.com/technet/security).

Once you've developed the access policies, you will need to select technologies that can both easily distribute and effectively enforce them. For this, you need to look no further than Windows Server® 2008. That's because Windows Server 2008 is not only the most secure Windows Server to date; it also offers administrators a hardened security platform that can form the cornerstone of a policy-driven network access solution. Among its long list of new and enhanced features, Windows Server 2008 delivers many of the ingredients necessary to implement secure, policy-based access to your network, helping to ensure that sensitive information is safeguarded from compromise.

Next-Generation Networking

At the core of the network security advancements in Windows Server 2008 is the Next-Generation TCP/IP Stack, a major update to the platform's networking functionality and related services. Besides delivering improved network performance and increased scalability, Windows Server 2008 boosts security through a series of integrated network features that provides a solid foundation on which a policy-driven network access solution can be built.

Internet Protocol security (IPsec) is one such feature that was significantly upgraded in Windows Server 2008 so it could play a key role in a policy-driven network access approach. Now, this isn't about using IPsec as a tunneling and encryption protocol but instead leveraging its host-to-host network authentication capabilities. In addition, since IPsec works at Layer 3, it can be utilized to enforce network access policies across a variety of network types.

To help make implementing IPsec-based network-access controls easier, Windows Server 2008 introduces a long list of improvements and new features aimed at simplifying policy creation, enforcement, and maintenance. For example, the number and types of available IPsec authentication methods have been increased. This was accomplished through the introduction of Authenticated IP (AuthIP), an extension to the Internet Key Exchange (IKE) protocol. AuthIP gives you the ability to author connection security rules (another name for IPsec policies in Windows Server 2008) that require communicating peers to successfully authenticate each other with not only machine credentials but optionally with user or health credentials. This added flexibility enables the design of very sophisticated logical networks without the need for upgrading your switching and routing infrastructure.

Windows Firewall with Advanced Security

The new Windows Firewall with Advanced Security builds on top of the IPsec features just described. By combining IPsec connection security rules with firewall filters into a single policy, the new Windows Firewall adds another policy-driven network access dimension: more intelligent authenticating firewall actions.

As shown in Figure 1, you now have three options to choose from when defining the specific action an inbound or outbound firewall filter should take: allow, block, or allow only if secure. When "Allow the connection if it is secure" is selected as the action, the Windows Firewall leverages the host-to-host network authentication capabilities of IPsec to determine whether a host or a user requesting to connect should be approved based on the policy you've defined. The firewall rule lets you stipulate which users, computers, and groups have the right to make the connection. It's worth noting that this adds an additional layer of protection, supplementing existing operating system- and application-level access controls.

Figure 1 Defining authenticating firewall rules

Figure 1** Defining authenticating firewall rules **(Click the image for a larger view)

By now, you should begin to see how it's possible to weave together these different network security controls through a centralized policy for a more effective and scalable means to manage network access.

Returning to the CRM example: the administrator could create an inbound rule for the servers running the company's CRM application (either via the program's executable or service ports) with the "Allow the connection if it is secure" option checked. Within the same firewall policy, the administrator can specify that only members of the "CRM Application Users" group can connect to this network application, as shown in Figure 2. If you take this same concept and scale to all network communications among all the managed computers on your network, you've now added a Server and Domain Isolation layer to your policy-driven network access strategy.

Figure 2 Admins can specify who can connect based on this policy

Figure 2** Admins can specify who can connect based on this policy **(Click the image for a larger view)

Server and Domain Isolation

With most organizations experiencing an increasing number of guests and other unmanaged devices connecting to their networks, having the means to separate and protect your trusted hosts has become ever more critical. The good news is there are many ways to isolate trusted and managed computers from the others on the network. However, you should know that many of these options are costly (running separate physical cabling systems, for example) and difficult to maintain (such as switched-based VLANs) as networks grow.

Server and Domain Isolation can provide a more cost-effective and manageable means to segment your environment into logically isolated and secure networks. As Figure 3 shows, you essentially use the same connection security rules (that is, the IPsec policies) mentioned earlier, but map them to all of your managed computers via Active Directory® Group Policy. This results in a network access policy that requires all peers to successfully authenticate with each other before any communications begin. Since this isolation occurs at Layer 3, the enforcement of these access controls spans hubs, switches, and routers across physical and geographical boundaries.

Figure 3 Defining authentication requirements to match your network access needs

Figure 3** Defining authentication requirements to match your network access needs **(Click the image for a larger view)

To create an isolated network, the various computers on the network should be separated according to the type of access desired. Policies can be defined such that computers on an isolated network are able to initiate communications with all of the computers on the network, including those not located on the isolated network. Conversely, computers that are not on the isolated network cannot initiate communications with computers that are on the isolated network. In fact, computers on the isolated network will ignore all requests for communication from computers outside the isolated network.

An Active Directory domain and domain membership are used to enforce the network policy. Domain member computers accept only authenticated and secured communications from other domain member computers. Optionally, it can also be mandated that all communication within the isolated domain be encrypted.

Server and Domain Isolation provides significant cost benefits since no major changes to the existing network infrastructure or applications have to be made. This solution creates a policy-enabled veil of protection that not only helps defend against costly network attacks and unauthorized access to trusted network resources but also does not require ongoing maintenance based on changes in network topology.

Network Access Protection

As described previously, the Server and Domain Isolation solution ensures logical separation of the various computers and servers on the network. While this solution helps prevent unauthorized access to the network, there is no guarantee that an authorized computer will not be the cause of a security threat.

Network Access Protection (NAP) is a built-in platform in Windows Server 2008 that helps ensure that computers connecting to a network or communicating on a network meet requirements for system health (that is, security and policy compliance) as you have defined it.

Even authorized users are often responsible for propagating viruses and spyware on the network. For example, when a user goes on vacation, his computer could fall out of compliance with the security requirements set by the administrator. This could have potentially serious repercussions if a mandated patch or signature released during the absence doesn't make it to the computer.

It is well beyond an administrator's available bandwidth to keep track of every user who connects to the network. What is needed is an automated tool that can verify the health compliance of every computer connecting to the network, remediating any that are found to be non-compliant, all based on a central policy. NAP does just that, adding yet another layer to your policy-driven network access solution.

The NAP agent—either built into the OS of the client computer (such as in Windows Vista®) or separately installable (for older versions of Windows as well as non-Windows operating systems)—reports any compliance issues to the Network Policy Server (NPS), which is the policy engine built into Windows Server 2008. It is in the NPS where you define the compliance policies that every device must adhere to.

While it is necessary to restrict devices that fail compliance checks, it's important to ensure they have the option to quarantine and remediate. NAP provides the option either to automatically remediate the device in cases where the firewall or antivirus solution is turned on or to manually remediate the device by forcing it into a quarantine zone. Here, the device has access to a remediation server with the latest patches, updates, and signatures. Once the user manually updates the device, it is granted access to the network, subject to passing the compliance verification.

With ubiquity, network access has become much simpler. However, this has created an added burden of ensuring that devices are healthy and compliant irrespective of the access mechanism. Computers can access the network via a regular 802.1X-compliant switch or wireless access point, or they may connect remotely from home using a VPN- or Terminal Services-based remote access connection. NAP not only ensures compliance for computers that connect via these different mechanisms but also provide enforcement at the DHCP server, 802.1X switch, VPN gateway, Terminal Service gateway, or 802.1X-compliant wireless access point.

In Figure 4, the network has already been isolated using the server and domain isolation solution. Using NAP with such an isolated network provides additional benefits to ensure health compliance for computers connecting to the network. The client, on startup, sends its statement of health (SoH) to the Health Registration Authority (HRA), which is a certificate server. The HRA passes the SoH to the NPS for policy validation. If the SoH is valid, the HRA issues the NAP client a health certificate and the client can now initiate IPsec-based secure communication with secure resources. If the SoH is not valid, the HRA tells the NAP client how to correct its health state and does not issue a health certificate. The NAP client cannot initiate communication with other computers that require a health certificate for IPsec authentication. However, the NAP client can communicate with the remediation server to bring itself back into compliance.

Figure 4 Network Access Protection using IPsec enforcement

Figure 4** Network Access Protection using IPsec enforcement **(Click the image for a larger view)

Bringing It All Together

While we have just skimmed the surface of these new features and functionality in Windows Server 2008, it's important to recognize how each component has built upon the previous. What transforms this from the traditional defense-in-depth approach is the underlying policy framework Windows Server 2008 offers through, for example, Active Directory Group Policy.

Thanks to this integrated experience, you will have a strong working foundation to define and deploy a policy-driven network-access solution without having to undo existing investments. By raising the access decision up to a more logical, policy-centric layer, you have the opportunity to tip the "Easy Access" versus "Increased Security" balancing act into your favor.

Microsoft has published a good deal of guidance that drills down into the technology areas mentioned in this article. We recommend first reviewing these articles and step-by-step guides to gain operational experience with the various features. (The links in the "Networking Resources" sidebar can help you get started.) Then, consider rolling out each stage in a way that it provides a strong foundation for the next stage.

For example, create a set of those authenticating firewall rules for your mission-critical applications, as outlined in the Windows Firewall with Advanced Security section. Once you're comfortable with this, you can expand the connection security rules to isolate your network domain, and then layer NAP on top of that. The benefits of implementing a policy-driven network access strategy can be quite significant, including helping you keep pace with the ever-changing world we call our corporate networks.

Ian Hameroff is a Senior Product Manager in the Security and Access Product Marketing group at Microsoft. He is responsible for the product management and marketing of the Windows Server platform networking technologies. Ian drives the go-to-market strategy for Windows Server networking and solutions focused around key security and networking initiatives, such as Server and Domain Isolation, Scalable Networking, and IPv6 adoption.

Amith Krishnan is a Senior Product Manager in the Security and Access Product Marketing group at Microsoft and holds product management and marketing responsibilities for the Windows Server networking and security initiatives such as Network Access Protection and Secure Wireless. He also develops the go-to-market strategy and drives awareness for these solutions.

Additional resources