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
Troubleshooting Internet Access
1- Check DNS name resolution If the client cannot resolve the DNS name of the Internet resource, the client will not be able to connect to the resource. To check if the client can resolve the DNS name, ping the FQDN of the Internet resource. Even if you can not ping the server, you can use the ping to determine if the client resolved the FQDN to the correct IP address. If the client did not resolve the DNS name correctly, then check the client DNS configuration and the DNS server used
by the client. Also check the access rules on ISA Server to ensure that DNS queries from the internal network can be forwarded to the Internet DNS servers.
2- Determine the extent of the problem An important troubleshooting step is to attempt to identify the cause of the problem by isolating who is affected by the problem. For example, if only one user or group of users is affected then the issue is likely a configuration error on an ISA Server access rule. If only one Web site is inaccessible, then the problem may be with an access rule configuration, or the
Web site may be unavailable. If all computers are affected, then you must check the ISA Server configuration and network connectivity. If only one computer is affected, then check the network connectivity and client configuration on that one computer.
3- Review access rule objects and access rule configuration After determining the extent of the problem, review the access rule configurations that specifically relate to the affected users. For example, if a group of users is affected, then look for access rules or access rule elements that apply specifically to that group.
4- Review access rule order ISA Server evaluates access rules in the order listed in ISA Server Management. The first rule that matches the client request is applied to the request. For example, if an access rule that allows access to all Web sites using HTTP is listed first, other access rules that set restrictions on which Web sites can be accessed will not be evaluated.
5- Check access rule authentication If an access rule requires authentication,then ensure that the ISA Server clients support the authentication protocol configured for the access rule. Also ensure that all users are using Web Proxy or Firewall clients because SecureNAT clients do not support authentication. The access rule order is also important when using access rules that require authentication. For example, if an access rule that allows Internet access using all protocols but only
for members of a particular group is evaluated first, all users that are not members of that group will not be able to access the Internet.
One of the useful tools provided with ISA Server for troubleshooting access to resources on other networks is the logging feature. By default, ISA Server logs all Web Proxy and Firewall client connections to the Internet. You can use these logs to determine which access rules are allowing or blocking access.
To view the information logged by ISA Server, complete the following steps:
1. In ISA Server Management, click Monitoring.
2. Click the Logging tab.
3. To view the information being logged at the current time, click Start Query. To use this option, start the query and then attempt to access the Internet resource from the client computer. You can view the client connection attempts in the log viewer.
4. To view archived information or to limit the number of entries in the log viewer, configure a filter to view specific information contained within the log files. For example, you could configure a filter that allowed you to view all the client connection attempts from a specific client computer over a specified period.
Maintaining ISA Server 2004
Among the new features in ISA Server 2004 is the option to export and import the ISA Server configuration. With this option, you can save and restore the ISA Server configuration information. When you use the ISA Server export feature, the configuration parameters are exported and stored in an .xml file. The import and export features are useful in several scenarios:
1- Cloning a server You can export a configuration from one ISA Server computer and then import the settings on another computer, thereby easily duplicating a server configuration. For example, after configuring an ISA Server computer at one branch office, you can export the configuration to an .xml file. Then you can import the file on a computer running ISA Server at another branch office. The two ISA Server computers will have a duplicate configuration.
2- Saving a partial configuration You can export and import any part of the ISA Server configuration. For example, you can export a single rule, an entire policy, or an entire configuration. This is helpful when you want to copy all the firewall policy rules, but not the monitoring configuration, from one ISA Server to another. This is also useful when you want to modify a specific rule. You can export that rule and have the exported configuration available in case you need to roll back the rule modification.
3- Sending a configuration for troubleshooting You can export your configuration information to a file and send it to support professionals for analysis and troubleshooting.
4- Rolling back a configuration change As a best practice, before modifying any ISA Server settings you should export the specific component that you are modifying. If your modification is not successful, you can easily restore the previous configuration by importing the policy file.
You can export the entire ISA Server configuration, or just parts of it, depending on your specific needs. You can export the following objects:
1- The entire ISA Server configuration
2- All the connectivity verifiers, or one selected connectivity verifier
3- All the networks, or one selected network
4- All the network sets, or one selected network set
5- All the network rules, or one selected network rule
6- All the Web chaining rules, or one selected Web chaining rule
7- Cache configuration
8- All the content-download jobs, or one or more selected content-download jobs
9- The entire firewall policy, or one selected rule.
When you export an entire configuration, all general configuration information is exported. This includes access rules, publishing rules, rule elements, alert configuration, cache configuration, and ISA Server properties. In addition, you can choose to export user permission settings and confidential information such as user passwords. Confidential information included in the exported file is encrypted.
To export the ISA Server configuration, complete the following procedure:
1. Open ISA Server Management.
2. Select the object the settings of which you want to export. Remember if you select
a container object (such as the Firewall Policy), all the objects in the container will be exported.
3. On the Tasks tab, click the Export task. The exact name for the task will vary depending on the type of object that you select.
4. Enter a file name for the exported .xml file and click Export.
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.
3 - Hardening Computers for Specific Roles :
Lesson 1: Tuning Security for Client Roles :
Planning Managed Client Computers :
When planning the requirements for managed client computers, start by identifying the baseline security level that is appropriate for users to have on their computers. The baseline user security level is specified by granting users membership to one of these groups: Users, Power Users, and Administrators. Membership in the Users group gives the most protection from a number of external threats, such as viruses, and it limits the damage that users can accidentally or intentionally cause to their computers. However, user level permissions have the most incompatibility problems with older applications. Take particular care before you give users privileged access to computers that they
share with other employees.
Next, identify the types of systems users need to interoperate with. Interoperability with earlier systems, such as Microsoft Windows NT 4.0–based servers and UNIX file servers, necessitates that some of the security you might use in a pure Windows Server 2003 environment must be relaxed.
Finally, consider the level of support users provide for their own computers. Users who use portable computers and provide their own support might require administrator rights on their computers. Other high-performance users, such as developers, might also need administrative rights.
Software restriction policies are a feature in Windows XP and Windows Server 2003 that can be used to regulate unknown or untrusted software. Businesses that do not use software restriction policies put the burden of identifying safe and unsafe software on the users. Users who access the Internet must constantly make decisions about running unknown software. Malicious users intentionally disguise viruses and Trojans to trick users into running them. It is difficult for users to make safe choices about what software they should run.
With software restriction policies, you can protect your network from untrusted software by identifying and specifying the software that is allowed to run. You can define a default security level of Unrestricted or Disallowed for a Group Policy object (GPO) so that software is either allowed or not allowed to run by default. You can make exceptions to this default security level by creating software restriction policy rules for specific software. For example, if the default security level is set to Disallowed, you can create rules that allow specific software to run.
Security for Desktop Computers :
When a computer manufacturer delivers a new computer to an organization, the operating system is generally configured to provide the greatest flexibility to the typical user. Many organizations have additional software installed on top of the operating system, such as Microsoft Office. This provides power users with the tools they need to do their jobs.
However, many types of employees do not require much flexibility and will actually be more productive if the software on their computers is restricted. For example, a user in the accounts payable department might only need access to an e-mail client, accounting software, and a Web browser. For this type of user, restricting the applications they can run can make them more productive (for example, by removing Solitaire). Additionally, it can reduce the risk of malicious software, such as viruses and Trojans, infecting the computer.
In a typical restricted desktop computer role, the desktop and Start menu are significantly simplified. Users cannot make extensive customizations, other than a limited number of application-specific settings. Applications are typically allocated to users based on their job roles, and users cannot add or remove applications. This type of desktop configuration is appropriate in a marketing or finance department, for example.
In these areas, users require only a specific and limited set (typically three to five) of productivity and in-house applications to do their jobs.
Security for Mobile Computers :
Mobile computers require that you attend to several additional security considerations beyond those of desktop computers. Mobile users might use their computers while traveling, which might require them to perform administrative tasks that a member of the IT group would normally perform. For example, a mobile user might need to print a document using a different printer than the one installed in the office, and would need to install the correct printer driver. To allow this, disable the Devices: Prevent Users From Installing Printer Drivers security option. If you anticipate that users who work away from the office will need to install or reinstall applications while working remotely, you might want to enable the Always Install With Elevated Privileges setting in the Administrative Templates\Windows Components\Windows Installer node.
Mobile users might connect to foreign networks, such as a wireless hotspot at a coffee shop. These foreign networks won’t have the benefit of your organization’s network security, so mobile users have an elevated risk of being attacked across the network. To mitigate this risk, enable the Internet Connection Firewall (ICF, known in Service Pack 2 as Windows Firewall) on all network interfaces for mobile computers. Unfortunately, ICF cannot be configured by using Group Policy settings. Lesson 2 in this chapter contains more information about firewalls.
Lesson Summary
■ Software restriction policies can be applied to a GPO to restrict the applications that can run on a target system. Software restriction policies can restrict applications based on a hash of the executable file, the path in the file system, a certificate associated with the application, or the Internet zone from which the application is running.
■ You should create security templates for the various computer roles in your organizations, including desktop computers, mobile computers, and kiosks. Whenever possible, you should base these templates on a predefined security template.
■ Security templates are useful for creating GPOs, but they contain only a subset of the settings available when configuring a GPO. Therefore, after importing a security template into a GPO, you might have to use the Group Policy Object Editor to specify additional settings.
■ Mobile computers have different security considerations than desktop computers. Mobile computers are subject to a wider array of network attacks because they might connect to unprotected networks. Additionally, they are more likely to be stolen, so encryption of the disk’s physical contents might be necessary.
■ Kiosks require security settings that are tightly restricted to prevent abuse. GPOs allow an administrator to remove all major user interface elements and configure kiosk computers to log on a user and launch a single application automatically at startup.
