Capability: Security and Networking

On This Page

Introduction
Requirement: Policy-managed Firewalls on Servers and Desktops
Requirement: Secure Remote Access to Internal Resources and LOB Applications
Requirement: Secured and Guaranteed Communication Verification Between Servers
Requirement: Service Level Agreement Monitoring and Reporting for Servers
Requirement: Secure Communication Mechanism for Presence
Requirement: Active Directory and IAS/RADIUS for Wireless Network Authentication and Authorization
Requirement: Centrally Managed Certificate Services
Requirement: Proactively Managed Bandwidth to Branch Offices

Introduction

Security and Networking is the third Core Infrastructure Optimization capability. The following table describes the high-level challenges, applicable solutions, and benefits of moving to the Rationalized level in Security and Networking.

Challenges	Solutions	Benefits
Business Challenges Multi-layered security models are not deployed across the network—from perimeter, through firewall, server, desktop, and application levels Firewall is not a standard component of desktops Mobile users lack secure access to resources through the routing infrastructure provided by a public network IT Challenges Servers accept inbound traffic from any host, increasing vulnerability to attacks Weak authentication of wireless clients Weak encryption and data integrity of wireless LAN	Projects Deploy policy-managed firewalls on servers. Secure remote access to internal resources and LOB applications Provide secured and guaranteed communication verification between servers Implement SLA monitoring and reporting for servers Implement secure communication mechanism for presence Deploy Active Directory and IAS/RADIUS for wireless network authentication and authorization Implement centrally managed certificate services Begin to proactively manage bandwidth to branch offices	Business Benefits Users have secure access to resources regardless of location Proactive policies and processes for security, configuration, and management increase stability IT Benefits Improved asset management of hardware and software for desktops Centralized group policies to distribute IPsec policies and filters, increasing the level of security on PCs IPsec policies increase the security of network environments by limiting inbound traffic to trusted hosts IT spends less time managing crises and more time delivering new services to the business

The Rationalized Level in the Infrastructure Optimization Model addresses the key areas of networking and security components, including: local firewalls, IP security, availability monitoring, securing wireless infrastructure, certificate management, and WAN management.

Requirement: Policy-managed Firewalls on Servers and Desktops

Audience

You should read this section if you do not have a policy-managed firewall on at least 80 percent of your servers and desktops.

Overview

In Core Infrastructure Optimization Resource Guide for Implementers: Basic to Standardized , * *you read about protecting network computers by using a centralized perimeter firewall. To move from the Standardized level to the Rationalized level, you need to supplement your network’s firewall protection by establishing and enforcing policies on your servers and desktops using class 1 host-based firewalls. Microsoft and other software vendors offer firewall software that allows you to configure protection based on a policy or set of rules. This requirement is tightly associated with the requirement for Centralized Directory-based Configuration and Security also at the Rationalized level.

Most class 1 firewalls can be configured for different levels of protection, from minimal to very restrictive. When you allow users to set the level of protection on their own computers, you cannot be assured that they will select a level that will protect your entire network. With policy-managed firewalls, you can determine the level of security that meets your network needs.

Phase 1: Assess

In the Assess phase, you are again assessing which computers in your environment already have some form of host-based firewall with policy management capabilities. The Rationalized level stipulates that 80 percent or more of your desktop PCs run either Windows XP SP2 or Windows Vista (see Requirement: Latest Two OS Versions and Service Packs on Desktops); there is no stated requirement at the Rationalized level that servers run the latest two operating systems. This is important because, assuming your organization has deployed the latest two desktop operating system versions, you will have already met the requirement of having host-based firewall features available on desktops, and you will simply need to incorporate configuration enforcement requirements via Group Policy to ensure that Windows Firewall is running with a desired configuration. Host-based firewalls in Windows Server products began with the release of Windows Server 2003 SP1, so if your organization is not running at least 80 percent of its server infrastructure with Windows Server 2003 SP1 or later, you will need to inventory and identify these systems without a host-based firewall. To automate the operating system and application information on server infrastructure, it is recommended to use SMS 2003 hardware inventory.

Phase 2: Identify

Using your server inventory generated in the previous phase, the Identify phase simply isolates the server infrastructure requiring host-based firewalls. In the Evaluate and Plan phase, you will determine the appropriate mitigation strategy to enable host-based firewalls and determine the appropriate firewall configuration to be enforced using Group Policy.

Phase 3: Evaluate and Plan

In the Evaluate and Plan phase, you will examine host-based firewall technologies and determine the appropriate course of action to have host-based firewalls present on 80 percent of desktops and servers in your organization. After the strategy has been determined for applying host-based firewalls to the majority of your desktops and servers, you should determine how Group Policy can be used to enforce usage and configuration of the host-based firewalls. This phase is only responsible for evaluating and planning for host-based firewall deployment in a test environment. The following sections focus on Windows Firewall, but you may elect to use similar technologies, such as BlackICE from Internet Security Systems or Zone Alarm from Zone Labs.

Windows Firewall

Windows Firewall is a built-in, host-based, stateful firewall that is included in Windows XP with Service Pack 2, Windows Server 2003 with Service Pack 1, Windows Vista, and Windows Server Code Name "Longhorn" (now in beta testing). Windows Firewall drops incoming traffic that does not correspond to either traffic sent in response to a request of the computer (solicited traffic) or unsolicited traffic that has been specified as allowed (excepted traffic).

As a host firewall, Windows Firewall runs on each of your servers and clients; it provides protection from network attacks that pass through your perimeter network or originate inside your organization, such as Trojan horse attacks, worms, or any other type of malicious program spread through unsolicited incoming traffic.

For more resources on Windows Firewall, go to https://www.microsoft.com/technet/network/wf/default.mspx.

Windows Firewall, or similar host-based firewall functionality, on 80 percent of desktops and servers is a requirement. As previously mentioned, other host-based firewall products that you may want to evaluate are BlackICE from Internet Security Systems and Zone Alarm from Zone Labs.

Getting Host-based Firewalls on Desktops and Servers

Once you have selected your preferred firewall technology for desktops and servers and targeted the hosts in need of firewall capabilities, your next task is to test, configure, and deploy those firewall applications to the test infrastructure. These steps align with best practices observed in this guide for patch management, application compatibility testing, and application deployment, as described in Patch Management for Servers, Compatibility Testing and Certification of Software Distributions, and Automated Tracking of Hardware and Software for Desktops. If you have selected Windows Firewall as your single and preferred technology for servers predating Windows Server 2003 SP1, you will need to update targeted servers to Windows Server 2003 SP1 or newer.

Policy Management of Firewalls

Policy management of the host-based firewall is also required as part of the Rationalized level in Core Infrastructure Optimization. For Windows Firewall users, the key is to simply ensure the firewall service is enabled. This straightforward process is performed via the following steps using Group Policy:

Verify that the Group Policy setting, Windows Firewall: Prohibit use of Internet Connection Firewall on your domain network, is either disabled or not configured.

If enabled, this setting prevents anyone, including administrators, from enabling or configuring Windows Firewall. To change this policy setting, use the Group Policy Object Editor to edit the Group Policy objects (GPOs) that are used to manage Windows Firewall settings in your organization.

To modify the Prohibit use of Internet Connection Firewall on your domain network setting

1. Open the Group Policy Object Editor to edit the GPO that is used to manage Windows Firewall settings in your organization.

2. Click Computer Configuration, click Administrative Templates, click Network, and then click Network Connections.

3. In the details pane, double-click the Windows Firewall: Prohibit use of Internet Connection Firewall on your domain network policy setting.

4. Select either the Disabled or Not Configured check box.

If you are not using Windows Firewall, locate the equivalent setting for the selected host-based firewall and perform the equivalent procedure. Once completed for at least 80 percent of managed clients and servers, this attribute of the requirement for Policy-managed Firewalls on Servers and Desktops is completed. For more information on Group Policy, see the requirement for Centralized Directory-based Configuration and Security in this guide.

For more information on advanced Windows Firewall settings, see Best Practices for Managing Windows Firewall.

Phase 4: Deploy

As a result of the previous three phases, you should be ready to deploy your selected host-based firewall technology and enable policy management. Again, the deployment process encompasses the equivalent best practice recommendations for patch management, application compatibility testing, and application deployment, as described in Patch Management for Servers, Compatibility Testing and Certification of Software Distributions, and Automated Tracking of Hardware and Software for Desktops. Refer to those requirements for detailed information about the planning and deployment process.

Further Information

For more information on firewalls, visit Microsoft TechNet and search for “Windows Firewall.”

To see how Microsoft incorporates firewalls into network perimeter security, go to https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx.

Checkpoint: Policy-managed Firewalls on Servers and Desktops

	Requirements
	Inventoried your desktop and server computers to identify which hardware currently has host-based firewall technologies.
	Deployed host-based firewall technology to hardware lacking firewall capabilities or updated servers to Windows Server 2003 SP1 or later.
	Established policy enforcement to ensure that host-based firewalls are always enabled and cannot be disabled.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Policy-managed Firewalls on Servers and Desktops capabilities of the Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources outlined in this guide for policy-managed host-based firewalls and in Best Practices for Managing Windows Firewall.

Go to the next Self-Assessment question.

Requirement: Secure Remote Access to Internal Resources and LOB Applications

Audience

You should read this section if your employees do not have secure remote access to internal resources and LOB applications beyond e-mail—for example, a virtual private network (VPN) or Microsoft Terminal Services.

Overview

In the current business environment, organizations are under pressure to reduce costs, increase efficiency, and maximize performance from the existing infrastructure. The growth of the Internet, together with new global business opportunities, makes it imperative that organizations provide secure 24x7 network access to employees and locations around the world. Two scenarios in which remote access is typically used are:

• Remote client access. Remote clients are usually single computers, such as home computers or laptops of employees who need to access enterprise resources while working at home or traveling.

• Site-to-site access. Site-to-site access is used between branch offices and centralized facilities of the organization to access resources and data at different logical and physical locations.

Both of these key remote access requirements of an enterprise organization can be provided using a VPN. Both of these solutions require the underlying presence of either a dial-up connection or an Internet (shared) leased-line connection. This guide focuses on VPN and introduces Terminal Services to fulfill the requirement. Guidance is based on Windows Server System Reference Architecture (WSSRA) Remote Access Services.

For more technical resources on VPN in Windows Server 2003, visit the Virtual Private Networks Web site on Microsoft TechNet.

Phase 1: Assess

During the Assess phase, you should identify the current ways your user base is working from remote locations. Organizations often only provide access to e-mail via services such as Microsoft Office Outlook® Web Access (OWA) or Web-enabled line-of-business applications. In these cases, end users effectively have a subset of functionality compared with those on-site. In the Assess phase, you should determine the high-level list of services available to users on-site, such as Intranet and collaboration services, and those available to users off-site or in branch offices, such as Web-based e-mail and LOB applications.

Phase 2: Identify

Now that you have the list of services for on-site and off-site or branch office users, the Identify phase simply determines which services offered on site would increase user productivity and effectiveness if securely delivered through remote access to off-site users. Typically, the key remote access requirements of an organization, namely remote client access and site-to-site access, can be provided using a VPN. Both of these solutions require an Internet connection or a leased-line connection.

Phase 3: Evaluate and Plan

The Evaluate and Plan phase examines how the selected remote access services are delivered, along with controls used to maintain security. For most organizations, it would be too costly to open an office in every city or to provide private circuits to every employee’s home to ensure secure connections to the enterprise network. A VPN enables business partners and employees to make secure, encrypted connections using the Internet, usually at a lower cost.

Virtual Private Networks

A virtual private network (VPN) is a secure, encrypted connection between two endpoints that is established over a shared connection such as the Internet and used as an extension of an enterprise network. A VPN enables the organization to use the existing global Internet infrastructure by simply connecting an office or user to an Internet service provider (ISP). VPN is also an extensible technology; for example, Voice over IP (VoIP) can be implemented to allow remote users to use their office telephone extension (with all of its messaging capabilities) wherever they may be working at the time.

VPN connections allow users who work at home or travel to obtain a remote access connection to an organization server, using the infrastructure provided by a public internetwork such as the Internet. From the user's perspective, the VPN is a point-to-point connection between the computer, the VPN client, and an organization server (the VPN server). The exact infrastructure of the shared or public network is irrelevant because it appears as if the data is sent over a dedicated private link.

VPN connections also allow organizations to have routed connections with other organizations over a public internetwork such as the Internet while maintaining secure communications, for example, for offices that are geographically separate. A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.

The following diagram depicts an architectural design for remote access services using VPN.  

Figure 7. Architectural design for remote access services using a VPN

VPN Design Considerations

There are many issues that need to be considered when designing a VPN solution, including security, costs, integration, future requirements, and administration. Before deciding on the appropriate VPN technology, it is important to determine the design goals for a VPN solution. These goals differ depending on whether the solution is for client remote access, site-to-site access, or both. For more information about VPN design options, see the WSSRA Remote Access Services Blueprint.

Planning for Remote Access Services

The remote access design is based on information gathered during the process of determining the business and technical requirements. Typically, a remote access solution is necessary for remote clients, such as employees working at home or while traveling, and branch office sites with multiple users, where business class site-to-site connections exist.

For detailed information on planning remote access services to remote clients, read WSSRA Remote Access Services Planning Guide for the Corporate Data Center (CDC) Scenario.

For detailed information on planning remote access services to branch offices, read:

• WSSRA Remote Access Services Planning Guide for the Satellite Branch Office (SBO) Scenario

• Virtual Private Network Design for the Branch Office Infrastructure Solution

Terminal Services

The Terminal Services component of Microsoft Windows Server 2003 lets you deliver Windows-based applications, or the Windows desktop itself, to virtually any computing device—including those that cannot run Windows.

Terminal Services in Windows Server 2003 provides three important benefits for secure remote access:

• Rapid centralized deployment of applications.

• Low-bandwidth access to data.

• Windows anywhere.

For more information on Terminal Services, go to http://technet2.microsoft.com/windowsserver/en/technologies/featured/termserv/default.mspx.

Phase 4: Deploy

After evaluating your options for remote access services and planning for what is required to provide appropriate service to remote clients and branch offices, the implementation of your design occurs in the Deploy phase. The WSSRA Remote Access Services Build Guide provides implementation steps for testing and deploying VPN services to remote clients in the CDC scenario and to branch offices in the SBO scenario.

Further Information

To see how Microsoft implements VPN and Terminal Services, go to the following Web sites:

• https://www.microsoft.com/technet/itshowcase/content/isa2004sp2.mspx

• https://www.microsoft.com/technet/itshowcase/content/rasecwp.mspx

Checkpoint: Secure Remote Access to Internal Resources and LOB Applications

	Requirements
	Evaluated remote access requirements for remote clients and branch offices.
	Designed and implemented secure virtual private network or similar services to remote clients and branch office.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Secure Remote Access to Internal Resources and LOB Applications capabilities of the Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources for VPN found in the Virtual Private Networks Web site on Microsoft TechNet.

Go to the next Self-Assessment question.

Requirement: Secured and Guaranteed Communication Verification Between Servers

Audience

You should read this section if you do not have a secured and guaranteed way to verify communication between critical servers such as domain controllers and e-mail servers.

Overview

Organizations face increasing challenges in securing the perimeters of their networks. As organizations grow and business relationships change, and customers, vendors, and consultants need to connect mobile devices to your network for valid business reasons, controlling physical access to a network can become impossible. The advent of wireless networks and wireless connection technologies has made network access easier than ever. This increased connectivity means that domain members on the internal network are increasingly exposed to significant risks from other computers on the internal network, in addition to breaches in perimeter security.

The concept of logical isolation this guide presents embodies two solutions: server isolation to ensure that a server accepts network connections only from trusted domain members or a specific group of domain members, and domain isolation to isolate domain members from untrusted connections. These solutions can be used separately or together as part of an overall logical isolation solution.

At its core, server and domain isolation enables IT administrators to restrict TCP/IP communications of domain members that are trusted computers. These trusted computers can be configured to allow only incoming connections from other trusted computers or a specific group of trusted computers. Group Policy centrally manages the access controls that control network logon rights. Nearly all TCP/IP network connections can be secured without application changes because Internet Protocol Security (IPsec) works at the network layer below the application layer to provide authentication and per-packet security, end-to-end between computers. Network traffic can be authenticated, or authenticated and encrypted, in a variety of customizable scenarios. This guide follows guidance and recommendations from the Server and Domain Isolation Using IPsec and Group Policy Guide on Microsoft TechNet.

Phase 1: Assess

Consistent with other requirements in this guide, the first phase is about assessing the current state of your organization. The process of obtaining and maintaining a reliable record of an organization's computers, software, and network devices is a classic IT challenge. Information about the following items is required to define the current state:

• Network discovery

• Documentation of network segmentation

• Network infrastructure devices

• Analysis of current network traffic model

• Active Directory

• Host discovery

• Host data requirements

For detailed information on how to gather this information, read the Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 3: Determining the Current State of Your IT Infrastructure. This guide discusses the requirements for each item and how to collect information via automated discovery using SMS 2003 or similar products as well as manual discovery options.

Phase 2: Identify

The Identify phase is about determining which strategies are appropriate for your organization’s needs. Defending a modern IT infrastructure from attackers while simultaneously allowing employees to work in the most agile and productive manner is not an easy task. Simply understanding the wide range of technologies that can help secure an environment is difficult enough for many people. It might help to see exactly where the solution fits within a typical IT infrastructure and how it is designed to complement existing network defenses.

The following figure shows a typical network infrastructure consisting of a number of network defense layers and illustrates where logical isolation fits within a typical environment.

Figure 8. Typical network infrastructure

The outcome of the Identify phase will be to determine the high-level requirements for your Server and Domain Isolation Design. In the Evaluate and Plan phase, we will establish detailed requirements and an execution plan. For more information, see the Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 4: Designing and Planning Isolation Groups.

Phase 3: Evaluate and Plan

The goal of the Evaluate and Plan phase is to ensure that all options have been considered for securing and guaranteeing verified communication between servers. In this case, we are focusing on IPsec as the mechanism to do this; there is an additional related requirement for centrally managed certificate services at the Rationalized level in the Core infrastructure Optimization Model.

In order to generate an executable plan for the Deploy phase, we provide instructions for implementation of the server and domain isolation design.

Evaluating Internet Protocol Security

IPsec is typically used to protect the communication channel between two servers and restrict the computers that can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer, such as an application server or a Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.

The networking requirements and recommendations for a server farm make IPsec a good option because:

• All servers are contained on one physical LAN (to improve IPsec performance).

• Servers are assigned static IP addresses.

IPsec can also be used between trusted Windows Server 2003 or Microsoft Windows 2000 Server domains. For example, you can use IPsec to secure communication of a Web server or application server in a perimeter network that connects to a computer running Microsoft SQL Server on an internal network. For more information, see Selecting IPsec Authentication Methods in the Windows Server 2003 Deployment Guide.

For more information about recommended environments for IPsec, see Determining Your IPsec Needs in the Windows Server 2003 Deployment Guide.

Planning for Server and Domain Isolation

During the Identify phase, we created high-level requirements. The next step is to create an implementation plan using Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 4: Designing and Planning Isolation Groups. After a plan has been created and detailed requirements defined, a combination of the following elements will implement these requirements:

Inbound and outbound access requirements for the isolation domain and isolation groups:

• Internet Protocol security (IPsec) policy designed specifically for the isolation group that requires IPsec Internet Key Exchange (IKE) negotiation for inbound and outbound connections.

• Domain-based security groups called network access groups to allow or deny network access when using IPsec-protected traffic.  

Network traffic protection requirements for the isolation domain and isolation groups:

• IPsec policy filters designed to properly identify which traffic should be secured.

• IPsec filter actions that negotiate the required level of authentication and encryption for the traffic that the filters identify.

• IPsec filter action settings to control whether plaintext communication is allowed when trusted hosts initiate outbound connections.

Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 5: Creating IPsec Policies for Isolation Groups discusses the preparation of the solution using Group Policy and IPsec policies in Active Directory using Windows Server 2003, and configuration of domain members using Windows Server 2003 and Microsoft Windows XP.

Phase 4: Deploy

The goal of the Deploy phase is to implement what has been planned as a result of the previous three phases. In this phase you will create IPsec policies in Active Directory, including the creation of filter lists, filter actions, and IPsec policies to implement isolation groups. The following figure depicts the various components of an IPsec policy and how they are associated with each other.

Figure 9. IPsec policy components

For detailed implementation guidance of IPsec policies, read Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 5: Creating IPsec Policies for Isolation Groups.

Further Information

For more information on IPsec, visit Microsoft TechNet and search for “IPsec.”

To see how Microsoft secures communications between servers, go to https://www.microsoft.com/technet/itshowcase/content/ipsecdomisolwp.mspx.

Checkpoint: Secured and Guaranteed Communication Verification Between Servers

	Requirements
	Assessed the current state of network infrastructure affected by Internet Protocol Security (IPsec).
	Identified organizational requirements to ensure secured and guaranteed communication between servers, including regulation and compliance impacts.
	Developed and implemented a plan across the organization using IPsec to meet defined requirements.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Secured and Guaranteed Communication Verification Between Servers capabilities of the Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources for communication between servers.

Go to the next Self-Assessment question.

Requirement: Service Level Agreement Monitoring and Reporting for Servers

Audience

You should read this section if you do not have a service level agreement (SLA) for monitoring and service level reporting for 80 percent or more of your servers.

Overview

Managing IT using a service management approach is becoming more prevalent in today’s IT industry. As organizations work to stay competitive and meet the needs of their internal and external consumers, they find it necessary to view their IT infrastructures as more than a collection of servers connected through wide area networks (WANs) and running applications You and your organization need to view these resources as services that generate revenue and provide capabilities for your consumers. When you take this approach, you need to understand all of the components making up the services and each component’s impact on the level of availability that the service provides. In addition, you must successfully measure your service delivery over time to clearly understand the quality of service that your systems are providing.

The Core Infrastructure Optimization Resource Guide for Implementers: Basic to Standardized guide discussed the requirement of having an automated way of monitoring critical servers in your organization at the Standardized level. At the Rationalized level, we are simply extending the requirement to all servers in the organization and attaching the service level management requirements as part of the monitoring requirement. The Rationalized level does not require a minimum bar for availability; this is determined as appropriate for each IT service in the organization.

Phase 1: Assess

As with the Standardized level, in the Assess phase your organization should take an inventory of all servers in your organization’s infrastructure. You can manually identify the servers and specifications or use a tool to automate the inventory process, such as the Systems Management Server (SMS) 2003 inventory collection features.

Additional deliverables for moving to the rationalized level are:

• Determining the primary IT services in your organization (service catalog).

• Assigning the infrastructure components necessary for delivering these services.

• Collecting information to determine a baseline current service level.

Establishing Service Level Baselines

A baseline is a line drawn in time, taking a “snapshot” of the situation. In this instance, it is a picture of the service level management within the organization. A baseline provides a picture of the services being delivered at that specific time and provides a plan for achieving future goals in service level management. Optimizing IT performance requires not only a clear vision of the objective, but also of the current baseline from which the process will begin.

For more guidance on assessing service level baselines, read the Microsoft Operations Framework (MOF) Service Level Management guidance.

Phase 2: Identify

After all servers have been inventoried, the Identify phase at the Rationalized level is the process when appropriate services levels are defined against your baselines. The main goal of service level management is to improve the services available to the business in the long term and to resolve service provision issues that currently exist.

Among the many benefits to the IT department, in addition to the improvement of service, is an increased knowledge of business expectations and improved cost management. Service level management allows the IT department to meet business expectations and opens a dialog to confirm these expectations. For example, an IT department may want to deliver a service at a 100 percent, 99.999 percent, or even 70 percent availability, but it may not be able to explain how it arrived at this number. Unless this expectation is documented and agreed on early in the service level management process, the IT department might focus on a non-business–critical service—for example, developing staff, investing in hardware, software, and other costly endeavors—with little real benefit to the business.

Service Level Objectives

When setting service level objectives, measure what the business is asking for. Often this can include process measurements—for example, rating customer satisfaction, returning phone calls, and responses to queries. There may be ways in which existing technology within the organization can be used to assist in these measurements. For example, call-center technology can run reports that are collated against calls logged at the service desk registering outgoing calls by individuals.

There are often complex component chains that result in the delivery of a service. It is possible, however, to agree on a final objective for the service as long as the service delivery of this objective can be measured over the end-to-end chain of components.

Common Measures for Service Level Objectives

Measure	Example
Availability	Days and hours the service is available or a % figure based on this.
Responsiveness and performance	Speed and volume (throughput or workload measures) of service, time to acquire data, speed of data transfer and response time, and technical and human speed of response.
Security	The security of the service.

The measures for the service level objectives should be carefully considered using the following criteria:

• Do they support the business objectives?

• Are they specific?

• Can they be measured?

• Are they attainable, even if this requires significant effort on the part of IT?

• Are they realistic in relation to the benefit they will bring to the business?

Phase 3: Evaluate and Plan

With all services defined in a service catalog and desired service levels defined, in the Evaluate and Plan phase we will evaluate technologies to automate monitoring of the components present in the IT service.

Monitoring Software

This section illustrates how software can be used to monitor the availability of critical servers. In this example, Microsoft Operations Manager (MOM) is used in the monitoring role. Whether using MOM or not, software for monitoring availability or other service level measures of servers should have the following functionality:

• Ability to gather server attribute information and to apply specific rules to monitor them, based on their attributes.

• Ability to obtain data from event logs and other providers, as defined by specific rules.

• Ability to collect performance data based on performance counters.

• Ability to generate alerts based on criteria specified in rules.

Depending on the measures defined in your organization’s service level agreements, MOM may be used as the sole technology for collecting data. In most cases, MOM data will need to be augmented with data from other services; for example, if you have defined service levels as part of change and release management, you will need to use status reports from other mechanisms like Systems Management Server 2003 reporting.  

System Center Operations Manager 2007 is in the process of being released at the time of this publication. As the next version of an operations management solution from Microsoft, it adds features for service-oriented health monitoring, client monitoring, and domain services monitoring.   

MOM Availability Management Pack

With the MOM Availability Management Pack you can collect and analyze data from the event logs of your servers and then generate configurable reports that you can view and customize to suit the needs of your organization. You can use these reports to identify the causes for planned and unplanned downtime and take preemptive actions to decrease downtime in the future.

You can use the availability reports to:

• Determine whether your servers are meeting their availability and reliability objectives.

• Filter reports to track trends by viewing information collected over a specific length of time, such as over a period of months or years.

• Identify the best and worst performing computers for a particular area.

• Identify problem areas, such as a particular application or operating system version that stops responding.

• View and analyze information gathered using Shutdown Event Tracker.

The MOM Availability Management Pack can be an invaluable tool that you can use to facilitate key monitoring measures in your service level management and move to the Rationalized level. For more information on the MOM Availability Management Pack, go to https://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e1dfa65-84a5-4e3e-9403-3ef9b47c6b68.mspx?mfr=true.

Planning for Microsoft Operations Manager Deployment

If you have selected Microsoft Operations Manager as the monitoring technology for your servers and it has not already been deployed in your environment, see the MOM 2005 Deployment Planning Guide as part of the Microsoft TechNet Operations Manager TechCenter.

System Center Operations Manager 2007

System Center Operations Manager 2007 offers a service-oriented monitoring approach that enables you to monitor your end-to-end information technology services, scale monitoring across large environments and organizations, and use Microsoft application and operating system knowledge to resolve operational problems. Following are some of the rich capabilities that Operations Manager 2007 provides.

Service-oriented Monitoring

A consolidated Operations Console displays the health of your environment and allows you to handle alerts. For additional information about the Operations Console, see Operations Console in Operations Manager 2007.

Reports provide multiple ways to view of the health of your environment. For additional information about reporting, see Reporting in Operations Manager 2007.

Built-in Management Packs

Out-of-the-box Management Packs provide monitoring information for many Microsoft applications. In addition, you can create your own Management Packs to monitor your custom applications. For additional information about Management Packs, see Management Packs in Operations Manager 2007.

Most Microsoft Management Packs include information about how to resolve common problems with the application.

Client Monitoring

Client Monitoring enables you to forward error reports for operating systems and applications to Microsoft and receive solutions for those errors, as available. For additional information, see Client Monitoring in Operations Manager 2007.

Active Directory Domain Services

Active Directory Domain Services Integration uses prior investments by allowing you to assign agent-managed computers to Management Groups. For additional information about Active Directory Domain Services, see Active Directory Domain Services Integration in Operations Manager 2007.

Secured Monitoring Environment

Security features allow you to monitor the health of information technology services and applications even when parts of the environment are outside your secured area. For additional information about security features, see Security Considerations in Operations Manager 2007 and Operations Manager 2007 Gateway Server.

Role-based authorization allows you to tailor the actions your operators and administrators can take. For additional information about roles, see About User Roles in Operations Manager 2007.

Audit collection efficiently collects security events from managed computers and provides reports for analysis. For additional information about audit collection, see Audit Collection Services (ACS).

Further Information

For more information about System Center Operations Manager 2007, visit http:/www.microsoft.com/technet/opsmgr/opsmgr2007_default.mspx.

Phase 4: Deploy

After you have defined the IT services in a service catalog, determined the baseline or current service levels, defined service levels appropriate for your organization, and determined a plan for automating service level monitoring, it is time to implement the availability monitoring solution.

If your organization has selected Microsoft Operations Manager as the technology to perform availability monitoring of your systems, detailed deployment guidance can be found in the MOM 2005 Deployment Guide and System Center Operations Manager 2007 Deployment Guide at Microsoft TechNet.  

Further Information

For more information, go to Microsoft TechNet and search for “SLA.”

• For more information on monitoring server availability with MOM 2005, go to https://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/faf19f47-facd-4467-9510-e7c84c671572.mspx?mfr=true.

• For information on additional functionality to optimize server monitoring using MOM 2005, see Solution Accelerator content.

• Notification Workflow. Notification Workflow is a Microsoft SQL Server-based notification services application that can be used to extend notification functionalities of MOM 2005.

• Autoticketing. Autoticketing provides guidance for automated ticket generation, enabling the automated posting of a request (or ticket) into the Trouble Ticketing (TT) system used for incident management.

• Alert Tuning Solution. Alert Tuning helps reduce the volume of alerts when deploying MOM 2005 management packs.

• Service Continuity. Service Continuity helps maintain the availability of MOM 2005 service.

• Multiple Management Group Rollup. Multiple Management Group Rollup allows a business to propagate data from multiple management groups into one data warehouse to create consolidated and aggregated reports.

• To see how Microsoft monitors Exchange Server 2003, go to https://www.microsoft.com/technet/itshowcase/content/monittsb.mspx.

• To see how Microsoft uses service level agreements, go to https://www.microsoft.com/technet/itshowcase/content/itscorecdnote.mspx.

Checkpoint: Service Level Agreement Monitoring and Reporting for Servers

	Requirements
	Defined your organization’s IT services in a service catalog.
	Determined the baseline or current service levels for defined services.
	Defined service levels appropriate for your organization and determined a plan for automating service level monitoring.
	Implemented an automated availability monitoring solution.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for SLA Monitoring and Reporting for Servers capabilities of the Core Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources for establishing and monitoring server SLAs in Microsoft Operations Framework.

Go to the next Self-Assessment question.

Requirement: Secure Communication Mechanism for Presence

Audience

You should read this section if you do not provide a secured communication mechanism, such as Session Initiation Protocol (SIP), for presence.

Overview

Presence is real-time information that describes a particular user’s location and availability to communicate. Establishing enterprise-wide presence can provide a significant increase in productivity. Collaboration and communication between workers is more efficient when the tracking time is reduced.

Online presence gives individuals the ability to identify who is online and available to communicate with them at any given moment. Enabling online presence (and installing the required software) adds an online status indicator next to an individual's name wherever his or her name appears in a site collection. The online status indicator shows whether the individual is offline or is online and available to respond to queries via an instant messaging client. When an individual is online, you can click the online status indicator to send an instant message. This direct access to knowledgeable sources can help team members work more effectively and efficiently.

You can take steps to provide secure communications for presence information. Instant messaging systems can provide secure communications between user objects in your directory. By providing technology like Session Initiation Protocol (SIP) for presence communications, you can move from the Standardized level to the Rationalized level. The Rationalized level requires that communication via SIP is also secure; this means that the communication is archived, operated through the directory service, and certificates are used.

To find out more about the business value of presence, download the Live Communications Server 2005 Document: Business Value of Presence document.

Phase 1: Assess

During the Assess phase we will examine how users in your organization are currently identifying the presence of other users. Many organizations use instant messaging technologies offered by Internet service providers. While enabling online presence is beneficial in many environments where collaboration is critical, it is important to balance the benefits of increased collaboration among group members with the requirements for security and compliance, particularly in regard to the deployment of an instant messaging client. Planning for presence should include assurance that both internal and external communications to and from the instant messaging client are consistent with company-wide policy for security and compliance with regulatory guidelines and business practices. In many organizations, instant messaging conversations must be retained in accordance with record-keeping requirements for electronic communications. For example, organizations subject to Sarbanes-Oxley regulation must archive instant messaging conversations as a part of their records-retention requirements.

The primary deliverable for the Assess phase is to take an inventory of software applications currently used in your organization to enable presence and instant messaging. In highly locked-down environments, your users may be policy-restricted from installing applications; nonetheless, it is still recommended that you take an inventory of all systems. You can centrally inventory your environment with tools such as Systems Management Server 2003 or the Application Compatibility Toolkit (ACT).

Phase 2: Identify

During the Identify phase, you will begin to gather the high-level requirements for enabling presence in accordance with regulations or organizational policies. As stated above, for many organizations it is imperative to archive instant messaging conversations in-house. Additionally, you will want to investigate the extent to which presence indicators are integrated into other productivity applications, such as e-mail and collaboration software. The requirements specification resulting from the Identify phase will be used when evaluating and planning for presence in the following phases.

For information how presence is used with Microsoft Office SharePoint® Server, see http://technet2.microsoft.com/Office/en-us/library/3f53f3d3-85b8-42e5-8213-afb5eec7e8651033.mspx.

For information on integrating presence functionality with Microsoft Office Outlook, see http://technet2.microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx.

Phase 3: Evaluate and Plan

During the Evaluate and Plan phase, you will examine the technologies specific to enabling presence in your environment. The following sections highlight the protocol and list some of the Microsoft technology possibilities to enable presence.

Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP), which is similar to HyperText Transfer Protocol (HTTP), is a text-based application-layer signaling and call control protocol. SIP is used to create, modify, and terminate SIP sessions. It supports both unicast and multicast communication. Because SIP is text-based, implementation, development, and debugging are easier than with H.323. Using SIP, one user can explicitly invite another to join a conversation or multimedia session. A SIP session begins when the second user accepts the invitation. SIP also supports inviting additional users to an already established session.

To learn more about real-time communication protocols, go to https://www.microsoft.com/technet/prodtechnol/winxppro/plan/rtcprot.mspx.

Live Communications Server

Live Communications Server 2005 delivers instant messaging (IM) and presence as part of a scalable, enterprise-grade solution offering enhanced security, seamless integration with other Microsoft products, and an extensible, industry-standard development platform. Microsoft Office Live Communications Server 2005 can provide the following secure communication and collaboration tools and features utilizing SIP for presence:

• Instant messaging

• Audio and video communication

• Data collaboration

Visit the Microsoft Office Live Communications Server TechCenter to find planning, deployment, and operations information for Microsoft Office Live Communications Server.

Office Communicator 2005 and Office Communicator 2007

Office Communicator 2005 and Office Communicator 2007 are secure enterprise messaging clients that integrate instant messaging with telephony and video for unified instant messaging. Office Communicator 2007 provides integration capabilities with programs across the 2007 Microsoft Office system—including Microsoft Word, Excel®, PowerPoint, OneNote, Groove, and SharePoint Server.

For more information about Office Communicator 2005, see the Office Communicator 2005 Resource Center.

For more information about Office Communicator 2007, see Microsoft Office Communicator 2007 product overview.

Office Outlook 2007

If your organization is using Microsoft Office Outlook 2007, you can enable presence as part of the contact details information for users in your global address list. When configured, presence is also displayed in received e-mail messages. Office Outlook 2007 can be integrated with Office Communicator 2005 or Office Communicator 2007.

For more information about configuring Office Outlook 2007 to enable presence, see http://technet2.microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx.

Office SharePoint Server 2007

If your organization is using Microsoft Office SharePoint Server 2007, online presence can be enabled for individuals who have access to the SharePoint site to see which other participants are online and to send instant messages to them. Online presence can be a powerful collaboration tool that helps site members to quickly find out who is available to answer questions.

For more information about planning for presence integration in Office SharePoint Server 2007, see the Planning and architecture for Office SharePoint Server 2007 guide,

Planning for Presence and Managed Instant Messaging Infrastructure

Once you have evaluated the technologies to enable presence in your organization, the next task is to plan and architect the selected infrastructure. To enable integrated presence within your organization, you will typically require the following:

• Directory service

• Global catalog

• DNS deployed and correctly configured

• Public Key (PKI) and certification authority (CA) infrastructures

• Backend database

By reaching the Rationalized level, these component requirements will typically already be in place in your organization. The following diagram provides sample architecture for Live Communications Server 2005 Enterprise Edition infrastructure.

Figure 10. Live Communications Server Enterprise Edition infrastructure

The final deliverable of the Evaluate and Plan phase is a deployment plan and architectural design for your selected presence infrastructure. For more information about planning for presence using Microsoft technology, see the Microsoft Office Live Communications Server 2005 with Service Pack 1 Planning Guide.

Phase 4: Deploy

By now the previous phases have derived an inventory of the current practices used for enabling instant messaging and presence, a high-level requirements specification for implementing presence and managed instant messaging, evaluation of presence and instant messaging technology, and a deployment plan for the selected solution. In the Deploy phase, we will implement the selected presence solution. Ancillary to the deployment of new technology, you will also want to examine policies used to manage existing or unmanaged instant messaging; this may include implementing policy restrictions for sending or receiving files, blocking the installation of new applications, or uninstalling unmanaged applications not meeting defined policy guidelines appropriate for your organization.

If you have selected Live Communications Server 2005, you can find detailed deployment planning and execution information in the Microsoft Office Live Communications Server 2005 with Service Pack 1 Planning Guide on Microsoft TechNet.  

Further Information

For more information, visit Microsoft TechNet and search for “presence.”

To see how Microsoft uses Microsoft Office Live Communications Server 2005, go to https://www.microsoft.com/technet/itshowcase/content/lcs2005twp.mspx.

Checkpoint: Secure Communication Mechanism for Presence

	Requirements
	Assessed any current unmanaged methods used for presence and instant communication.
	Created a requirements specification for presence and instant messaging, aligning to industry or local regulations and policies.
	Evaluated presence and instant technology and created plan to implement your selected solution.
	Implemented presence at minimum through managed instant messaging and optionally through collaboration and e-mail infrastructure.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Secure Communication Mechanism for Presence capabilities of the Infrastructure Optimization Model.  

Go to the next Self-Assessment question.

Requirement: Active Directory and IAS/RADIUS for Wireless Network Authentication and Authorization

Audience

You should read this section if you have not deployed a secure wireless network using Active Directory and IAS/RADIUS for authentication and authorization.

Overview

Wireless technology releases us from copper wires. A user can have a notebook computer, PDA, Pocket PC, Tablet PC, or just a cell phone and stay online anywhere a wireless signal is available. The basic theory behind wireless technology is that signals can be carried by electromagnetic waves that are then transmitted to a signal receiver. But to make two wireless devices understand each other, we need protocols for communication. Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol where RADIUS clients send authentication and accounting requests to a RADIUS server. The RADIUS server checks the remote access authentication credentials on the user accounts and logs remote access accounting events.

Internet Authentication Service (IAS) in Windows Server 2003 or Network Policy Server (NPS) in the future with Windows Server Code Name “Longhorn” are Microsoft implementations of a RADIUS server and proxy. As a RADIUS server, IAS performs centralized connection authentication, authorization, and accounting for many types of network access including wireless, authenticating switch, and remote access dial-up and virtual private network (VPN) connections. As a RADIUS proxy, IAS forwards authentication and accounting messages to other RADIUS servers. RADIUS is an Internet Engineering Task Force (IETF) standard.

Phase 1: Assess

You read in previous sections of this guide and in the Core Infrastructure Optimization Resource Guide for Implementers: Basic to Standardized about the importance of authenticating users for access to your IT environment. To move to the Rationalized level, you need to take the next step by expanding authentication and authorization to users independently of their method of accessing your network.

The Assess phase will again take an inventory of any existing wireless infrastructure in place in your organization. Many organizations already have wireless networking capabilities in place and there are three common types of wireless networking technologies:

• Wireless local area networks (WLAN)

• Wireless personal area networks (WPAN)

• Wireless wide area networks (WWAN)

The following sections explain each of these network types and available wireless technologies; the Core Infrastructure Optimization Model focuses on WLAN as the only type of wireless network where your organization can actively control user or object authentication.

Wireless Local Area Networks (WLAN)

WLAN technologies enable wireless network connections within a private area, such as a company office or building, or in a public area such as an airport or shop. WLANs are generally used to supplement an existing wired LAN environment, providing an extra level of flexibility for the WLAN users, usually at the cost of network speed and connection reliability.

Wireless Personal Area Networks (WPAN)

WPAN technologies are designed to allow users to establish as needed wireless communications between personal devices such as PDAs, cellular phones, or laptops. Generally these devices are designed to communicate in an area of a few meters, an area referred to as a personal operating space (POS).

Wireless Wide Area Networks (WWAN)

WWAN technologies are designed to enable wireless connections over public or private networks that are distributed over large geographical areas, such as cities or countries.

The result of the Assess phase will be documentation of existing WLAN topologies in use at your organization. This topology will be used in the Evaluate and Plan phase while planning for ways to optimize secured user authentication.

Phase 2: Identify

The Identify phase concentrates primarily on identifying a secure means of authenticating WLAN-connected devices in an effort to mirror the level of security used in your wired LAN infrastructure. This section introduces the following technologies and protocols used to provide a secure wireless networking infrastructure:

• Wireless authentication using IEEE 802.11

• Remote Authentication Dial-In User Service (RADIUS)

• Extensible Authentication Protocol (EAP)

• Internet Authentication Service (IAS)

• Certificates

For detailed technical guidance about wireless protocols and authentication, see the Wireless Deployment Technology and Component Overview.

Wireless Authentication Using IEEE 802.11

The Institute of Electrical and Electronics Engineers, Inc. (IEEE) 802.11 is an industry standard for a shared access WLAN that defines the Physical layer and media access control (MAC) sublayer for wireless communications. The original IEEE 802.11 standard defined the following types of authentication, which are described in the following sections.

Open System Authentication

Open system authentication does not provide authentication, only identification using the wireless adapter's MAC address. Open system authentication is used when no authentication is required. Open system authentication is the default authentication algorithm that uses the following process:

1. The authentication-initiating wireless client sends an IEEE 802.11 authentication management frame that contains its identity.

2. The receiving wireless node checks the initiating station's identity and sends back an authentication verification frame.

With some wireless APs, you can configure the MAC addresses of allowed wireless clients using a feature known as MAC filtering. However, MAC filtering does not provide any security because the MAC address of a wireless client can be easily determined and spoofed.

Shared Key Authentication

Shared key authentication verifies that an authentication-initiating station has knowledge of a shared secret. According to the original 802.11 standard, the shared secret is delivered to the participating wireless clients by means of a secure channel that is independent of IEEE 802.11. In practice, the shared secret is manually configured on the wireless AP and the wireless client.

Shared key authentication uses the following process:

1. The authentication-initiating wireless client sends a frame consisting of an identity assertion and a request for authentication.

2. The authenticating wireless node responds to the authentication-initiating wireless node with challenge text.

3. The authentication-initiating wireless node replies to the authenticating wireless node with the challenge text that is encrypted using WEP and an encryption key that is derived from the shared key authentication secret.

4. The authentication result is positive if the authenticating wireless node determines that the decrypted challenge text matches the challenge text originally sent in the second frame. The authenticating wireless node sends the authentication result.

Because the shared key authentication secret must be manually distributed and typed, this method of authentication does not scale appropriately in large infrastructure network mode (for example, corporate campuses and public places).

Remote Authentication Dial-In User Service (RADIUS)

RADIUS is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access. Originally developed for dial-up remote access, RADIUS is now supported by wireless APs, authenticating Ethernet switches, virtual private network (VPN) servers, Digital Subscriber Line (DSL) access servers, and other network access servers.

Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP) was originally created as an extension to Point-to-Point Protocol (PPP) that allows for development of arbitrary network access authentication methods. With PPP authentication protocols such as Challenge-Handshake Authentication Protocol (CHAP), a specific authentication mechanism is chosen during the link establishment phase. During the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order. With EAP, the specific authentication mechanism is not chosen during the link establishment phase of the PPP connection. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. When the connection authentication phase is reached, the peers negotiate the use of a specific EAP authentication scheme known as an EAP type.

Internet Authentication Service (IAS)

IAS in Windows Server 2003 and Windows 2000 Server is the Microsoft implementation of a RADIUS server and for Windows Server 2003, the Microsoft implementation of a RADIUS proxy. IAS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and router-to-router connections. IAS enables the use of a heterogeneous set of wireless, switch, remote access, or VPN equipment and can be used with the Windows Server 2003 or Windows 2000 Server Routing and Remote Access service.

When an IAS server is a member of an Active Directory-based domain, IAS uses Active Directory as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network) and to log on to an Active Directory-based domain.

Certificates

Certificates are used to authenticate a wireless client with a wireless access point. Wireless clients running Windows Vista, Windows XP, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 Server can use certificates to authenticate the computer.

Identify Phase Summary

The Identify phase for this requirement differs from others in that it contains many of the aspects used for evaluating technology options for wireless networking. This is partly the case because the protocols and standards used are consistent for nearly all wireless networking technologies. An understanding of the standards and protocols is necessary to identify your desired outcome, or requirement specification, for secure wireless authentication. For more information, see the Wireless Deployment Technology and Component Overview and Wireless Networking Security guides on Microsoft TechNet.

Phase 3: Evaluate and Plan

Now that you have identified the technologies and protocols required to wireless network security and developed a high-level requirements specification, the Evaluate and Plan phase will evaluate technologies that can be used to plan and implement your wireless network deployment project.

Assuming that other requirements of the Rationalized level have been fulfilled, many of the components necessary for implementing a secure wireless infrastructure are probably in place, including Windows XP SP2 or newer client computers and Windows 2000 Server or newer servers.

Windows Server IAS

Windows Server IAS provides the following solutions for organizations that require secure network access:

• Compatibility with RADIUS servers and clients from any vendor that meets the IEEE specifications outlined in RFCs 2865, 2866, and 2869.

• Integration with the Active Directory directory service. IAS allows you to take advantage of Active Directory for user authentication, authorization, and client configuration, thus reducing management costs.

• Use of standards-based strong authentication methods for network access.

• Management of network access that is outsourced to an ISP. IAS allows you to create an agreement between your organization and the ISP in which the ISP can charge a roaming user’s department for that employee’s network usage. In this way, each employee does not need to submit an expense statement or create a roaming account to connect to the corporate network remotely.

• Dynamic key management for wireless access points as a means to increase network security.

Servers running the Internet Authentication Service (IAS) component of the Windows 2000 Server and Windows Server 2003 operating systems perform centralized authentication, authorization, auditing, and accounting for many types of network access, including dial-up, virtual private network (VPN), wireless, and 802.1x authenticating switch access. IAS is the Microsoft implementation of the Remote Authentication Dial-In User Service (RADIUS) protocol.

For more information, see the Windows Server 2003 Security Guide.

Active Directory

When you implement your IAS server as a member of an Active Directory domain, IAS uses the Active Directory directory service as its user account database and is part of a single sign-on solution. With single sign-on, users supply account credentials (user name and password or a certificate) only once during the authentication and authorization process; these credentials are then used to log on to an Active Directory domain and for network access control (authenticating and authorizing access to a network).

Planning a Secure Wireless Network

There are two primary wireless security architectures using Microsoft technologies. The first method uses an IPsec VPN, while the second uses the 802.1x Extensible Authentication Protocol (EAP). The purpose of both is to guarantee the user authentication and authorization and to protect the data's confidentiality and integrity.

IPsec VPN Authentication

The basic structure of IPsec VPN is that the wireless clients connect to the open wireless access point (AP) and then authenticate with the IPsec VPN for access to the organization's protected intranet.

802.1x Authentication Using EAP

802.1x with EAP-TLS and machine certificates can be used to authenticate both the wireless clients and the server. It also manages the WEP key by periodically and automatically sending a new key, thereby avoiding some of the known WEP key vulnerabilities. The data confidentiality will be protected by these dynamic WEP keys.

When creating your plan for implementation, you can use either method. For more information, see the Wireless Networking Security guides on Microsoft TechNet.

Also see Securing Wireless LANs with PEAP and Passwords and Securing Wireless LANs with Certificate Services guides on Microsoft TechNet.

Phase 4: Deploy

The final step in the process is to deploy protected wireless access in your organization. If you have selected the 802.1x authentication method using Windows technologies, detailed step-by-step deployment guidance can be found in the Deployment of Protected 802.11 Networks Using Microsoft Windows Guide.

Further Information

For more information on Active Directory and IAS/RADIUS, go to the following Web sites:

• http://technet2.microsoft.com/WindowsServer/en/library/55f10dbe-c5d8-497e-8bd1-f0d6d8019ee41033.mspx?mfr=true

• https://www.microsoft.com/technet/security/midsizebusiness/topics/serversecurity/wirelessaccessconfig.mspx

• https://www.microsoft.com/technet/isa/2006/authentication.mspx

You can also visit Microsoft TechNet and search for “IAS” or “RADIUS.”

To see how Microsoft uses IAS, go to https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx.

Checkpoint: Active Directory and IAS/RADIUS for Wireless Network Authentication and Authorization

	Requirements
	Identified current wireless access and related topologies.
	Evaluated wireless technologies, protocols, and standards.
	Developed and implemented plans for secure wireless authentication infrastructure.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Active Directory and IAS/RADIUS for Wireless Authentication and Authorization capabilities of the Core Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources in the Wireless Resources for Windows XP on Microsoft TechNet.

Go to the next Self-Assessment question.

Requirement: Centrally Managed Certificate Services

Audience

You should read this section if you do not have a centrally managed Certificate Services infrastructure or Public Key Infrastructure (PKI).

Overview

Computer networks are no longer closed systems where the mere presence of a user can serve as a sufficient proof of identity. In this age of information interconnection, the network of an organization may consist of intranets, Internet sites, and extranets, all of which are susceptible to intrusion by individuals with malicious intent seeking a variety of data files, from e-mail messages to e-commerce transactions. To mitigate the risks incurred by this susceptibility, mechanisms for establishing and sustaining a user's identity are required. A centrally managed, electronic identity for users can provide the following:

• Accessibility of information. Information assets need to be accessible to authorized users and protected from unauthorized access or modification. Passwords can help, but users who have several passwords for accessing different secure systems may choose passwords that are easy to remember and consequently easy to decipher.

• Non-repudiation of identity. Information needs to be sent from one user to another with the confidence that the sender of the information is valid. It is also necessary to provide reasonable confidence that the information has not been changed en route.

• Privacy of information. Users should be able to send information to other users or to access a computer system with confidence that the information cannot be accessed or be made available to others. It should be possible for the user or system to define who can access the information. Privacy is of particular importance when information is transmitted over the public Internet.

These requirements deal with electronic information assets and have a direct impact on most organizations. Any mechanism that is implemented to deal with these requirements must be both manageable and secure. A public key infrastructure (PKI) is an appropriate technology to fulfill these requirements with the use of digital certificates. PKI enables the exchange of digital certificates between authenticated entities and trusted resources. Certificates in a PKI are used to secure data and manage the identification credentials of resources within and outside the organization. Clearly, PKI itself needs to be trusted; therefore, it is managed by a pre-qualified organization or part of such organization. Such an organization can be called a certification authority (CA), but usually just the computer that runs the certificate software is called a CA. Whether the CA refers to an organization or to the software that supports certification, the CA is responsible for establishing and vouching for the identity of certificate holders. It may also revoke certificates if they should no longer be considered valid and publish certificate revocation lists (CRLs) for use by certificate verifiers to determine the validity of a certificate.

This guide uses best practices as documented by the Windows Server System Reference Architecture Certificate Services guides.

Phase 1: Assess

The Assess phase looks at the current state of the network environment. This Assess phase is identical to the Assess phase in the requirement for Secured and Guaranteed Communication Verification Between Servers at the Rationalized level. The process of obtaining and maintaining a reliable record of an organization's computers, software, and network devices is a classic IT challenge. Information about the following items is required to define the current state:

• Network discovery

• Documentation of network segmentation

• Network infrastructure devices

• Analysis of current network traffic model

• Active Directory

• Host discovery

• Host data requirements

For detailed information on how to gather this information, read the Server and Domain Isolation Using IPsec and Group Policy Guide Chapter 3: Determining the Current State of Your IT Infrastructure. This guide discusses the requirements for each item and how to collect information via automated discovery using SMS 2003 or similar products as well as manual discovery options.

Phase 2: Identify

The Identify phase defines the high-level need for establishing a centralized public key infrastructure. When an organization decides to implement a PKI, the business problem should be identified before the design phase starts. The design phase begins with identifying the considerations for people, processes, and technology. The questions that drive the PKI service requirement include the following:

People-related questions:

• How do people handle their certificates?

• Who is going to manage the certificates?

• How does a PKI affect a user’s working experience?

• What is the size of the organization?

Process-related questions:

• Should the PKI be part of the organization's IT infrastructure or should the certificates be bought from an outside source?

• Are certificates also used for external transactions?

• What process is applied to enroll certificates?

• How are trusts established and verified between the organization and related entities?

• At what intervals should a trust be verified?

• What constraints have an impact on the validity of certificates?

• How urgent is the revocation of associated certificates once a trust is canceled?

Technology-related questions:

• What are the types of entities that require certificates, and for what purposes?

• For what purposes is a directory service beneficial?

• What information needs to be included as part of the certificates?

• Which applications are PKI-enabled?

• How complex should a public/private key be, and can PKI-enabled applications support this complexity?

Before the first CA server is installed in an organization, a complete PKI service design study must exist that covers people, processes, and technology. In the long run, extending a poorly implemented PKI is more difficult and costlier to manage than spending time up front to plan for an extensible PKI. For more information about identifying the high-level requirements of the PKI, see the WSSRA Blueprint for Enterprise Design for Certificate Services.

Phase 3: Evaluate and Plan

In the Evaluate and Plan phase, we will examine PKI and plan the necessary steps for deploying the infrastructure.

What Is PKI?

Many of the technologies needed to implement a secure network require PKI, which enables the exchange of digital certificates between authenticated entities and trusted resources. Certificates in a PKI are used to secure data and manage the identification credentials of resources within and outside the organization. When a PKI is in place, any permitted subject is allowed to request certificates from a certificate enrollment service that is managed by the CA. The CA determines the validity of the certificate requester and issues a valid certificate in response to the request. The certificate holder can use the certificate until it expires or until it is revoked; the trustworthiness of a certificate depends on the quality of trust between a certificate requester and the issuing CA. Two user certificates issued by two different CAs will, by default, have no trusted status between each other. A common trust between the issuing CAs is required to ensure that the certificates can be mutually trusted.

PKI-enabled clients use certificates to determine the level of trust for a given resource. To ensure this, a PKI needs a verification mechanism to check a certificate’s validity. The Windows Server 2003 PKI provides CRLs as a verification mechanism, and clients are technically capable of retrieving a CRL through a number of protocols. Depending on the client capabilities and the network infrastructure, use of one protocol might be preferred over the others; examples of such protocols include:

• HTTP and Secure HTTP (HTTPS). HTTP and HTTPS are used when CRLs are published with a Web server. These protocols are commonly used to make CRLs accessible to entities outside the organization's network.

• LDAP. Accessing a CRL through LDAP from a directory service requires more bandwidth than retrieving the same CRL through HTTP because LDAP, by default, requires authentication. Even if anonymous access is used to retrieve the CRL, LDAP would send an anonymous authentication header. If a CRL needs to be available internally and externally, it can be difficult to provide directory access to all clients through LDAP.

PKI Architecture

The architecture of a PKI involves implementing various interdependent technologies and processes to make it possible to issue, validate, renew, and revoke certificates. These technologies include:

• One or more servers running certificate services that provide certificate enrollment, revocation, and other certificate management services.

• Active Directory directory service or another directory service that provides account management, policy distribution, and certificate publication services.

• Domain controllers that can authenticate end users and computers when they request certificates.

• Domain client computers and users who request, receive, and use certificates for specific purposes. Although certificates can also be used by services and by non-domain clients, in most Windows PKI environments, domain users and computers are the primary recipients and users of certificates. In some cases, the domain client can be a subordinate CA that requests and receives a certificate authorizing it to issue certificates of its own.

The following figure illustrates the architecture of PKI technologies.

Figure 11. PKI technologies architecture

This type of PKI implementation gives you centralized control over your certificate services.

Planning for CA Infrastructure and PKI Implementation

The options for a CA infrastructure depend on the security and certificate requirements of an organization, the purpose of the PKI, and the requirements of applications, users, and computers.

As described earlier, certificate requirements have a direct impact on your PKI design. Logical design of the PKI can be done once the PKI service has been defined. See the WSSRA Blueprint for Enterprise Design for Certificate Services for detailed technical guidance for planning your organization’s public key infrastructure.

Phase 4: Deploy

After your public key design has been validated and refined by lab testing and pilot programs, you can deploy the PKI in your production environment. A disciplined approach to deploying a PKI is essential for establishing the security of the applications that you are enabling. The following figure shows the high-level CA infrastructure and PKI deployment processes.

Figure 12. High-level CA infrastructure and PKI deployment processes

For detailed technical information on CA infrastructure and PKI deployment, see:

• Windows Server 2003 Technical Library: Designing a Public Key Infrastructure

• Windows Server 2003 Technical Library: Deploying the PKI

Further Information

For more information, visit Microsoft TechNet and search for “PKI.”

To see how Microsoft deploys PKI, go to https://www.microsoft.com/technet/itshowcase/content/deppkiin.mspx.

Checkpoint: Centrally Managed Certificate Services

	Requirements
	Performed a network discovery to inventory all components.
	Identified people, process, and technology design considerations for the certification authority and public key infrastructure.
	Created a detailed deployment plan to enable the PKI.
	Implemented PKI deployment plan.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Centrally Managed Certificate Services capabilities of the Core Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources for certificate services.

Go to the next Self-Assessment question.

Requirement: Proactively Managed Bandwidth to Branch Offices

Audience

You should read this section if you do not proactively manage bandwidth to branch offices.

Overview

When you must provide secure, safe, and efficient communication between your organization’s headquarters and branch offices, you face the issue of limited bandwidth over your wide area network (WAN). There are several things you can do to make the most efficient use of the bandwidth. The design of your physical network infrastructure has a significant impact on other services and components in your branch and hub site infrastructures. The performance and availability of the network determine whether a service can appropriately support user requirements for accessing services over a WAN.

This guide is based on published guidance in the Branch Office Infrastructure Solution for Microsoft Windows Server 2003 Release 2 (BOIS R2).

Phase 1: Assess

The following sections discuss the activities you should conduct during the Assess phase.

Documenting Network Design

The first step in determining how to optimize WAN bandwidth in your organization is to document your organization’s current network design for branch offices. There are two primary branch office network designs: single-hub and multi-hub.

Single-Hub Network

In a single-hub network, the hub site connects directly to multiple remote sites. This is a common WAN structure for organizations that have multiple branch offices, but the branch offices have almost identical business functions and operate within the borders of a single country or smaller region. The following figure shows a sample network structure with one hub site.

Figure 13. Single-hub network

Multi-Hub Network

The multi-hub network generally provides at least three tiers of network connections. This is a common structure for larger or international organizations that have many branch offices with diverse business functions. This WAN structure commonly has one central hub site for corporate headquarters and one hub site per geographic region. The following figure shows a sample network structure with one central hub site and two regional hub sites.

Figure 14. Multi-hub network

The multi-hub network may be further extended if branch offices are connected to other branch offices. In this case, it is important to determine the services to be available in second-tier sites. Options for the second-tier sites include the following:

• Have the same set of services available locally as the first-tier branch office.

• Have more services available locally (because of insufficient network availability, capacity, or performance).

• Have fewer services available locally and rely on the services provided by the hub site.

The first step of the Assess phase is to document your organization’s network design for your branch and hub infrastructure.

Documenting WAN Links

The next step in the Assess phase is to document the WAN links between all of your sites. The network link connecting the branch office to the hub site is a critical component of any WAN. The WAN link can significantly affect the availability of any services requiring access over the WAN. As part of the discovery process, you should determine the following information:

• Link type. This is a primary determinant of network speed, support for network loads, and network availability. Link type includes whether the connection is persistent (such as a leased line) or on-demand (such as dial-up and ISDN), as well as the protocols that it uses (such as virtual private networking or VPN, Frame Relay, or satellite).

• Link bandwidth. This is the theoretical maximum speed of the link, but the real speed is limited by network latency.

• Link latency. This is the time that it takes a network packet to get from one place to another, which constrains the minimum time (amount of delay) it requires for a transaction (round trip).

• Link capacity. This is the theoretical amount of aggregate data that can be pushed through a network link. It is closely tied to link speed.

• Link utilization. This is expressed as a percentage of total capacity for the link. Utilization includes all network traffic, including the background transactions required to monitor and manage the network and services, other individual services and applications that use the network, and specific functions that depend on the network (such as security cameras/systems and VoIP).

Network Segmentation in the Branch Office

The last stage is assessing network segmentation for the branch office and what is required to most appropriately support the services in the new solution.

The internal network in the branch office has traditionally been a single segment network, also known as a flat network. This type of network provides a simple and inexpensive infrastructure with a simple IP plan. If your organization’s branch offices incorporate single or multiple segment networks, these should be documented as part of the assessment.

Other Network Design Considerations

In addition to the network link, each branch office also requires a network infrastructure that supports all users in the branch office and their internal connectivity requirements. Additional design considerations related to the branch infrastructure and other network components include the following:

• Location of centralized services

• Local Internet access

• Security impacts

• Routing limitations

• Network Address Translation (NAT)

Assessment Summary

The outcome of this step should produce a detailed spreadsheet or topology diagram listing how all of these items correlate to the network design documented in the first step. For more information and other assessment considerations, see Physical Design in the BOIS R2 guide.

Phase 2: Identify

The goal of the Identify phase is to determine the level of performance appropriate for your organization’s needs. In most cases increasing performance will lead to increasing costs. In this phase it is important to weigh the costs and benefits of each performance level.

The diverse type and characteristics of WANs make it impossible to give specific recommendations about which WAN connections are most appropriate for your organization. However, based on customer data collected by various groups, it is possible to generalize three network link scenarios: high, medium, and low performance. The following list describes the characteristics of each of these performance scenarios and the potential applications for each:

• High performance. Satellite branch offices typically require high performance links, (at least 1.544 or 2 megabits per second or Mbps, depending on location), low latency, and high availability. These are typically found in North America and within country borders of many Western European and other countries. This type of network link may enable organizations to centralize more services into the hub site than the other scenarios simply because the reduction in management cost by moving services centrally can outweigh the cost of providing sufficient availability. Also, the capacity and latency can be good enough that they should not negatively affect end-user productivity. In some cases, productivity may actually improve because of application. For instance, applications that access a back-end store (such as a database or mainframe computer) in a hub site might benefit by being moved to application farms in a central site and by using Terminal Services to access them. The reason for this is that the most intensive transactions do not have to occur over the WAN, and the high-capacity WAN supports the level of performance that users require for access to the application.

• Medium performance. Accelerated branch offices can typically use medium performance links (128–512 kilobits per second or Kbps), medium latency, and good availability. These scenarios are typically found in geographic locations that do not have the more advanced telecommunication infrastructures or in situations that require crossing significant geographic boundaries. The link might support centralization of services with low bandwidth requirements (such as DNS and Active Directory), if they do not have configurations or other restrictions that prevent centralization. However, the availability of the network link might not be sufficient to ensure that the services left in the branch office (such as file and print services) can access any centralized services upon which they depend for name resolution, authentication, and authorization. Also, the latency of this link might not provide an acceptable user experience when using Terminal Services to access centralized applications.

• Low performance. Autonomous branch offices can usually function with lower performance links (such as those less than 128 Kbps) and high latency and are more tolerant of link unreliability. This scenario is typically found in areas of the world where the telecommunications industry is significantly under-developed or the cost of actually obtaining a higher performing and more available network link is cost prohibitive (such as when connecting a single branch office in a very remote location). Use of this type of link is not conducive to the centralization of services. But it simplifies the branch office design because all services that support the business-critical branch office functions and the services upon which they depend must be located locally in the branch office.

The result of the Identify phase should be a detailed analysis and recommendation of the desired performance outcomes for each connection, thereby determining how each branch office is classified: satellite, accelerated, or autonomous.

Phase 3: Evaluate and Plan

Until now, you have been documenting your network topology and desired performance needs for your branch office infrastructure. In the Evaluate and Plan phase, you will evaluate the impacts of centralizing versus localizing services and create a plan for managing your WAN links to meet your performance requirements.

Evaluating the Physical Server Design

Branch office infrastructure design is generally focused on centralizing as many services as possible. Although a long-term goal might be to centralize all services, this is seldom feasible for a short-term solution. The reason for this is that it can be cost-prohibitive to provide connectivity between the client computer in the branch office and the service in the hub site that has appropriate availability, capacity, and latency. If the state of current technologies does not support centralization of specific services, the intent of streamlining the branch design is usually to consolidate all services remaining in the branch office on a single server. This can also be challenging but is achievable in certain instances.

The types of design considerations that are not specific to a single service and that should be applied to all services include the following:

• The design options available for streamlining branch office infrastructures.

• Branch service placement considerations, including the general implications of service placement on people and processes, as well as on the business itself.

• Other design considerations, especially those related to users and business functionality, which are not specific to service placement.

Design Options for Branch Office Infrastructures

Defining branch office infrastructures requires analyzing the options for and implications of deploying services centrally and locally. The two basic decisions that you must make for each branch require evaluation of many design options.

Service Centralization Options

The primary options available for centralization of services include running the service:

• Only in the branch office (with no failover).

• In the branch office with failover to the hub site if it has replication capabilities.

• Only in the hub site.

Branch Server Design Options

You can still streamline services that cannot be centralized by service consolidation on one or more branch servers. The branch server design should focus on how to optimize the use of hardware, software, and support (including the use of personnel resources) in each branch office.

The Solution Accelerator for Consolidating and Migrating LOB Applications and the Mixed Workload Consolidation Guide provide detailed guidance for determining which applications can be consolidated. The Solution Accelerator for Consolidating and Migrating LOB Applications also provides guidance for identifying appropriate solutions for applications that are not good candidates for consolidation.

The following list summarizes the primary options for running applications at branch office sites:

• Single server consolidation

• Service consolidation

• Virtualized consolidation

• Dedicated server

The option that you choose for each service determines the number of branch servers required.

Branch Service Placement Considerations

Each organization has priorities that dictate which requirements are most significant and, thus, which ones will have the most impact on the design of the branch office infrastructure solution. As part of your earlier analysis efforts during the Envisioning phase of your project, you should have identified technical, business, and other requirements and limitations that affect the placement of services.

You will need this information to effectively evaluate the options and trade-offs for each branch service—both the general design considerations and the service-specific design considerations that the following list outlines:

• IT organization

• Political considerations

• Legal and regulatory considerations

• Security

• Availability and reliability, including:

  • Centralization of services

  • Consolidation and co-hosting services on a branch server

  • Non-redundant servers in the branch office

  • Branch service redundancy

  • Single server for local services, with local redundancy and Windows clustering for services  

• Backup and recovery

• Performance and capacity

• Scalability

• Cost

Planning for Branch Office Services

BOIS R2 introduced a new design technique that you can use to provide a common and repeatable approach to infrastructure service design in an organization, whether for branch offices or other IT services. This technique uses service design reference (SDR) diagrams and three fundamental design elements to illustrate the design process for each service. These elements are:

• Design stages

• Design considerations

• Design options

The following figure shows a generic version of a service design reference that is used to illustrate the elements of this design approach.

Figure 15. Generic version of a service design reference

At each design stage, you should use the considerations and options to determine whether the input design will meet the requirements of the new design and whether the model can be modified to match the new requirements as needed.

Detailed planning is required for the core branch office service to ensure that WAN bandwidth usage is optimized. These services are referred to as core services because they provide the basic infrastructure for a branch office environment that can then be enhanced or extended to increase the features of a solution. These core services are:

• Directory Service

• Network Addressing and Name Resolution Services

• File Services

• Print Services

• Core Client Services

• Core Management Services

See the Core Branch Service Design in BOIS R2 for detailed information about designing for branch office core services.

Distributed File System

The Distributed File System (DFS) technologies in Windows Server 2003 R2 offer WAN-friendly replication as well as simplified, fault-tolerant access to geographically dispersed files. The two technologies in DFS are as follows:

• DFS replication. New state-based, multimaster replication engine that is optimized for WAN environments. DFS Replication supports replication scheduling, bandwidth throttling, and a new byte-level compression algorithm known as remote differential compression (RDC).

• DFS namespaces. Technology that helps administrators group shared folders located on different servers and present them to users as a virtual tree of folders known as a namespace. DFS Namespaces was formerly known as Distributed File System in Windows 2000 Server and Windows Server 2003.

Evaluating and Planning Summary

There is no single step or recommendation for optimizing WAN bandwidth in every organization. Each organization has unique considerations when managing their WAN. As a result of the Evaluate and Plan phase, the goal is to identify where opportunities exist to consolidate services and have a better understanding of your current network topology so that WAN bandwidth can be proactively managed.

Phase 4: Deploy

Once you have identified the appropriate architectures and balance of centralized versus localized services for your branch offices in order to optimize WAN link constraints, the Deploy phase will implement the recommendations resulting from your branch office planning and architecture. Depending on the recommendations made, the Deploy Phase may, for example, lead to further centralization of services and, with those changes, WAN links will be adjusted appropriately. As part of the deployment process, it can be written as a standard policy to reexamine WAN link requirements and branch office infrastructure at appropriate intervals or corresponding with preset data, performance, or staffing thresholds.   

Further Information

For more information, visit Microsoft TechNet and search for “bandwidth management.”

To see how Microsoft manages WAN bandwidth, go to https://www.microsoft.com/technet/itshowcase/content/optbwcs.mspx.

Checkpoint: Proactively Managed Bandwidth to Branch Offices

	Requirements
	Identified and documented branch office topology.
	Created requirement specification based on the needs of all branch office types.
	Created a plan and architecture for branch office service consolidation and identified performance thresholds for reexamination of branch office WAN requirements.
	Implemented plan to optimize branch office services against WAN link limitations.

If you have completed the steps listed above, your organization has met the minimum requirement of the Rationalized level for Proactively Managed Bandwidth to Branch Offices capabilities of the Infrastructure Optimization Model. We recommend that you follow the guidance of additional best practice resources for managing bandwidth.

Go to the next Self-Assessment question.