Enabling VPN connectivity requires a complex interplay between several server components such as the ISA Server configuration and the RRAS configuration. In addition, you have several configuration options such as authentication methods and tunneling protocols. All these components and options must be configured correctly to allow users to connect to the ISA Server computer using a VPN.
Use the following guidelines when troubleshooting VPN client connections:
1- The most common problems with VPN connections are user authentication problems.Start by checking the user configuration. Does the user have permission to dial in? Is the user part of a group that has permission to use VPN on the ISA Server computer? Is the user account locked out? Is the user using the correct password?
2- If the user account is not the problem, then check the authentication method configuration.If the user is connecting to a PPTP connection, ensure that the client and server share an authentication method. By default, ISA Server only enables MS-CHAP v2 authentication, so if users are using an older Windows client such as Windows 98 or Windows NT, they may not be able to support the authentication method. The best solution in this case is to install the appropriate security patches
on the clients so they support MS-CHAP v2 authentication.
3- If the users are connecting to an L2TP/IPSec connection, ensure that the client has the correct certificate installed or is configured to use the appropriate pre-shared key.
4- L2TP/IPSec clients may also not be able to authenticate if ISA Server is configured to block IP fragments. In this scenario, users will get an error message that indicates that the security negotiation timed out. IPSec uses the Internet Key Exchange (IKE) protocol for mutual computer authentication and for the exchange of session keys in an L2TP VPN connection. The IKE negotiation information cannot fit inside an MTU. Because of this, the IKE negotiation packet is fragmented into
smaller packets. When you filter fragmented packets in ISA Server, the IKE negotiation packets are dropped by ISA Server. Therefore, the VPN connection cannot be completed successfully. To enable client connections, you must configure ISA Server not to block IP fragments.
5- If the users can connect to the VPN remote-access server and authenticate, but cannot get access to any network resources, check the name resolution for the VPN clients. The VPN clients must be configured with a DNS server (and possibly a WINS server) address to resolve server names on the internal network.
6- If the DNS configuration is accurate, check the configuration of the access rules defined on the ISA Server computer. Remember that the VPN Clients network is used by ISA Server like any other network, so you must configure access rules in order to enable network traffic to flow between networks.
Guidelines for Troubleshooting VPN Client Connections
Configuring ISA Server Authentication
You can configure which authentication method ISA Server will use to authenticate users that connect using Web Proxy clients. ISA Server supports the following authentication methods:
- Basic authentication Basic authentication sends and receives user information as plaintext and does not use encryption. Basic authentication is the least secure authentication method that ISA Server supports. However, because basic authentication is part of the HTTP specification, most browsers support it.
- Digest authentication Digest authentication passes authentication credentials through a process called hashing. Hashing creates a string of characters based on the password but does not send the actual password across the network, ensuring that no one can capture a network packet containing the password and impersonate the user. Digest authentication currently works only in a domain in which all the domain controllers are running Microsoft Windows 2000 or Windows Server 2003 and client computers are running Internet Explorer 5 or later. Digest authentication also works only if the domain controller has a reversibly encrypted copy of the requesting user’s password stored in Active Directory. This is not the default configuration, and so you must enable this. Storing a password in reversible encryption is significantly less secure than the Active Directory default, in which the password is stored in a one-way hash.
- Integrated Windows authentication Uses either the Kerberos version 5 authentication protocol or NTLM protocol, both of which do not send the user name and password across the network. Integrated Windows authentication works with Internet Explorer 2.0 or later. Use Integrated Windows authentication when all the client computers use Internet Explorer. Integrated Windows authentication is the default authentication method used by members of the Windows 2000 Server and Windows Server 2003 families.
- Digital certificates authentication Requests a client certificate from the client before allowing the request to be processed. Users obtain client certificates from a certification authority that can be internal to your organization or a trusted external organization. Client certificates usually contain identifying information about the user and the organization that issued the client certificate. Client certificates are more commonly used to authenticate Internet users rather than internal users trying to access the Internet. Web Proxy clients do not support client certificate authentication.
- Remote Authentication Dial-In User Service RADIUS is an industry-standard authentication protocol. A RADIUS client (typically a dial-up server, VPN server, or wireless access point) sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates the RADIUS client request, and sends back a RADIUS message response. RADIUS authentication is more frequently used to provide authentication for accessing resources on the internal network from the Internet.
ISA Server Clients and Authentication
The ISA Server authentication that you choose depends on the type of ISA Server client you have deployed in your organization.
SecureNAT Clients For SecureNAT clients, there is no user-based authentication. You can restrict access to the Internet based only on network rules and other access rules. If an access rule requires authentication, SecureNAT clients will be blocked from accessing the resources defined by the rule.
Firewall Clients When ISA Server authenticates a Firewall client, it uses the credentials of the user making the request on the computer running the Firewall client. Because ISA Server requests credentials when a session is established, no client configuration is required to enable authentication of users who gain access to ISA Server by using a Firewall client. When the Firewall client requests an object, ISA Server does not ask the client to authenticate, because the session already has an identity.
Web Proxy Clients Web Proxy clients do not automatically send authentication information to the ISA Server computer. By default, ISA Server requests credentials from a Web Proxy client only when processing a rule that restricts access based on a user set element. You can configure which method the client and ISA Server use for authentication.
You can also configure ISA Server to require authentication for all Web requests. When a Web Proxy client requests HTTP content and all users are required to authenticate, ISA Server will always ask for user credentials before checking the firewall policy. Otherwise, ISA Server will try to determine if the first rule (of the ordered firewall policy) matches the client request. If the rule seems to match, but ISA Server requires client authentication to validate the match, ISA Server will request that the client authenticate.
70-299 : Module 12 : Securing Remote Access
Windows Server 2003 provides two main types of remote access methods: dial-up and VPN. For each remote access type, there are several authentication and encryption protocols to choose from. You will have to choose the remote access type and security protocols based on the clients that will be connecting to your internal network and based on your existing infrastructure. This lesson will describe the two remote access methods and the various encryption and authentication protocols to allow you to make educated recommendations.
Remote Access Methods :
There are two primary methods for connecting remote users to a private network: dialup networking and virtual private networking. Dial-up networking enables a remote access client to establish a temporary dial-up connection to a physical port on a remote access server by using the service of a telecommunications provider, such as analog phone lines, Integrated Services Digital Network (ISDN), or X.25. The most common use of dial-up networking is that of a dial-up networking client that dials the phone number of a modem attached to the remote access server. This establishes a circuit
between the two devices.
Virtual private networking is the creation of an encrypted, authenticated point-to-point connection across a public network such as the Internet. A VPN client uses special network protocols called tunneling protocols to make a virtual call to a virtual port on a VPN server.
VPN Protocols :
Windows Server 2003 supports two VPN protocols: PPTP and L2TP. In most circumstances,either protocol will work equally well. They both provide similar levels of privacy and data integrity because they support the same authentication and encryption standards. They primarily differ in stability and compatibility. PPTP is more mature, but it is not an Internet standard. L2TP is relatively new, but it might be supported by a wider variety of non-Microsoft clients because it is an Internet standard.
11 Deploying, Configuring, and Managing SSL Certificates
Lesson 2: Configuring SSL for IIS
The most common use of SSL is to authenticate Web servers and to encrypt communications
between Web browsers and Web servers. SSL, when used to protect HTTP, is referred to as Hypertext Transfer Protocol Secure (HTTPS). HTTPS is used by virtually every e-commerce Web site on the Internet to protect private information about end users and to protect end users from submitting private information to a rogue server impersonating another server.
Internet Information Services (IIS) 6.0, included with Windows Server 2003, supports both server and client SSL certificates. Configuring these certificates is simple when you are managing a single Web site with a single server certificate. However, managing certificates can be complicated when a server has multiple certificates or when you are using client certificates for authentication.
You can use SSL certificates to allow users to verify the identity of your Web site and to encrypt traffic sent between the client and the Web site. It is important to understand that an SSL certificate identifies a Web site, and not a Web server. A single Web server can host multiple Web sites. Alternatively, a single Web site can be hosted on multiple Web servers to provide redundancy and scalability.
For example, an Internet service provider (ISP) that hosts Web sites for 20 customers on a single Web server needs 20 SSL certificates to allow each site to use encryption. Alternatively, if an ISP stores a copy of a Web site on 10 different servers to allow the Web site to remain online in the event of a hardware failure, the same certificate can be installed on all 10 servers.
SSL certificates use the fully qualified domain name (FQDN) to identify the Web site.When the client retrieves the site’s SSL certificate, the client checks the FQDN of the Web site against the subject name, also known as the common name, listed in the certificate. Checking the name used to identify the site against the name listed in the certificate prevents a rogue Web site from intercepting traffic destined for a different site.
The Web Server Certificate Wizard :
Using HTTPS on an IIS Web server requires the server to have a certificate installed and configured. The exact process you will use to configure the certificate varies depending on the source of the certificate; however, you will always use the Web Server Certificate Wizard to perform the configuration. To launch the Web Server Certificate Wizard:
1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. Expand the computer name, and then expand Web Sites. Right-click the Web site for which you want to configure an SSL certificate, and then click Properties.
3. Click the Directory Security tab, and then click the Server Certificate button. The Web Server Certificate Wizard appears.
You can use the Web Server Certificate Wizard to request a new certificate, assign an existing certificate, renew a certificate, and delete a certificate, as described in the following sections.
10 Planning and Implementing Security for Wireless Networks
802.1X authentication :
Although the early implementations of WEP were woefully inadequate, WEP’s vulnerability can be significantly reduced by using 802.1X authentication. 802.1X enables WEP to regularly change the encryption keys, which dramatically reduces the likelihood that an attacker will be able to gather enough data to identify the shared secret.
802.1X employs an Internet Engineering Task Force (IETF) standard protocol called Extensible Authentication Protocol (EAP) to carry the authentication conversation between the client, the WAP, and a Remote Access Dial-In User Server (RADIUS) service. As part of the 802.1X secure authentication process, the EAP method generates an encryption key that is unique to each client. RADIUS forces the client to generate a new encryption key on a regular basis, which makes it more difficult for an attacker to capture enough traffic to identify a key. This allows existing WEP-capable hardware to be used while minimizing WEP’s vulnerabilities.
Specifically, the client must perform the following steps to connect to an 802.1Xauthenticated
wireless network:
1. When the client computer is in range of the WAP, it will try to connect to the Service Set Identifier (SSID) hosted by the WAP. If the client has been configured with shared network authentication, it will authenticate itself to the WAP by using the network key. Because the WAP is configured to allow only 802.1X-authenticated connections, it issues an authentication challenge to the client. The WAP then sets up a restricted channel that allows the client to communicate only with the RADIUS service.
2. The wireless client examines the RADIUS server’s public key certificate to ensure that an attacker is not impersonating the RADIUS server. The client then attempts to authenticate, using 802.1X, to the RADIUS service.
❑ If the client and RADIUS service have been configured to use Protected EAP (PEAP) authentication, the client establishes a Transport Layer Security (TLS) session with the RADIUS service and then transmits credentials using the configured authentication protocol.
❑ If the client and RADIUS service have been configured to use EAP-TLS authentication, the client authenticates by using public key certificates.
3. The RADIUS service checks the client credentials against the directory. If it can authenticate the client’s credentials and the access policy allows the client to connect, it will grant access to the client. The RADIUS service relays the access decision to the WAP. If the client is granted access, the RADIUS service transmits the dynamic shared secret to the WAP. The client and WAP now share common key material that they can use to encrypt and decrypt the traffic that will pass between them.
4. The WAP then bridges the client’s connection to the internal network, completing the 802.1X authentication process. If the client is configured to use Dynamic Host Configuration Protocol (DHCP), it can now request a lease.
PEAP :
PEAP is typically used to authenticate wireless clients by using a user name and password; EAP-TLS is used to authenticate wireless clients by using public key certificates. Although using a user name and password is not as strong as using public key certificates, because passwords can be stolen or guessed, the resulting encryption is still very strong. When PEAP authentication is used with a RADIUS service that forces encryption keys to change regularly, the resulting WEP encryption is not likely to be compromised in a reasonable amount of time. PEAP’s primary advantage over EAP-TLS
is that it is easier to deploy because it does not require you to implement a Public Key Infrastructure (PKI).
The PEAP authentication method has two phases. Phase 1 authenticates the RADIUS server by using the RADIUS server’s public key certificate and then establishes a TLS session to the RADIUS server. Phase 2 requires a second EAP method tunneled inside the PEAP session to authenticate the client to the RADIUS service. This allows PEAP to use a variety of client authentication methods.
EAP-TLS :
EAP-TLS performs the same functions as PEAP by authenticating the client computer and generating keying material that will be used for encrypting the wireless communications. However, EAP-TLS uses public key certificates to authenticate both the client and the RADIUS service. EAP-TLS was designed by Microsoft and is based on an authentication protocol that is nearly identical to the protocol used in the Secure Sockets Layer (SSL) protocol for securing Web transactions. While public key certificates provide strong authentication and encryption, you should only use EAP-TLS if you already have a PKI in place for another application or your organization’s security requirements do not allow simple password authentication.
RADIUS :
RADIUS is a standardized service used primarily to authenticate dial-up users. Windows Server 2003 includes a RADIUS service and proxy named IAS. The traditional use for IAS on Windows networks is to allow an Internet Service Provider (ISP) to authenticate an organization’s users based on the Active Directory domain credentials stored on the organization’s private network.
Because RADIUS is designed to allow network hardware to authenticate against an external user database, WAPs also can use RADIUS to authenticate wireless users as they join the network. Authenticating to a RADIUS service allows user authentication for wireless networks to be centralized, rather than forcing administrators to store user credentials on each WAP.
Lesson 3: Troubleshooting IPSec
General Troubleshooting Guidelines
Regardless of the type of problem you are experiencing, you should first make sure that the necessary services are started and set to automatic on both IPSec peers. On computers running Windows Server 2003, the IPSec Services service must be started. On computers running Windows 2000, the IPSec Policy Agent service must be started. Sometimes, especially after making significant changes, you might be able to resolve a problem by restarting IPSec services. This completely clears the IKE negotiation state. You can restart IPSec services from a command prompt by running the following commands:
net stop policyagent
net start policyagent
This is simply a quick way to restart IPSec without restarting the computer. After restarting the IPSec services on both computers, attempt to establish a secure connection. If the problem persists, restart the operating systems on both IPSec peers and try again.
Kerberos Authentication Problems :
Kerberos authentication is the default IPSec authentication method. You can quickly identify whether IPSec connectivity problems are caused by authentication by temporarily changing the IPSec authentication method on both IPSec peers to Preshared Key. If IPSec communications succeed with Preshared Key, Kerberos authentication is probably the source of the problem.
For Kerberos authentication to be successful, both IPSec peers must have valid computer accounts in trusted domains, and they must be able to authenticate the remote computers. Each IPSec peer must be able to communicate with domain controllers without having the authentication requests filtered. In earlier versions of Windows, IPSec automatically allowed Kerberos traffic. However, the Kerberos protocol is no longer a default exemption in Windows Server 2003.
Certificate Authentication Problems :
Certificates are a common method for authenticating computers that are not in a trusted domain environment. If you are experiencing problems with IPSec and want to verify that the problem is related to authentication, temporarily change the IPSec authentication method on both IPSec peers to Preshared Key. If IPSec communications succeed with Preshared Key but fail with certificates, the problem is almost certainly related to certificates.
If you have multiple rules in a policy, double-check that those rules will use the same authentication method consistently for any single remote computer. It is acceptable to have a policy that configures Kerberos authentication for hosts on an internal network and uses certificates for hosts on an external network. However, you cannot create one rule that uses Kerberos to authenticate just Transmission Control Protocol (TCP) data and a second rule that authenticates User Datagram Protocol (UDP) traffic by using certificates, for example. The IP Security Policy Management snap-in will not prevent you from creating these rules, but they will not work properly. All rules that apply to a single remote host must use a single authentication method.
Troubleshooting Firewalls, Routers, and Packet Filtering :
Packet filtering at firewalls is a common source of IPSec problems because IPSec cannot be permitted or blocked by applying the techniques used for most applications. First, your firewall must allow two-way traffic with a UDP destination port of 500. If the firewall is also a NAT server and you will be using Network Address Translation Traversal (NAT-T), you must also allow UDP traffic with a destination port of 4500. Second, the firewall must allow traffic with an IP protocol ID of 50, which is used by ESP. If you are using AH instead of ESP, you must allow IP protocol 51.
Network Address Translation Problems :
Network Address Translation (NAT) is a common technique for connecting a privately numbered internal network to a public network such as the Internet. As Chapter 8 discussed, earlier implementations of IPSec were not compatible with NAT. This makes sense, because NAT’s purpose is to modify the source or destination IP address in a packet without the client or server being aware, and part of IPSec’s purpose is to discard packets that have been modified in transit.
MCP 70-299 : 8 - Planning and Configuring IPSec
Active Directory Considerations :
For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members. Another advantage of using Active Directory–based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization.
that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups. To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server
2003 operating system CDs.
Authentication for IPSec :
Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.
If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.
Public key certificates authentication :
A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec.
Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.
Preshared key authentication :
If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer’s domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers’ communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.
The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory–based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.
Testing IPSec
As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.
Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.
Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.
After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.
MCP 70-299 : 8 - Planning and Configuring IPSec
Unfortunately, IP was not originally designed with authentication or encryption in mind. As the internet grew and TCP/IP became the network protocol of choice, this unsecured form of communication became the standard. IPSec allows computers to continue using IP, while adding authentication and encryption.
However, most computers on IP networks today do not have IPSec enabled. As a result, computers with IPSec enabled are usually configured to politely ask remote computers to use IPSec to improve the security of the connection. If the two computers determine that they both have IPSec configured, and can agree upon a set of security standards, they can begin to use IPSec. This process is known as IPSec negotiation.
Not all IPSec negotiations are successful. Often the negotiations will fail because one of the two computers is not capable of using IPSec. Alternatively, the computers might not have the same security protocols enabled, which would mean that they wouldn’t be able to agree on a set of standards. In these cases, the computers will either revert to unprotected IP communications or determine that they will not communicate at all if they cannot use IPSec.
Internet Key Exchange (IKE) is the algorithm by which the first secure Security Association, or SA (a secure channel), is negotiated. IKE is a combination of the Internet Security Association Key Management Protocol (ISAKMP) and the Oakley Key Determination protocol and performs a two-phase negotiation: Main Mode and Quick Mode.
Main Mode
The initial long form of the IKE negotiation (Main Mode or Phase 1) performs the authentication and generates the master key material to establish an ISAKMP SA between machines. The result is referred to as an ISAKMP SA or an IKE SA. After the ISAKMP SA is established, it will remain in place for the period of time defined on the host computers—by default, it will last for 8 hours on computers running Windows. If data is actively being transferred at the end of the 8 hours, the Main Mode security association (SA) will be renegotiated automatically.
Main Mode negotiation occurs in three parts:
1. Negotiation of protection suites
2. Diffie-Hellman exchange
3. Authentication
Quick Mode
Quick Mode (also known as Phase 2) IKE negotiation establishes a secure channel between two computers to protect data. Because this phase involves the establishment of SAs that are negotiated on behalf of the IPSec service, the SAs created during Quick Mode are called the IPSec SAs. Two SAs are established, each with its own Security Parameter Index (SPI) label. One IPSec SA is used for inbound traffic, and the other is used for outbound traffic. During Quick Mode, keying material is refreshed or, if necessary, new keys are generated. A protection suite that protects specific IP traffic is also selected.
IPSec hosts will perform IKE Quick Mode negotiation on a regular basis to reduce the risk of an attacker using brute force methods to determine the keys used in the communications. Each renegotiation re-establishes two new IPSec security associations with new keys and SPIs. By default, computers running Windows will perform Quick Mode negotiation every hour (3600 seconds) or after 100 megabytes have been transferred.
Either side of the connection can start the renegotiation process. Therefore, the site that first reaches the defined session key limit will initiate renegotiation. Lesson 3 describes how to specify session key limits.
Authentication Header and ESP :IPSec can use two protocols: Authentication Header (AH) and ESP. The protocols canbe used either separately or together. AH provides data origin authentication, dataintegrity, and anti-replay protection for the entire packet, including the IP header andthe data payload carried in the packet. Naturally, AH does not provide protection forthe fields in the IP header that are allowed to change in transit, such as the hop count.AH does not encrypt data, which means it does not provide privacy. Attackers can readthe contents of packets if they can intercept them, but the packets cannot be modified.ESP is more commonly used than AH because it provides data origin authentication,data integrity, anti-replay protection, and the option of privacy. While AH and ESP canbe used together, you will use ESP alone in most circumstances. You should chooseAH over ESP only when the data and header in the packet need to be protected frommodification and authentication but not encrypted. You might do this if you have anintrusion detection system, firewall, or quality of service (QoS) router that needs toinspect the contents of the packet. Otherwise, take advantage of the privacy providedby encryption, and use ESP. If IPSec traffic must traverse a NAT server, you must useESP, because ESP is the only IPSec protocol that supports NAT-T.
IPSec in Windows :
IPSec is natively available and can be used to protect network communications for Windows 2000, Windows XP Professional, and Windows Server 2003. Additionally, a legacy client is available for Microsoft Windows NT 4.0, Windows 98, and Windows Millennium Edition (ME). You can download the legacy client from
MCP 70-299 : Planning and Configuring an Authentication Strategy
Lesson 1: Understanding the Components of an Authentication Model :
The Difference Between Authentication and Authorization :
The two processes are closely related and often confused. To understand the difference between authentication and authorization, consider an example in the physical world that most people are familiar with: boarding an airplane. Before you can board a plane, you must present both your identification and your ticket. Your identification, typically a driver’s license or a passport, enables the airport staff to determine who you are. Validating your identity is the authentication part of the boarding process. The airport staff also checks your ticket to make sure that the flight you are boarding is the correct one. Verifying that you are allowed to board the plane is the authorization process.
The server that authenticates the user must be able to determine that the user’s credentials are valid. To do this, the server must store information that can be used to verify the user’s credentials. How and where this information is stored are important decisions to make when designing an authentication model.
■ Authentication is the process of proving your identity. In Windows networks, users frequently authenticate themselves using a user name and password pair. How the user name and password are communicated across the network has changed with different versions of Windows.
■ Earlier versions of Windows use LM authentication, which is still supported by Windows Server 2003 for backward compatibility but carries with it potential security vulnerabilities. LM authentication should be disabled whenever compatibility with Windows 95 or Windows 98 is not required.
■ If LM authentication cannot be disabled, the storage of the LMHash can be avoided for specific user accounts by using passwords greater than 14 characters or passwords that contain special ALT characters.
■ Newer versions of Windows use NTLMv1, NTLMv2, or Kerberos authentication. The Kerberos protocol is designed to be more secure and scalable than NTLM authentication.
■ Local passwords are stored and maintained by the Local Security Authority (LSA). The LSA is responsible for managing local security policies, authenticating users, creating access tokens, and controlling audit policies.
■ Windows Server 2003 and the Resource Kit include the Kerbtray.exe, Klist.exe, and CmdKey.exe tools for troubleshooting Kerberos authentication problems.
Considerations for Evaluating Your Environment :
When evaluating your environment, identify the following:
■ The number of domain controllers in your organization. Ensure that there are enough domain controllers to support client logon requests and authentication requests while meeting your redundancy requirements.
■ The type of network connectivity between site locations in your organization. Ensure that clients in remote sites are connected well enough to authenticate to domain controllers located in main sites.
■ The number of certification authorities (CAs) that are available in your organiza tion and their locations. Ensure that you have enough CAs to support the anticipated number of certificate requests.
What is a strong password?
A strong password is one that can be remembered by the user but that is also complex enough to be difficult to guess. For example, *&_I5y#<.h may appear to be a good password, but the user might be forced to write it down in order to remember it, creating a significant security vulnerability. Fortunately, there are techniques for creating strong passwords that the human brain can remember.
an easy-to-remember suffix to it to make it more secure: 99Butterflies@complexpass word.com. You now have a password that is 33 characters long, uses uppercase, lowercase, and symbols, is easy to remember, and that, because of the length, is harder than the *&_I5y#<.h password to crack.
Strong password policy :
When implementing and enforcing a password policy, consider the users’ inability to remember passwords that are too complex, change too often, and are too long. When passwords are too complex or too long, the eventuality that users will use other methods to remember their passwords, such as writing them down, is more likely.
Password Complexity is enforced by default in the Windows Server 2003 environment. The Password Complexity feature requires that passwords:
■ Do not contain all or part of the user’s account name.
■ Be at least six characters in length.
■ Contain characters from three of the following four categories:
❑ Uppercase characters (A through Z)
❑ Lowercase characters (a through z)
❑ Base 10 digits (0 through 9)
❑ Non-alphabetic characters (for example, !, $, #, %).
Windows 2003 Authentication Methods for Earlier Operating Systems :
Authentication protocols have improved over time and will continue to improve in the future. As a result, earlier operating systems support fewer and less secure authentication protocols than newer operating systems. By default, computers running Windows Server 2003 can accept all types of authentication protocols, including LM, NTLMv2, and Kerberos, to ensure compatibility with earlier operating systems. If your organization does not require this backward compatibility, you can you can configure security policy to support only the more secure protocols, such as NTLMv2 and Kerberos.
The Network Security LAN Manager Authentication Level policy defines which authentication protocols a computer sends and accepts. This policy is contained within the Local Policies\Security Options security policy node. Table 1.6 describes the options for this policy setting. The policy settings are listed in order from least to most secure. Increasing the security of this policy reduces compatibility with earlier clients and servers.
To configure domain controllers to reject LM authentication:
1. On a domain controller, click Start, click Administrative Tools, and then click Domain Controller Security Policy.
2. Expand Local Policies and then select Security Options
3. Double-click Network Security: LAN Manager Authentication Level. The Network Security: LAN Manager Authentication Level Properties dialog box appears.
4. Select the Define This Policy Setting check box, if it is not already selected.
5. Select Send NTLMv2 Response Only\Refuse LM, and then click OK.
6. Close the Default Domain Controller Security Settings console.
7. Click Start, and then click Run. Type gpupdate.exe, and click OK. This causes the policy to take effect on the local domain controller immediately.
Lesson Summary :
■ Use security policy settings to configure authentication requirements.
■ Implement a strong password policy in your organization to reduce the likelihood that your users’ credentials will be compromised.
■ Although you can enforce complex passwords by using security policy in Windows Server 2003 Active Directory, employee education is the only way to keep users from writing down passwords or using discoverable personal information in passwords.
■ An account lockout policy prevents malicious attackers from logging on by continually guessing passwords; however, it enables malicious attackers to perform a denial-of-service attack that denies valid users from successful authentication.
■ Kerberos ticket lifetimes must be short enough to prevent attackers from cracking the cryptography that protects the ticket’s stored credentials, but long enough to minimize the number of tickets that clients request.
■ Use delegated authentication and constrained delegation as strategies for implementing supplemental authentication where required.
■ Any application that has the Certified for Windows Server 2003 logo has been tested to ensure that it will function in environments that require multifactor authentication.
Lesson 3: Configuring Authentication for Web Users :
Configuring Anonymous Access for Web Users :
Most public Web sites on the Internet allow anonymous access for at least a portion of the site. In other words, the general public can retrieve pages from the Web server without providing credentials. This does not mean that authentication is not taking place, however. Any user or process that accesses a file or other network resource must do so in the context of a security principal (a user, a computer, or a service account). When Internet Information Services (IIS) accesses files to be sent to an anonymous user, it uses a specified user account to access those files. When anonymous access is not allowed, users must provide their own credentials.
Configuring Web Authentication :
This chapter has already described three authentication protocols: LM, NTLM, and Kerberos.
However, none of these protocols can be used by a Web browser to authenticate a user to a Web server because Web browsers and Web servers can use only Hypertext Transfer Protocol (HTTP) to communicate. Web browsers must authenticate to Web servers using an authentication protocol that is contained within HTTP. Administrators configuring an IIS server have several authentication options that differ in how they pass the credentials to IIS and which browsers support them:
■ Basic Authentication. Selecting this option enables browsers to submit the user’s password in an encoded format that is equivalent to clear text. If the authentication traffic is intercepted, an attacker could easily determine the user’s password.
While this authentication method is vulnerable to being intercepted, it is supported by a wide range of browsers.
■ Digest Authentication For Windows Domain Servers. Selecting this option allows the Web browser to submit the user’s password in an MD5 hash. If digest authentication traffic is intercepted, an attacker would be able to easily determine the user’s password.
■ Integrated Windows Authentication. Selecting this option enables Kerberos v5 authentication and NTLM authentication within the Web requests. This allows the Web browser to send the user’s password in the form of a hash without requiring the user’s password to be stored using reversible encryption.
■ .NET Passport Authentication. Select this option if your organization is using the .NET Passport service for authentication. .NET Passport provides a central authentication service that many different organizations can use and allows users to authenticate themselves to many different, unrelated Web sites.
