Implementing a VPN infrastructure must be planned carefully because you are deliberately exposing your internal network to the Internet. In many cases, VPN clients have complete access to the internal network, just as if the client computer were connected to the internal network behind the ISA Server computer. This means that your VPN implementation must be as secure as possible.
Use the following guidelines when planning your ISA Server VPN implementation:
1- For the highest level of security, implement a VPN solution that uses L2TP/IPSec,MS-CHAP v2, or EAP/TLS for user authentication and certificate-based authentication for computer authentication. With this configuration, you must deploy certificates to all remote-access clients. However, the certificate authentication means that only computers that have the appropriate certificate will be able to connect.
2- You can also deploy PPTP using certificate-based authentication. In this scenario,you can use two-factor authentication, with devices such as smart cards, to ensure the identity of the remote client. Although this option provides a more secure means to authenticate the remote-access user, it does not provide an option for authenticating the remote-access client computer.
3- If you do not have the option of deploying client certificates to all VPN clients or using smart cards, the most secure option is to use PPTP with password authentication. When you use PPTP, the data is encrypted; however, the authentication mechanism is not as secure. If you use password-based authentication, ensure that you enforce strong passwords by using Group Policy.
4- Always use the most secure protocols that both your VPN access servers and clients can support and configure the remote-access server and the authenticating server to accept only secure authentication protocols. If you have older VPN clients that do not support secure authentication protocols, consider not enabling VPN access for these clients. Only enable VPN access for these clients if there is a strong business need to do so, and if you do not have the option of upgrading the clients.
5- ISA Server 2004 allows you to use pre-shared keys in place of certificates when creating remote-access and gateway-to-gateway VPN connections. Pre-shared keysupport for IPSec-based VPN connections should be used only for testing purposes. A single remote-access server can use only one pre-shared key for all L2TP/IPSec connections requiring a pre-shared key for authentication. This means that you must issue the same pre-shared key to all L2TP/IPSec VPN clients. Unless you distribute the pre-shared key within a Connection Manager profile, each user must manually enter the pre-shared key into the VPN client software settings. This reduces the security of the L2TP/IPSec VPN deployment.
6- Using RADIUS for authentication does not increase the level of security for VPN connections. The only advantage of using RADIUS is that you can centralize policy management for multiple ISA Server computers acting as VPN remote-access servers.
7- Using SecurID can significantly increase the level of security for the VPN connections because SecurID requires access to the token that provides a one use password. However, deploying SecurID significantly increases the complexity of the VPN server deployment.
Affichage des articles dont le libellé est group. Afficher tous les articles
Affichage des articles dont le libellé est group. Afficher tous les articles
Guidelines for Planning a VPN Infrastructure
Troubleshooting Internet Access
ISA Server uses access rules to grant internal users access to Internet resources. In some cases, you may need to troubleshoot these access rules to ensure that a user can access the required resources. Use the following guidelines to troubleshoot Internet access issues:
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.
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.
Inscription à :
Articles (Atom)
