Section 8.5. Planning, Implementing, and Maintaining Network Security and Infrastructure

8.5. Planning, Implementing, and Maintaining Network Security and Infrastructure

Security is critically important to ensure the integrity of the network. The way you secure the network will depend on the organization's security policies and the configuration of the network. On a typical network, clients will send requests to servers using TCP/IP, and servers will receive and process the requests. When clients connect to the network using wireless technology or connect to the network using remote access, special considerations must be made to ensure the security of the network is not compromised.

8.5.1. Planning and Configuring Network Protocol Security

In addition to IP addresses, computers on TCP/IP networks use specific protocols and ports for communications. Servers configured to use a specific protocol listen on a specific TCP or UDP port for requests from clients. For example, web servers listen on TCP port 80 for Hypertext Transfer Protocol (HTTP) requests.

8.5.1.1. Specifying and configuring port and protocol security

The Internet Assigned Numbers Authority (IANA) is responsible for assigning the values used for TCP/IP protocols and ports. Commonly used protocols have permanently assigned port numbers, which are referred to as well-known ports. While clients may contact a server on a particular port, the client may in some cases use a randomly assigned port to connect to and communicate with a server. This random port is referred to as an ephemeral port.

On a server, you can type netstat -ano at a command prompt to list all TCP and UDP port connections to that server. The output shows, by protocol, which ports are in use, such as:

 Proto  Local Address     Foreign Address State           PID TCP    192.168.20.10:80  0.0.0.0:0       LISTENING       2581

In the example, process ID 2581 is listening on the local address 192.168.20.10 to port 80. Because this process is using port 80, another program is prevented from using this port as well. Type tasklist /fi "pid eq ProcessNumber" at the command prompt to determine which program is using the port where ProcessNumber is the PID, such as:

 tasklist /fi "pid eq 2300"

Table 8-17 lists the commonly used protocols for Windows Server 2003 and the ports on which those protocols commonly are used. Keep in mind that most protocols can be configured to use different, alternate listen ports. For example, a common alternate listen port for HTTP is 8080.

Table 8-17. Commonly used protocols for Windows Server 2003
Protocol	Listen port
Domain Name System (DNS)	TCP port 53 and UDP port 53
Dynamic Host Configuration Protocol (Client)	UDP port 68
Dynamic Host Configuration Protocol (Server)	UDP port 67
File Transfer Protocol (FTP)	TCP port 20 for data; TCP port 21 for control
Global Catalog	TCP port 3268
Global Catalog with LDAP/SSL	TCP port 3269
Hypertext Transfer Protocol (HTTP)	TCP port 80
Installation Bootstrap Service	TCP ports 1067 and 1068
Internet Authentication Service (IAS)	UDP ports 1645, 1646, 1812, and 1813
Internet Security Association and Key Management (ISAKM)	UDP port 500
Kerberos change password protocol	TCP port 464
Kerberos version 5	UDP port 88
Layer 2 Tunneling Protocol (L2TP)	UDP port 1701
LDAP Secure Sockets Layer (SSL)	TCP port 686
Lightweight Directory Access Protocol (LDAP)	TCP port 389 and UDP port 389
NetBIOS Datagram protocol	UDP port 138
NetBIOS Name Server protocol	UDP port 137
NetBIOS Session Services	TCP port 139
Network News Transfer Protocol (NNTP)	TCP port 119
Point-to-Point Tunneling Protocol (PPTP)	TCP port 1723
Post Office Protocol 3 (POP3)	TCP port 110
Remote Desktop Protocol (RDP)	TCP port 3389
Remote procedure call (RPC)	TCP port 135
RPC over HTTP	TCP port 593
Secure Hypertext Transfer Protocol (HTTPS)	TCP port 443
Secure NNTP	TCP port 563
Sever Message Block (SMB) over IP	TCP port 445 and UDP port 445
Simple Mail Transfer Protocol (SMTP)	TCP port 25
Simple Network Management Protocol (SNMP)	UDP port 161
Simple Network Management Protocol trap	UDP port 162
Windows Product Activation	TCP port 80 and 443

The most common way to secure a server is to use packet filtering. Packet filtering is used to control the TCP/IP traffic that is permitted to reach a computer or a network, based on specific criteria, such as IP address, IP protocol, TCP port, or UDP port. Packets that do not meet the requirements of a particular filter are discarded. In this way, only packets that meet filter requirements reach a computer or network and are processed.

While packet filtering primarily is used by firewalls and routers that connect the internal network to the Internet, you can use packet filtering on your internal network as well. For example, you might want to use it to regulate the flow of traffic from one subnet to another or to limit the types of traffic that can be received by a server. In this case, you could install a firewall between the network segments or enable a software-based firewall on the server for which you want to limit traffic. You could also enable packet filtering on the router that connects the subnets or on the server for which you want to limit traffic.

Before you create packet filters, you need to determine the types of traffic that you will permit and the types of traffic that you will deny. You can then configure packet filtering to be inclusive or exclusive:

Inclusive: You completely block all traffic and then specify the permitted traffici.e., the traffic to include.
Exclusive: You open the connection completely and then specify the traffici.e., the traffic to exclude.

While the inclusive approach is more secure, it is much more difficult to configure as you must specifically allow all types of permitted traffic. On Windows XP Professional and Windows Server 2003, packet filtering can be configured in several ways.

Windows XP Professional and Windows Server 2003 include the Windows Firewall. To start Windows Firewall, click Windows Firewall in the Control Panel. In the default configuration, when Windows Firewall is enabled, all outside sources are blocked from connecting to the computer by default, an the exceptions specified on the Exceptions tab only are allowed.

Tip: Do not use Windows Firewall on Windows Server 2003 systems configured as IP routers or for remote access servers. Instead, use the NAT/Basic Firewall features of RRAS.

Windows XP Professional and Windows Server 2003 include TCP/IP Filtering. To use TCP/IP Filtering, follow these steps:

Click Start Control Panel Network Connections Local Area Connection.
Click Internet Protocol (TCP/IP), and then select Properties.
Click the Advanced Button.
On the Options tab, click the Properties button.
Use the TCP/IP Filtering dialog box, shown in Figure 8-25, to configure packet filtering. Turn on packet filtering by selecting Enable TCP/IP Filtering (All Adapters). By default, all TCP, UDP, and IP Protocols are allowed.
To filter TCP traffic, click Permit Only for TCP Ports. Click Add to define a permitted TCP port.
To filter UDP traffic, click Permit Only for UDP Ports. Click Add to define a permitted UDP port.
Click OK four times.

Figure 8-25. Configuring standard TCP/IP packet filtering.

When you have configured a server as a router using Routing And Remote Access Service (RRAS), you can configure packet filtering through RRAS. Packet filtering in RRAS is more versatile and configurable than the standard Windows Server 2003 packet-filtering feature. To use packet filtering with RRAS, follow these steps:

Open Routing And Remote Access. Connect to the server you want to work with (if necessary).
Expand the server node and the related IP routing node.
Click the General node.
Right-click the WAN interface, and then select Properties.
On the General tab, click the Inbound Filters button, and then configure filters if you want to limit incoming traffic.
On the General tab, click the Outbound Filters button, and then configure filters if you want to limit outgoing traffic.

8.5.1.2. Planning and configuring an IPSec policy for secure network communications

To protect the data being sent between computers on the network, you can use IP Security (IPSec). IPSec is a technology for authenticating and encrypting IP traffic between computers. IPSec operates at the network layer as an extension to the IP protocol itself, and provides end-to-end encryption for IP traffic. The source computer and the intended recipient only an read the encrypted traffic.

IPSec secures traffic by encrypting it, and then encapsulating it prior to transmission. Even if packets are captured during transmission from one computer to another, the packets are protected because they can be read only by a computer that has the appropriate key needed to decrypt the data. Because the encrypted data is encapsulated in standard IP datagrams, routers, switches, and other intermediaries handle the encrypted data as they do any other packets. They do not need to be able to read the packets to forward the packets to the appropriate destination.

While there are other protocols that provide network traffic encryption, these operate at the application layer and are used to encrypt only specific types of traffic. For example, web servers can be configured to use Secure Sockets Layer (SSL) . SSL encrypts traffic between web clients and web servers. In contrast, IPSec can encrypt any type of traffic and is not dependent on a specific application.

IPSec policy is most often implemented when you need to:

Secure communications on an internal network
Secure communications between networks, especially when traffic passes over WAN connections
Secure communications between remote access clients and the internal network

With RRAS, remote access clients that establish VPN connections with a RRAS server can use IPSec to enhance security when the Layer 2 Tunneling Protocol (L2TP) is used. When VPN connections are used to connect LANs and WANs, IPSec can also be used with L2TP to enhance security. In either configuration, IPSec is used to encrypt all traffic. Thus, regardless of the destination, all traffic passing over the VPN connection is encrypted and protected.

The IPSec standards define two protocols for securing network communications:

IP Authentication Header (AH): This is not used to encrypt data in IP packets. Instead, AH is used to provide authentication, anti-relay, and integrity services. AH can be used by itself or with IP Encapsulating Security Payload protocol. By itself, AH provide basic security but does not prevent unauthorized users from reading packet contents. AH does guarantee, however, that no one has modified packets enroute to its destination. It does this using relatively low overhead.
IP Encapsulating Security Payload (ESP): This protocol is used to encrypt data in IP packets. Encryption secures the data and prevents intruders from relaying information. ESP provides authentication, anti-relay, and integrity services. In contrast to AH, which inserts only a header into the IP packet, ESP inserts a header and a trailer to ensure that all data following the ESP header, up to and including, the ESP trailer is encrypted. As a result, anyone who captures a secured packet can only read the IP header, but cannot read any part of the rest of the packet. ESP can be used with AH; using both protocols ensures the maximum possible security for data transmission.

IPSec operates either in transport mode or tunnel mode:

Transport mode: Two computers act as end points and communicate with each other using IPSec, but intermediaries, such as routers, do not need to use or support IPSec.
Tunnel mode: The WAN routers on either end of a connection act as the end points and communicate with each other using IPSec, but computers transmitting packets to each other over the WAN connection do not need to use or support IPSec.

IPSec is applied using Group Policy:

For Active Directory domains, IPSec policies are stored under Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Active Directory.
For computers in workgroups, you can configure local group policy under Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Local Computer.

In Windows Server 2003, IPSec has four main components:

An IPSec Policy Agent: This provides the services needed for end-to-end security between clients and servers. On Windows 2000 and later systems, the IPSec Policy Agent is the IPSEC Services service (lsass.exe). This service must be enabled and running on all systems that use IPSec.
Internet Key Exchange (IKE): This is the protocol used to negotiate the key exchange. The computers in the exchange must negotiate the encryption algorithm, the hashing algorithm, and the authentication method that will be used. They also exchange information about key generation.
IPSec Driver: This enables secure communications by generating the required checksums, creating the IPSec packets, and encrypting data for transmission. The driver is also responsible for comparing each outgoing packet to the filter list obtained from the IPSec policy being used. For incoming packets, the driver calculates its own hashes and checksums, and then compares these to the hashes and checksums in the received packets.
IPSec Policy: This defines packet filters that enforce security by blocking, allowing, or initiating secure communications. Although multiple IPSec policies can be defined, one policy only is applied at a time.

Active Directory has three default IPSec policies:

Server (Request Security) policy: Servers always request security using Kerberos trust but do not require secure communications. This policy is intended for use when the highest levels of security are not required and servers might communicate with clients that do not support IPSec.
Client (Respond Only) policy: Clients communicate unsecured normally but respond to server requests for secure communications. This policy is intended for computers that connect to both secured servers and unsecured servers.
Secure Server (Require Security) policy: Servers always require secure communications using Kerberos trust. Servers will not respond to clients that do not or cannot use secure communications. This policy is intended for computers working with sensitive data that requires the highest levels of security at all times.

Only one IPSec policy can be assigned and enforced at a time. To assign and enforce one of these policies, follow these steps:

Open the GPO you want to work with for editing.
Access Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Active Directory.
The Policy Assigned column indicates whether a policy is assigned.
To assign and apply a policy, right-click it and select Assign.

To create a new policy, follow these steps:

Open the GPO you want to work with for editing.
Access Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Active Directory.
Right-click IP Security Settings On Active Directory, and then select Create IP Security Policy.
Follow the prompts, and the IP Security Policy Wizard guides you through the steps of creating the policy.

After you create the policy, edit its properties. The wizard automatically opens the policy's properties dialog box when you click Finish. You can display the properties dialog box by right-clicking the policy and selecting Properties (see Figure 8-26).

Figure 8-26. Configure rules for the IPSec policy.

IPSec policies have three components:

Rules: These combine IP filter lists with filter actions to define whether and how computers should use IPSec. An IPSec policy can have multiple rules. Typically, there are rules for all IP traffic and all ICMP traffic, as well as a default rule. Other rules also can be defined.
IP filter lists: These are collections of filters that specify what types of traffic a computer should secure with IPSec, such as All IP Traffic or All ICMP Traffic. Filters can be applied based on source IP address, destination IP address, protocol, source port, and destination port.
Filter actions: These specify exactly how IPSec should secure the filtered packets. Filter actions require at least one security method. With integrity and encryption security, the data will be encrypted and authenticated. With integrity-only security, the data will be authenticated but not encrypted.

With a policy's Properties dialog box open, you can create rules that define IP filter lists and filter actions by clicking Add on the Rules tab, and then following the prompts for the Create IP Security Rule Wizard. To assign and enforce the new policy, right-click the policy and select Assign.

To determine whether IPSec policy is applied to a computer, complete these steps:

Click Start Run. Type mmc in the Open field, and then click OK.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click IP Security Policy Management, and then click Add.
In the Select Computer Or Domain window, click Local Computer to analyze the local computer's IPSec policy. Otherwise, click Another Computer, and then type the name or IP address of the remote computer to analyze.
Click Finish. Click Close, and then click OK.
In the MMC, click the IP Security Policies On . . . node.
In the right pane, you'll see a list of IPSec policies defined in the domain. Under Policy Assigned, you'll see an entry of Yes if a policy is being applied. If a policy is not applied, you'll see an entry of No in the Policy Assigned column (see Figure 8-27).

Figure 8-27. Determining whether IPSec is being applied.

8.5.2. Planning Secure Network Administration Methods

For secure network administration of remote computers, Remote Desktop for Administration and Remote Assistance are essential as they increase efficiency by allowing you to centrally and remotely manage systems, regardless of where they are located on the network. For Exam 70-293, you need to know how to configure and use Remote Desktop For Administration and Remote Assistance, as discussed in "Essential Administration Tools" in Chapter 2. Review the related sections in Chapter 2.

As part of planning, it is important to understand the possible modes in which each can be used. Remote Desktop For Administration is one of two operating modes for Windows Server 2003 Terminal Services. Using Remote Desktop For Administration, administrators can establish remote connections to client computers. Each server configured with Remote Desktop For Administration can have up to two concurrent connections. If the feature is enabled, any user that is a member of the Administrators group can establish remote desktop connections. Additional remote desktop users can be set as well.

Using Remote Assistance, a user can send an invitation asking for troubleshooting help. The helper or expert accepting the request can view the user's desktop and transfer files, and chat with the user needing help through a single interface. Two assistance modes are possible:

If the computer is allowed to be remotely controlled, the helper or expert can take over the computer and resolve the problem as if she is sitting in front of the computer.
If the computer is not allowed to be remotely controlled, the helper or expert can view but not interact with the user's computer. The helper or expert can only offer guidance, and watch as the user tries to resolve the problem.

By default, remote assistance invitations are valid for 30 days. In environments where security is a high concern, 30 days typically is too long a period for invitations to remain open. In most cases, you'll want to restrict how long invitations can remain open to one day or less. You can do this through Group Policy. After you open the GPO you want to work with for editing, access Computer Configuration\Administrative Templates\System\Remote Assistance. You can then enable and configure the Solicited Remote Assistance policy, and in this way control how Remote Assistance is used.

Both Remote Desktop For Administration and Remote Assistance use TCP port 3389. This port should be open on the internal network to allow these features to be used. To protect your computers, this port should be blocked on external routers and firewalls to prevent users outside the organization from using these features. If you open TCP port 3389 on external routers and firewalls, you may inadvertently open the internal network to attack.

8.5.3. Planning Security for Wireless Networks

As discussed previously in this chapter under "Planning and Modifying a Network Topology," most wireless networks use technologies based on the IEEE 802.1 specification. Securing a wireless network is different from securing a wired network. On a wireless network, anyone who is within range of one of your wireless access points can gain access to your internal network. Unauthorized users can also intercept wireless signals being broadcast to your network and use information they've gleaned to break into the network. This makes security for wireless networks of critical importance.

To protect your internal network, all wireless transmissions should be secured and encrypted. Several technologies are available for authenticating and encrypting wireless transmissions. Wi-Fi Protected Access (WPA) is used for authentication. WPA has two operating modes:

Enterprise Mode: With this mode, wireless devices have two sets of keys: session keys and group keys. Session keys are unique to each association between an access point and a wireless client, and are used to create a private virtual port between the access point and the client. Group keys are shared among all clients connected to the same access point. Both key sets are generated dynamically and rotated.
Home/Small Office Mode: With this mode, also referred to as WPA-PSK, WPA doesn't use a changing encryption key. Instead, it uses a preshared encryption key, referred to as a group key, which is programmed into the base station and then configured on all the other wireless devices. Wireless devices use the master key as a starting point to mathematically generate session keys. Session keys are then regularly and automatically changed so that the same session key is never used twice.

Wireless Equivalency Protection (WEP) encrypts data using private key encryption. All data is encrypted using before it is transmitted, and any computer that wants to read the data must be able to decrypt it using the private key.

With Robust Security Network (RSN), wireless devices dynamically negotiate the authentication and encryption algorithms to be used for communications. This allows the supported authentication and encryption algorithms to be changed as needed to address security issues. Most RSN compatible devices can use:

Extensible Authentication Protocol (EAP) with Protected EAP (PEAP) as the encryption algorithm
Extensible Authentication Protocol (EAP) with Smart card or other PKI certificate
Advanced Encryption Standard (AES) as the encryption algorithm
Temporal Key Integrity Protocol (TKIP) as the encryption algorithm

During configuration of wireless networking, you need to specify the name of the wireless network and the mode in which the wireless device will run. Signals generated by wireless devices are omnidirectional. The broadcast range of a wireless device is referred to as its basic service area (BSA). All wireless devices have BSAs. Wireless devices within the same BSA are referred to as basic service sets (BSS).

Wireless devices run in one of two operating modes:

Ad hoc: With Ad hoc networks, two or more wireless devices communicate directly with each other. When two wireless devices are within range of each other, they can connect to form a two-node wireless network. If additional wireless devices come within range of one of the devices in this network, they can join the network. However, ad hoc networking is not transitive. A device on the ad hoc network must be within range of another device to communicate with itthe device cannot communicate with a device outside of its own range. Ad hoc networks are most often used on home networks.
Infrastructure: With infrastructure networks, wireless adapters connect to an access point rather than to another computer directly. A wireless access point (WAP) acts as a bridge between the wireless adapter and the physical network, and typically is connected to the organization's internal network by Ethernet cable. A wireless device within range of the wireless access point is able to try to connect to the internal network.

You can prevent unauthorized access and secure wireless transmissions using several different authentication methods. The IEEE 802.11 defines two methods: Open System Authentication and Shared Key Authentication. Windows Server 2003 supports an additional options called IEEE 802.1X.

The default authentication method for IEEE 802.11 devices is Open System authentication. As the name implies, this authentication method essentially allows any two wireless devices to communicate with each other. Although the devices identify each other prior to communicating, there is no exchange of passwords, keys, or other security credentials, and there is, therefore, no way for devices to refuse authentication with each other.

The Shared key authentication method for IEEE 802.11 devices requires each device to authenticate using a secret key that all devices on the wireless network must have to communicate. Because all devices have the same key, this method isn't very secure. If the shared key is compromised, then the entire network is.

The IEEE 802.1X standard defines a method of authenticating and authorizing users connecting to wireless networks. With IEEE 802.1X, wireless devices act as clients of a server, such as a server running RADIUS, and the server handles authentication and authorization using any supported authentication protocols, such as Extensible Authentication Protocol (EAP), Extensible Authentication Protocol Transport Layer Security (EAP-TLS), or Protected EAP (PEAP).

By default, a Windows XP Professional computer uses an Open System configuration and can connect to any available wireless network including both ad hoc and infrastructure networks. To enhance security, you should restrict wireless connections to designated infrastructure networks. To configure the client computer directly, follow these steps:

Click Programs Control Panel Network Connections.
Right-click the wireless connection and choose Properties.
On the Wireless Networks tab, click Advanced.
Select Access Point (Infrastructure) Networks Only.
Click Close, and then click OK.

Group Policy can be used to configure clients to use infrastructure networks only. To configure the client computer through Group Policy, follow these steps:

Open the GPO you want to work with for editing.
Access Computer Configuration\Windows Settings\Security Settings\Wireless Network (IEEE 802.11).
Right-click Wireless Network (IEEE 802.11), and then select Create Wireless Network Policy.
Follow the prompts, and the Wireless Network Policy Wizard guides you through the steps of creating the policy.
After you create the policy, edit its properties. The wizard automatically opens the policy's properties dialog box when you click Finish. You can display the properties dialog box by right-clicking the policy and selecting Properties.
On the General tab, set Networks To Access to Access Point (Infrastructure) Networks Only, as shown in Figure 8-28.

Figure 8-28. Limit clients to infrastructure networks only.
On the Preferred Networks tab, click Add to define the networks to which wireless clients subject to the GPO can connect.
On the Network Properties tab, type a name for the wireless network, and then set the desired network authentication and data encryption technique (see Figure 8-29).

Figure 8-29. Set the network name, authentication, and data encryption details.
Click OK.

8.5.4. Troubleshooting Security for Data Transmission

If IPSec is improperly configured, network communications between secured clients and secured servers can fail. The most common reason for this failure is an improper or incompatible configuration of the IPSec components. For example, while a client and server might both be configured to use IPSec for a particular type of traffic, they may be subject to different IPSec policies and therefore, have different filter action settings for this type of traffic. Having different, incompatible settings prevents the client and server from communicating with each other.

The best way to determine whether there is an IPSec policy mismatch is to examine the Security logs of both the client and the server. The Security log should contain warning messages if the systems attempted to perform an Internet Key Exchange negotiation that failed.

Some IPSec processes are only logged when auditing is enabled. Specifically, you must enable Audit Logon Events and Audit Policy Change for Success and Failure events. The IPSec driver can be configured to log dropped packets as well. To configure logging, type the following command:

 netsh ipsec dynamic set config ipsecdiagnostics 7

To disable diagnostic logging, type the following command:

 netsh ipsec dynamic set config ipsecdiagnostics 0

You can monitor IPSec policy to ensure that it is working correctly using IP Security Monitor. To access this snap-in in a console, complete these steps:

Click Start Run. Type mmc in the Open field, and then click OK.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click IP Security Monitor, and then click Add.
Click Close, and then click OK.

Tip: By default, IP Security Monitor connects to the local computer. If you want to monitor IPSec on another computer, right-click the IP Security Monitor node, and then click Add Computer. Expand the computer node, and then select the Active Policy entry to see the active IPSec policy on the designated computer (if any).

The Active Policy folder shows the IPSec policy currently assigned according to the specific GPO from which the policy was applied (see Figure 8-30). When you apply IPSec policy at multiple levels within the Active Directory structure, one IPSec policy only is applied, and by default, it is the policy processed last. Also by default, organizational unit policy has precedence over domain policy, and domain policy has precedence over site policy.

Figure 8-30. The Active Policy folder shows the IPSec policy currently assigned.

With the IP Security Monitor, you should use the Main Mode or Quick Mode nodes to view current filters, security methods, statistics, and security associations. High failure rates (relative to the level of IPSec activity) under the Statistics node can indicate IPSec configuration problems. If computers cannot make an IPSec connection, check to see whether the number of Authentication Failures increases. If so, authentication is the issue and you should ensure the following:

The computers' shared secrets match
The certificates are correct
The computers are members of the appropriate domain

If computers cannot make an IPSec connection, check to see whether the number of Negotiation Failures increases. If so, check the security method and authentication settings for incorrect configurations.

You can view similar IPSec information at a command prompt by typing:

 netsh ipsec static show all

By determining the Resultant Set of Policy for a user or computer, you can determine the specific IPSec policy settings that are being applied to that user or computer. To determine Resultant Set of Policy, follow these steps:

Click Start Run. Type mmc in the Open field, and then click OK.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click Resultant Set Of Policy, and then click Add.
Click Close, and then click OK.
Right-click Resultant Set Of Policy and select Generate RSoP Data.
Follow the prompts for using the Resultant Set Of Policy Wizard in Logging Mode, selecting the user and computer for which you want to review the RSoP. Click Finish.
Expand Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Active Directory or Computer Configuration\Windows Settings\Security Settings\IP Security Settings On Local Computer as appropriate.
The GPO from which the IPSec policy is being applied is listed, as are the specific IPSec settings being applied.

8.5.5. Planning a Security Update Infrastructure

Exam 70-293 expects you to know to install and configure software update infrastructure as a means of maintaining system security. Several different technologies are available to ensure that Windows computers are up to date with the latest security patches, hot fixes, and service packs, including:

Automatic Updates
Windows Update
Windows Server Update Services (WSUS)

These features were discussed previously in the section "Installing and Configuring Software Update Infrastructure" in Chapter 2. Review the related sections to prepare for Exam 70-293. WSUS requires IIS, BITS, and .NET Framework 1.1. WSUS is the replacement for Software Update Services (SUS).

You can use the Microsoft Baseline Security Analyzer (MBSA) to check for common security problems on a single computer or multiple computers. MBSA is not included with Windows Server 2003, but can be downloaded from the Microsoft Downloads site (http://download.microsoft.com). MBSA can detect incorrect security configurations and failure to install security updates. When you run MBSA, it details:

Account vulnerabilities
Filesystem vulnerabilities
Improper passwords
Missing security updates
Other vulnerabilities, such as those for IIS or SQL Server

8.5.6. Planning and Configuring a Public Key Infrastructure That Uses Certificate Services

Public Key Infrastructure (PKI) provides the components and services necessary to use public and private keys with digital certificates. You can use certificates for authentication and encryption. Two types of certificates are used:

Client certificates: These contain identifying information about a client
Server certificates: These contain identifying information about a server

Certificates enable clients and servers to authenticate each other prior to establishing a connection. Because certificates contain public and private encryption keys, they also are used to encrypt and decrypt data. A basic overview of public and private key encryption follows:

When a client wants to securely send data to a server, the client obtains the server's public key and uses it to encrypt the message. The message is then securely transmitted over the network.
When the server receives the encrypted message from the client, the server decrypts it using its private key.
When the server wants to securely reply to the client's request, the server obtains the client's public key and uses it to encrypt the reply. The reply is then securely transmitted over the network.
When the client receives the encrypted reply from the server, the client decrypts it using its private key.

Windows Server 2003 includes PKI components and services referred to collectively as Microsoft Certificate Services . Microsoft Certificate Services allow you to issue and manage digital certificates.

8.5.6.1. Identifying the appropriate type of certificate authority to support certificate issuance requirements

Certificate authorities are used to issue digital certificates. A certificate authority (CA) is a trusted agency responsible for confirming the identity of clients and servers, and then issuing certificates that confirm these identities. Before issuing a client certificate, CAs require you to identify the user, the user's organization, and the client application being used. Before issuing a server certificate, CAs require you to identify the organization in which the server is located and the server itself.

Certificate servers can be configured as one of four types of CAs:

Enterprise root CA: The certificate server at the root of the hierarchy for an Active Directory domain. The enterprise root CA is the most trusted CA in the enterprise and is integrated with Active Directory.
Enterprise subordinate CA: A certificate server that is a member of an existing CA hierarchy. The enterprise subordinate CA can issue certificates but must obtain its own CA certificate from the enterprise root CA.
Stand-alone root CA: The certificate server at the root of a nondomain (workgroup) hierarchy. The stand-alone root CA is the most trusted CA in its hierarchy and does not use Active Directory.
Stand-alone subordinate CA: A certificate server that is a member of an existing nonenterprise (workgroup) hierarchy. The stand-alone subordinate CA can issue certificates but must obtain its own CA certificate from the stand-alone root CA in its hierarchy.

8.5.6.2. Planning the enrollment and distribution of certificates

The enterprise root CA is at the top of the enterprise CA hierarchy. There can be only one root CA in an enterprise. All other CAs in the hierarchy must be enterprise subordinate CAs.

Enterprise CAs use certificate templates, publish their certificates and revocation lists to Active Directory, and use the information in Active Directory to determine whether to automatically approve or deny certificate enrollment requests. Clients must have access to Active Directory to receive certificates.

Tip: Enterprise CAs publish their Certificate Revocation Lists in Active Directory, making it easier to ensure that revoked certificate cannot be used.

Stand-alone CAs can use the same type of hierarchy as enterprise CAs. You can create a stand-alone root CA with all other CAs in the hierarchy created as stand-alone subordinate CAs. If you plan to use a single stand-alone CA, this CA must be configured as a stand-alone root CA.

Stand-alone CAs do not use templates and are not integrated with Active Directory. They store information locally and by default do not automatically approve or deny certificate enrollment requests. Instead, certificate enrollment requests are maintained in a queue for an administrator to manually approve or deny them.

While certificate servers don't have to be dedicated for this sole purpose, it is generally a good idea to have dedicated certificate servers. To protect the integrity of certificate services, you should create multiple levels in the CA hierarchy. In an enterprise, this means setting up an enterprise root CA, and then setting up one or more levels of enterprise subordinate CAs. Then, issue certificates through the subordinate CAs only. This safeguard should help ensure that the root CA's private key can't be easily compromised.

8.5.6.3. Planning for the use of smart cards for authentication

A smart card is a small card-sized device that contains memory and/or integrated circuitry. Windows can use smart cards for authentication during logon. To use smart cards for authentication, you must:

Install smart card reader devices on computers.
Set up a smart card to use for user logon.

Smart cards contain a user's digital certificate and private key, allowing the user to be authenticated when logging on the network. With smart cards, only enterprise CAs can be used. The reason for this is that smart card certificates are associated with the user's account in Active Directory, and only enterprise CAs store certificates in Active Directory.

Tip: Stand-alone CAs do not store certificates in Active Directory and should not be used to issue smart card certificates.

Once you've configured your CA infrastructure, you can set up logon for smart cards by completing the following steps:

Log on using an account authorized to enroll certificates for the domain where the user's account is located.
Open Internet Explorer. In the Address field, type the address of the CA that issues smart card certificates, and then press Enter.
Click Request A Certificate, and then click Advanced Certificate Request.
Click Request A Certificate For A Smart Card On Behalf Of Another User Using The Smart Card Certificate Enrollment Station. If you are prompted to accept the smart card signing certificate, click Yes.
In Certificate Template, click Smart Card Logon if you want to use the smart card for logging on to Windows only, or click Smart Card User if you want to use the smart card for secure email as well as logging on to Windows.
In Certification Authority, click the name of the CA that will issue the smart card certificate.
In Cryptographic Service Provider, select the cryptographic service provider (CSP) of the smart card's manufacturer.
In Administrator Signing Certificate, click the Enrollment Agent certificate that will sign the enrollment request.
In User To Enroll, click Select User. Select the appropriate user account, and then click Enroll.
When prompted, insert the smart card into the smart card reader on your computer, and then click OK. When prompted, enter the personal identification number (PIN) for the smart card.

In Active Directory Users And Computers, you can view and manage the certificates assigned to a user account using the Published Certificates tab of the user's Properties dialog box. This tab is only displayed when View Advanced Features is selected.

8.5.6.4. Configuring Certificate Services

Microsoft Certificate Services uses IIS. You should install IIS prior to installing Certificate Services. After you install IIS, you can install Certificate Services by completing the following steps:

Log on to the server for which you are configuring Certificate Services. If you're creating an enterprise CA, the account must have Enterprise Admin privileges.
Click Start Control Panel Add Or Remove Programs.
Select the Certificate Services checkbox. When prompted, click Yes, and then click Next.
Select the CA type. Click Next.
Enter the common name for the CA, such as First Root CA, and set the CA certificate's expiration date. Click Next.
Specify the storage location for the configuration database and log. By default, the certificate database and log are stored in the \%SystemRoot%\System32\CertLog folder. Click Next.
If IIS is running on the certificate server, Windows will need to shut down IIS before continuing. When prompted, click Yes.
The Windows Components Wizard begins installing and configuring Certificate Services. Click Finish when this process is completed.

When you install Certificates Services on a computer running IIS, you can manage Certificate Services using a web browser. Use the URL http://hostname/certsrv/ where hostname is the name of the certificate server. The Certificate Authority console in the Administrative tools menu can also be used to manage Certificate Services. In an enterprise, the certificate server is configured for automatic enrollment by default. This means authorized users can request a certificate, and the CA automatically processes the certificate request so that the user can immediately install the certificate.

To view or change the default request processing policy, use the following technique:

Click Start Programs Administrative Tools Certificate Authority.
Click the Policy Module tab.
Click the Properties button.
To process requests manually, select Set The Certificate Request Status To Pending. The Administrator Must Explicitly Issue The Certificate.
To automatically process requests, select Follow The Settings In The Certificate Template, If Applicable. Otherwise, Automatically Issue The Certificate.
Click OK twice.

For manual processing of requests, you can review pending requests by selecting the Pending Requests node in the Certificate Authority console.