miércoles, 22 de junio de 2011

CHAPTER 6 (II)


MORE INFO
CONFIGURING L2TP/IPSEC FOR NAT TRAVERSAL
For instructions on performing the registry edit to enable NAT traversal in L2TP/IPSec, visit http://support.microsoft.com/kb/926179.
Understanding PPTP
PPTP is the easiest VPN protocol to implement in Windows networks. Unlike other tunneling protocols, PPTP does not require any certificates or pre-shared keys on either the VPN client or server. Another important feature of PPTP is that it can be used with older Windows operating systems: It is the only native Windows VPN protocol that can run on Microsoft Windows NT 4.0, and it is compatible with all versions of Windows since Microsoft Windows 2000. PPTP, however, includes significant disadvantages, the biggest of which is that it is not as secure as other VPN protocols. Although PPTP does encrypt data, it does not ensure data integrity or data origin authentication. Another important limitation to PPTP is that it can traverse NAT devices only through PPTP-enabled NAT routers.
Table 6-1 compares important features of the four VPN protocols available in Windows networks.
TABLE 6-1 VPN Protocols in Windows Networks
VPN PROTOCOL               OS SUPPORT     SCENARIO          TRAVERSAL        VPN RECONNECT/MOBILITY      AUTHENTICATION
IKEv2     Windows 7,Windows Server 2008 R2     Remote Access                NAT       Yes         Machine or user authentication via IKEv2; VPN server requires a server certificate
SSTP      Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2           Remote Access                NAT, Firewalls, Web Proxy     No          User authentication via Pointto-Point Protocol (PPP); VPN server requires server certificate
L2TP/IPSec         Windows 2000 and later              Remote Access, Site-to-Site      NAT, only with a special registry fix        No                 Machine authentication via IPSec followed by user authentication via PPP; VPN client requires a computer certificate or a pre-shared key
PPTP     Windows NT 4.0, Windows 2000, and later.        Remote Access, Site-to-Site      NAT, only through PPTP-enabled NAT routers No          User authentication via PPP

Understanding the Remote Access VPN Connectivity Process
When a VPN client requests access to a corporate network running Windows, a number of steps need to occur before the client is able to connect to that network successfully. If  an error occurs at any stage of the process, no connectivity will be established. Knowing the steps in the VPN connection process is a prerequisite for troubleshooting because it enables you to understand how particular connection failures might relate to particular errors in your VPN configuration.

Remote access VPN connectivity occurs in the following steps:
1. The VPN client contacts the VPN server.
In the first stage of a VPN connection attempt, the VPN client attempts to contact the VPN server. Successful completion of this stage requires the client to be properly configured with  the IP address of the VPN server. The VPN server also needs to be publicly available. If the VPN server is located behind a firewall, the firewall needs to be configured to allow the  VPN client access.
2. The VPN tunnel is negotiated.
After the VPN client contacts the VPN server, it submits a request for a tunnel type. A VPN network connection can be set to any of five settings: Automatic, PPTP, L2TP/IPSec, SSTP, and IKEv2, as shown in Figure 6-12.

FIGURE 6-12 Configuring the VPN type
The default setting is Automatic. According to this setting, the VPN connection makes VPN protocol requests prioritized in the following order: IKEv2, SSTP, L2TP/IPSec, and PPTP. The VPN type that is negotiated eventually is the first for which the VPN server can answer the request.
During this phase, the authentication protocol is also negotiated. For IKEv2 VPNs,  the EAP-MSCHAPv2 authentication protocol is used. For other VPN types, MS-CHAPv2 is preferred if it is also available on the VPN server. Otherwise, CHAP is requested.
Finally, encryption is negotiated during this phase. Like authentication settings, encryption settings are defined on the Security tab in a VPN connection Properties dialog box in Windows 7, as shown in Figure 6-13. For encryption to be negotiated properly, the client settings defined here must be compatible with those defined on the VPN server. For example, if Maximum Strength Encryption is defined on the client, the server must be able to provide maximum strength encryption or the VPN connection fails.

FIGURE 6-13 Configuring data encryption in the VPN connection
3. The VPN tunnel is created. If the VPN tunnel type, authentication protocol, and encryption strength can be agreed upon, the VPN tunnel is created between the VPN client and  PN server. After this point, all exchanges are encrypted. In the case of IKEv2 and SSTP VPNs, the tunnel creation is performed with the help of the VPN server’s computer certificate. The VPN client must therefore be able to validate the certificate; to do so, the certificate of the issuing root CA must be installed in the Trusted Root Certification Authorities store on the VPN client computer. In the case of L2TP/IPSec VPNs, pre-shared keys or computer certificates are used to create the encryption terms for the tunnel. These elements must therefore be configured properly for the negotiation to work. (PPTP VPNs use Microsoft Point-to-Point Encryption to create the secure tunnel and do not require a PKI.)
A final requirement for a VPN tunnel to be negotiated is that the VPN client-server communication must be able to traverse the network elements that lie between them. For example, if a firewall is located between the VPN client and server, the ports used by the VPN protocol must be left open. If a NAT device is located between the VPN client and server, the VPN protocol must be able to traverse that NAT device.
4. Remote access authentication is performed. During this phase, the user credentials submitted with the VPN connection request are sent to the VPN server by using the previously agreed upon authentication protocol. The VPN server then either performs the authentication locally, or forwards the authentication request to an available domain controller, or forwards the authentication request to a RADIUS server. For this step to occur, the VPN user must submit proper credentials, and the VPN server must be configured to forward the
authentication to the appropriate location.
5. Remote access authorization is performed. In this phase, the user account properties are checked to verify that the user is authorized for remote access. Then, the list of network policies configured on the VPN server or NPS server is checked. The first policy whose conditions match the connection request is applied to that request and then either allows or denies the request. Note that constraints (such as time of day) that affect the authorization of the connection request might also be defined in the policy.
6. The VPN connection is established. If the remote access connection request is authorized, the VPN server allows the VPN user to log on to the domain. After domain logon occurs, the VPN user has access to the corporate network.
Troubleshooting VPN Client Connectivity
Use the following list to help you troubleshoot VPN client connectivity:
Verify that the VPN client connection is configured properly with the VPN server name or IP address.
Verify that the VPN client computer has an active Internet connection. The VPN connection can be established only when the client is connected to the Internet.
Verify that the proper user credentials are defined in the VPN connection.
Verify that the user is authorized for remote access.
Verify that certificates are configured properly for the VPN connection. For instance, verify that the certificate of the root CA that has issued the VPN server’s computer certificate is installed in the Trusted Root Certification Authorities store on the VPN client computer. In the case of an L2TP/IPSec VPN, verify that the VPN client computer has installed a computer certificate that can be validated by the VPN server.
If an error message with code 741 appears and indicates that the local computer does not support encryption, verify that that encryption settings defined in the VPN connection are compatible with those defined on the server.
PRACTICE Creating an IKEv2 VPN Connection
In this practice, you create a simulated IKEv2 VPN connection between a client running Windows 7 and a server running Windows Server 2008 R2. Note that the two-computer network used in this practice does not approximate the environment in which such a connection would be used in the real world. In a real-world scenario, a VPN connection would link a client on the Internet through a firewall to a VPN server, which would be a member server of the local Active Directory Domain Services (AD DS) domain. A separate server acting as a domain controller would be used to authenticate the user. Yet another server would act as the certificate server used to generate the certificates for the connection. Instead of that scenario, this practice has a single server running Windows Server 2008 R2 acting as the VPN server, domain controller, and certificate server.
In this practice, you perform the following steps:
1. On the domain controller, you create a domain user account and assign that user account the Allow Access dial-up permission. (Exercise 1)
2. You install Active Directory Certificate Services on the server. Using Certificate Services, you generate both a server authentication certificate to be installed on the server and a root CA certificate to be installed on the client. (Exercises 2–8)
3. You install and configure the Network Policy and Access Services server role on the server; this step enables the server to receive and route VPN connections. (Exercises 9–11)
4. You create and test the VPN connection on the client. (Exercises 12–13) To prepare for this practice, name the server DC1.nwtraders.msft and the client Client1.nwtraders.msft. Configure both computers with a single network adapter and connect them to the same network. DC1 should be a domain controller in the Nwtraders.msft domain and Client1 should be a member of the same domain. DC1 should be configured only with the following roles:
AD DS
DHCP Server
DNS Server
NOTE
 REMOVE ANY OTHER ROLES
If any other roles have been installed on DC1, remove them before beginning this practice. (You can make an exception for the Active Directory Certificate Services server role. If  you installed this role when the server was named DC1.nwtraders.msft, you can leave the role installed.) Note also that if you have installed the Routing and Remote Access Services role service of the Network Policy and Access Services server role, you should first disable the Routing and Remote Access service before removing this associated server role. Finally, when removing the server roles, use the same domain administrator account that you will use during the practice exercises.
EXERCISE 1
Creating a Domain User with Network Access Permissions
In this exercise, you create a domain user account in Active Directory Users And Computers and then grant that user account the Allow Access network access permission.
1. Log on Nwtraders from DC1 as a domain administrator.
2. Open the Active Directory Users And Computers console by clicking Start, clicking Administrative Tools, and then clicking Active Directory Users And Computers.
3. In the Active Directory Users And Computers console tree, expand nwtraders.msft, right-click Users, click New, and then click User.
4. On the first page of the New Object-User wizard, enter into the corresponding fields a first name, last name, and user logon name that you want to give a VPN user, and then click Next.
5. On the second page of the New Object-User wizard, enter a password into the Password and Confirm Password text boxes.
6. Clear the check box next to User Must Change Password At Next Logon, and then click Next.
7. On the Final page of the New Object-User wizard, click Finish.
8. In the Active Directory Users And Computers console, locate and then open the properties for the user account you just created.
9. In the Properties dialog box, on the Dial-in tab, click Allow Access in the Network Access Permission area.
10. Click OK to close the user Properties dialog box.
EXERCISE 2
Installing Active Directory Certificate Services and Web Server (IIS)
Server Roles
NOTE
HAVE YOU ALREADY INSTALLED THESE SERVER ROLES?
You can skip this exercise if you have performed “Exercise 2: Issue an Untrusted Certificate,” in Lesson 2 of Chapter 4, “Security.” In this case, you have already installed the Certification Authority and Certification Authority Web Enrollment role services of the Active Directory Certificate Services server role on the domain controller. If these role services are installed  on your domain controller, skip this exercise and move to Exercise 3.
In this exercise, you install the Certification Authority and Certification Authority Web Enrollment role services of the Active Directory Certificate Services server role. Choosing the second of these role services initiates the additional installation of the Web Server (IIS) role. Together, these features are needed to create the infrastructure needed to support IKEv2-enabled VPN connections.
Perform the steps in this exercise while you are still logged on to DC1 as a domain administrator.
1. In Server Manager, select the Roles node and then click Add Roles in the Roles Summary area of the details pane.
The Add Roles Wizard opens.
2. On the Before You Begin page, click Next.
3. On the Select Server Roles page, select Active Directory Certificate Services, and then click Next.
4. On the Introduction To Active Directory Certificate Services page, read all the text on the page, and then click Next.
5. On the Select Role Services page, select both Certification Authority and Certification Authority Web Enrollment.
6. In the Add Role Services And Features Required For Certification Authority Web Enrollment? dialog box, click Add Required Role Services.
7. Click Next.
8. On the Specify Setup Type, verify that Enterprise is selected, and then click Next.
9. On the Specify CA Type page, verify that Root CA is selected, and then click Next
10. On the Set Up Private Key page, verify that Create A New Private Key is selected, and then click Next.
11. On the Configure Cryptography For CA page, click Next to accept the default cryptographic settings.
12. On the Configure CA Name page, click Next to accept the default CA common name and suffix.
13. On the Set Validity Period page, click Next to accept the default validity period.
14. On the Configure Certificate Database page, click Next to accept the default locations.
15. On the Web Server (IIS) page, click Next.
16. On the Select Role Services page, click Next to accept the default choices.
17. In the Confirm Installation Selections dialog box, click Install. The installation might take several minutes. When the installation completes, the Installation Results page appears.
18. On the Installation Results page, click Close.
EXERCISE 3
Creating and Issuing a Certificate Template
After you install Active Directory Certificate Services, you must use the new CA on DC1 to generate a server certificate. This server certificate will be used later to authenticate
the VPN server.
No certificate template exists by default for the kind of server certificate needed to authenticate a VPN server for an IKEv2 connection. Before you can submit a request to the CA for such a certificate, then, you need to create a certificate template that includes the proper extended key usage (EKU) options: Server Authentication and IP Security IKE Intermediate.
In this exercise, you create a certificate template that will enable you to request a server certificate with the required EKU options applied. Perform the steps in this exercise while you are still logged on to DC1 as a domain administrator.
1. Open the Certification Authority console by clicking Start, clicking Administrative Tools, and then clicking Certification Authority.
2. In the Certification Authority console tree, expand the nwtraders-DC1-CA node.
3. Right-click Certificate Templates, and then click Manage. The Certificate Templates Console appears.
4. In the details pane, locate and right-click the IPSec template in the list, and then click Duplicate Template.
5. In the Duplicate Template dialog box, verify that Windows Server 2003 Enterprise is selected, and then click OK. The Properties Of New Template dialog box opens.
6. On the General tab, change the Template Display Name to IKEv2 VPN.
7. On the Request Handling tab, select Allow Private Key To Be Exported.
8. On the Subject Name tab, select Supply In The Request. If a message box appears, click OK to dismiss the message.
9. On the Extensions tab, verify that Application Policies is selected, and then click Edit.  he IP Security IKE Intermediate policy is already present in the list of application policies.
10. Click Add, select Server Authentication, and then click OK.
11. Click OK to return to the Extensions tab.
12. Click OK to save your completed template.
13. Close the Certificate Templates Console window.
14. In the Certification Authority console tree, right-click Certificate Templates, select New, and then click Certificate Template To Issue.
15. In the Enable Certificate Templates dialog box, select IKEv2 VPN, and then click OK.
16. Restart DC1.
EXERCISE 4
Configuring Windows Internet Explorer to Allow Certificate Publishing
The new certificate template is now ready to be used for certificate requests. Before you can request one, however, you must configure Windows Internet Explorer security settings to work with the certificate publishing web page.
1. Log on to DC1 as a domain administrator.
2. Click Start, right-click Internet Explorer, and then click Run As Administrator.
3. Click Tools, and then click Internet Options.
4. On the Security tab, under Select A Zone To View Or Change Security Settings, click Local Intranet.
5. In the Security Level For This Zone area, change the security level for Local Intranet from Medium-low to Low, and then click OK.
NOTE CUSTOM LEVEL IS PREFERABLE
In a real-world scenario, it is preferable to adjust the individual ActiveX control settings by using Custom Level than to lower the overall security level.
EXERCISE 5
Requesting a Server Authentication Certificate by Using Internet Explorer
After you have adjusted its security settings, Internet Explorer is now ready to be used to request and install certificates on the local computer. In this exercise, you perform this action. You do this while still logged on to DC1 as a domain administrator.
1. In the Internet Explorer address bar, type http://localhost/certsrv, and then press Enter.
2. Under Select A Task, click Request A Certificate.
3. Under Request A Certificate, click Advanced Certificate Request.
4. Under Advanced Certificate Request, click Create And Submit A Request To This CA.
5. On the first confirmation dialog box, click Yes to allow the ActiveX control.
6. On the second confirmation dialog box, click Yes to allow the certificate operation.
7. In the Certificate Template list, select IKEv2 VPN.
8. Under Identifying Information, in the Name field, type DC1.nwtraders.msft.
NOTE
USE THIS SAME NAME IN THE CONNECTION SETTINGS
The name is the certificate subject name and must be the same as the Internet address
used in the IKEv2 connection settings configured in Exercise 12 in this practice.
9. Under Key Options, verify that Mark Keys As Exportable is selected, and then click Submit.
10. Click Yes in each of the confirmation dialog boxes.
11. Click Install This Certificate. A message appears indicating that the certificate has been installed.

No hay comentarios:

Publicar un comentario