لطفا منتظر باشید ...
Using RADIUS for VPN Authentication and Remote Access Policy
We prefer to not join front-end ISA firewalls to the user domain. The reason for this is that the network segments between the front-end ISA firewall and back-end firewalls are unauthenticated DMZ segments, and we want to avoid passing domain information through those segments as much as possible.
When the ISA firewall is not a member of the user domain, we must use a mechanism other than Windows to authenticate and authorize domain users. The ISA firewall can authenticate VPN users with RADIUS (Remote Access Dial-In User Service). The RADIUS Protocol allows the ISA 2004 firewall to forward user credentials of a RADIUS server on the Internal network. The RADIUS server sends the authentication request to an authentication server, such as an Active Directory domain controller. The Microsoft implementation of RADIUS is the Internet Authentication Service (IAS).
In addition to authenticating users, the IAS server can be used to centralize Remote Access Policy. For example, if you have six ISA firewall/VPN servers under your administrative control, you can apply the same Remote Access Policy to all these machines by creating policy on an IAS server on your network.
The ISA firewall is not limited to working with just IAS, and it supports all types of RADIUS servers. However, the Microsoft IAS server is included with all Windows 2000 and Windows Server 2003 server family products, which makes it very convenient to use for any Microsoft shop.
In this section we will discuss procedures required to enable RADIUS authentication and RADIUS Remote Access Policy for VPN clients. We will carry out the following procedures:
Configure the IAS Server
Create a VPN Clients Remote Access Policy
Enable the VPN Server on the ISA 2004 firewall and configure RADIUS Support
Create a VPN Client Access Rule
Make the connection from a PPTP VPN client
Configure the Internet Authentication Services (RADIUS) Server
If you have not installed the IAS server, you can install it now using the Add/Remove Programs Control Panel applet on your Windows 2000 or Windows Server 2003 machines on the Internal Network. You need to configure the IAS server to communicate with the Active Directory and then instruct the IAS server to work with the ISA 2004 firewall/VPN server machine. In our current example, the IAS server is installed on the domain controller on the Internal Network (EXCHANGE2003BE).
Perform the following steps to configure the IAS server:
Click Start; point to Administrative Tools, and click on Internet Authentication Services.
In the Internet Authentication Services console, right-click on the Internet Authentication Service (Local) node in the left pane of the console. Click the Register Server in Active Directory command.
This setting allows the IAS Server to authenticate users in the Active Directory domain. Click OK in the Register Internet Authentication Server in Active Directory dialog box.
Click OK in the Server registered: dialog box. This dialog box informs you that the IAS Server was registered in a specific domain and if you want this IAS Server to read users' dial-in properties from other domains, you'll need to enter this server into the RAS/IAS Server Group in that domain. This automatically places the machine in the RAS and IAS Server Group in the Active Directory. If you want to register the server in another domain, you must place it in the RAS and IAS Servers group in that domain or use the command netsh ras add registeredserver Domain IASServer command.
Right-click on the RADIUS Clients node in the left pane of the console, and click the New RADIUS Client command.
In the New RADIUS Client dialog box, type in a Friendly name for the ISA firewall. You can use any name you like. In this example we'll use the DNS host name of the ISA firewall, which is ISALOCAL. Enter either the FQDN or the IP address of the ISA 2004 firewall/VPN server in the Client address (IP or DNS) dialog box. Do not enter a FQDN if your ISA firewall has not registered its internal interface IP address with your internal DNS server. You can use the Verify button to test whether the IAS Server can resolve the FQDN. Click Next.
On the Additional Information page, leave the RADIUS Standard entry in the Client-Vendor drop-down list box. Your ISA firewall will use this setting. Enter a complex shared secret in the Shared secret text box, and confirm it in the Confirm shared secret text box. The shared secret should be a complex string consisting of upper and lower case letters, numbers, and symbols. Put a checkmark in the Request must contain the Message Authenticator attribute checkbox. This option enhances the security of the RADIUS messages passed between the ISA firewall and IAS servers. Click Finish. See Figure 9.45.
Figure 9.45: Configuring the Shared Secret
| Warning | The shared secret should be very long and complex. We recommend that it be at least 20 characters and contain a mix of upper and lower case letters, numbers, and symbols. |
Create a VPN Clients Remote Access Policy
We're now ready to create a Remote Access Policy on the IAS Server. Remote Access Policies configured on the IAS Server are applied to VPN client connections made to the ISA firewall when the ISA firewall is configured to use RADIUS authentication and policy, and when the ISA firewall is configured as a RADIUS client. Fortunately for us, the Windows Server 2003 IAS server has a Remote Access Policy Wizard that makes it easy to create a secure VPN client Remote Access Policy.
Perform the following steps to create a VPN client Remote Access Policy on the IAS Server:
In the Internet Authentication Service console, right-click on the Remote Access Policies node, and click the New Remote Access Policy command.
Click Next on the Welcome to the New Remote Access Policy Wizard page.
On the Policy Configuration Method page, select Use the wizard to set up a typical policy for a common scenario. In the Policy name text box, type a name for the policy. In this example, we'll call it VPN Access Policy. Click Next.
Select the VPN option on the Access Method page. This policy is used for all VPN connections. You have the option to create separate policies for PPTP and L2TP/IPSec VPN links. However, to create separate policies for PPTP and L2TP/IPSec connections, you'll need to go back to the previous page in the Wizard and create two custom policies. In this example, we apply the same policy to all remote access VPN connections. Click Next.
You can grant access to the VPN server based on user or group. The best access control method is on a per-group basis because it entails less administrative overhead. You can create a group such as VPN Users and allow them access, or allow all your users access. In this example, we will select the Group option and click the Add button. This brings up the Select Groups dialog box. Enter the name of the group in for Enter the object name to select, and click Check names to confirm that you entered the name correctly. In this example, use the Domain Users group. Click OK in the Select Groups dialog box and Next in the User or Group Access dialog box.
Select user authentication methods you want to allow on the Authentication Methods page. You may wish to allow both Microsoft Encrypted Authentication version 2 and Extensible Authentication Protocol (EAP). Both EAP and MS-CHAP version 2 authentication are secure, so we'll select both the Extensible Authentication Protocol (EAP) and Microsoft Encrypted Authentication version 2 (MS-CHAPv2) checkboxes. Click the down arrow from the Type (based on method of access and network configuration) drop-down list and select the Smart Card or other certificate option, then click the Configure button (as shown in Figure 9.46). In the Smart Card or other Certificate Properties dialog box, select the certificate you want the server to use to identify itself to VPN clients. The self-signed certificate appears in the Certificate issued to drop-down list. This certificate is used to identify the server when VPN clients are configured to confirm the server's validity. Click OK in the Smart Card or other Certificate Properties dialog box (as shown in Figure 9.47), and then click Next.
Figure 9.46: The Authentication Method Page
Figure 9.47: The Smart Card or other Certificate Properties Dialog Box
Select the level(s) of encryption you want to enforce on VPN connections. All Microsoft clients support the strongest level of encryption. If you have clients that don't support 128 bit encryption, select lower levels, but realize that you lower the level of security provided by the encryption method used by the VPN protocol. In this example, we'll select all three options (see Figure 9.48). In a high-security environment, you should select on the strongest encryption option. Just make sure all your VPN clients support this level of encryption. Click Next.
Figure 9.48: The Policy Encrypted Level
Review your settings on the Completing the New Remote Access Policy Wizard page and click Finish.
Remote Access Permissions and Domain Functional Level
The new Remote Access Policy requires the connection be a VPN connection. The VPN protocol can be either PPTP or L2TP/IPSec. The VPN client must use MS-CHAP v2 or EAP-TLS to authenticate, and the client must support the level of encryption set in the Remote Access Policy. The user must belong to the Domain Users group in the domain specified in the Remote Access Policy.
The next step is to configure Remote Access Permissions. Remote Access Permissions are different than Remote Access Policies.
When a VPN user calls the ISA firewall, the parameters of the connection are compared against Remote Access Policy (the remote access policy can be either on the ISA firewall itself or on a IAS server). Remote Access Policies are represented as a hierarchical list. The policy on top of the list is evaluated first, then the second-listed policy is evaluated, then the third, and so forth.
The VPN client's connection parameters are compared to the conditions in the policy. In the remote access policy we created above, there were two conditions:
The connection type is a virtual connection, and
The user is a member of the Domain Users group.
If the connection request matches both of those conditions, then Remote Access Permissions are determined. Remote access permissions are determined differently depending on the type of domain the user account belongs to.
Windows Server 2003 domains do not use the Mixed and Native Mode designations you might be familiar with in Windows 2000. Windows Server 2003 supports domains of varying functional levels. If all the domain controllers in your domain run Windows Server 2003, the default functional level is Windows 2000 mixed. All user accounts are denied VPN (Dial-up) access by default in Windows 2000 Mixed Mode functional level. In Windows 2000 Mixed Mode, you must configure each user account to have permission to log on to the VPN server. The reason is that user account permissions override Remote Access Policy permissions in Mixed Mode domains.
If you want to control Remote Access Permissions via Remote Access Policy, you must raise the domain functional level to Windows 2000 Native or Windows Server 2003. The default Remote Access Permission in Windows 2000 and Windows Server 2003 domains is Control access through Remote Access Policy. Once you are able to use Remote Access Policy to assign VPN access permission, you can take advantage of group membership to allow or deny VPN access to the VPN server.
When a VPN connection matches the conditions in the Remote Access Policy, and the user is granted access via either the user account Dial-in settings or Remote Access Policy, then the VPN connection parameters are compared to a number of settings defined by the Remote Access Profile. If the incoming connection does not comply with the settings in the Remote Access Profile, then the next Remote Access Policy is compared to the connection. If no policy matches the incoming connection's parameters, the VPN connection request to the ISA firewall is dropped.
The VPN Remote Access Policy you created earlier includes all the parameters required for a secure VPN connection. Your decision now centers on how you want to control Remote Access Permissions:
Enable Remote Access on a per group basis: this requires that you run in Windows 2000 Native or Windows Server 2003 functional level.
Enable Remote Access on a per user basis: supported by Windows 2000 Native, Windows 2000 Mixed and Windows Server 2003 functional levels.
Enable Remote Access on both a per user and per group basis: this requires Windows 2000 Native or Windows Server 2003 functional level; granular user-based access control overriding group-based access control is done on a per user basis.
Procedures required to allow per user and per group access include:
Change the Dial-in permissions on the user account in the Active Directory to control Remote Access Permission on a per user basis.
Change the domain functional level to support Dial-in permissions based on Remote Access Policy.
Change the Permissions settings on the Remote Access Policy.
Changing the User Account Dial-in Permissions
You enable dial-in permissions on a per account basis, or create Remote Access Policies that can be configured to enable dial-in permissions to entire groups.
Perform the following steps if you want to control access on a per user basis, or if you have no other choice because of your domain's functional level:
Click Start; point to Administrative Tools, and click on Active Directory Users and Computers.
In the Active Directory Users and Computers console, expand your domain name and click on the User node.
Double-click on the Administrator account in the right pane of the console. In the user account Properties dialog box, click on the Dial-in tab. The default setting on the account is Deny access. You can allow VPN access for the account by selecting the Allow access option. Per user account settings override permissions set on the Remote Access Policy. Notice the Control access through Remote Access Policy option is disabled. This option is available only when the domain is at the Windows 2000 or Windows Server 2003 functional level. Make no changes to the account setting at this time. See Figure 9.49.
Figure 9.49: Changing the Dial-in Permissions
Click Cancel to escape this dialog box.
Changing the Domain Functional Level
If you want to control access on a per group basis, you will need to change the default domain functional level. Perform the following steps to change the domain functional level:
On a domain controller in your domain, open the Active Directory Domains and Trusts console. Click Start; point to Administrative Tools and click on Active Directory Domains and Trusts.
In the Active Directory Domains and Trusts console, right-click on your domain, and click on the Raise Domain Functional Level command.
In the Raise Domain Functional Level dialog box, click the down arrow in the Select an available domain functional level drop-down list and select either Windows 2000 native or Windows Server 2003, depending on the type of domain functional level your network can support. In this example, we will select the Windows Server 2003 option. Click the Raise button after making your selection (as shown in Figure 9.50).
Figure 9.50: The Raise Domain Functional Level
Click OK in the Raise Domain Functional Level dialog box. This dialog box explains that the change affects the entire domain and after the change is made, it cannot be reversed.
Click OK in the Raise Domain Functional Level dialog box informing you that the functional level was raised successfully. Note that you do not need to restart the computer for the changes to take effect. However, the default Remote Access Permission will not change for user accounts until Active Directory replication is completed. In this example, we will restart the computer. Restart the computer now and log in as Administrator.
Return to the Active Directory Users and Computers console and double-click on a user account. Click on the Dial-in tab in the user's Properties dialog box. Notice how the Control access through Remote Access Policy option is enabled and selected by default (Figure 9.51).
Figure 9.51: Controlling Access via Remote Access Policy
Controlling Remote Access Permission via Remote Access Policy
Now that we have the option to control access via Remote Access Policy (instead of a per user account basis), let's see how VPN access control via Remote Access Policy is performed:
Click Start; point to Administrative Tools, and click Internet Authentication Service.
Click Remote Access Policies in the left pane of the console. You will see the VPN Access Policy and two other built-in Remote Access Policies. You can delete the other policies if you require only VPN connections to your ISA firewall. Right-click on Connections to other access servers, and click Delete. Repeat with Connections to Microsoft Routing and Remote Access server.
Double-click on the VPN Access Policy in the right pane of the console. In the VPN Access Policy Properties dialog box there are two options that control access permissions based on Remote Access Policy:
Deny remote access permission
Grant remote access permission
Notice that this dialog box does inform you that the user account settings override the Remote Access Permission settings: Unless individual access permissions are specified in the user profile, this policy controls access to the network. Select the Grant remote access permission to allow members of the Domain Users group access to the VPN server (Figure 9.52).
Figure 9.52: Remote Access Policy Properties
Click Apply and then click OK in the VPN Access Policy Properties dialog box to save the changes
Enable the VPN Server on the ISA Firewall and Configure RADIUS Support
After the RADIUS server is installed and configured and Remote Access Policies are in place, we can start configuring the ISA firewall. First, we will first enable the VPN server component and then configure the VPN server to support RADIUS authentication.
Perform the following steps to enable the VPN server and configure it for RADIUS support:
In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and click on Virtual Private Networks (VPN).
Click the Tasks tab in the Task pane. Click Enable VPN Client Access.
Click Configure VPN Client Access.
In the VPN Clients Properties dialog box, put a checkmark in the Enable VPN client access checkbox. Configure the number of VPN clients you want to allow in the Maximum number of VPN allowed text box.
Click the Protocols tab. Put checkmarks in the Enable PPTP and Enable L2TP/IPSec checkboxs. Click Apply and then click OK (Figure 9.53).
Figure 9.53: Enabling the VPN Protocols
Click the Specify RADIUS Configuration link on the Tasks tab.
On the RADIUS tab in the Virtual Private Networks (VPN) Properties dialog box (Figure 9.54), put a checkmark in the Use RADIUS for authentication checkbox.
Figure 9.54:
Click the RADIUS Servers button. In the RADIUS dialog box, click Add.
In the Add RADIUS Server dialog box, enter the name of the IAS server machine in the Server name text box. In this example, the name of the IAS server is EXCHANGE2003BE.msfirewall.org. Enter a description of the server in the Server description text box. In this example, enter the description IAS Server. Click the Change button (Figure 9.55).
Figure 9.55: The Add RADIUS Server Dialog Box
In the Shared Secret dialog box, enter a New Secret and then Confirm new secret. Make sure this is the same secret you entered in the RADIUS client configuration at the IAS server machine. Click OK.
Click OK in the Add RADIUS Server dialog box.
Click OK in the RADIUS Servers dialog box (Figure 9.56).
Figure 9.56: RADIUS Server Dialog Box
Click Apply in the Virtual Private Networks (VPN) Properties dialog box. Click OK in the ISA 2004 dialog box informing you that the Routing and Remote Access Service may restart. Click OK in the Virtual Private Networks (VPN) Properties dialog box.
Click Apply to save the changes and update the firewall policy.
Click OK in the Apply New Configuration dialog box.
Restart the ISA firewall, and log on as Administrator.
Create an Access Rule Allowing VPN Clients Access to Approved Resources
The ISA firewall can accept incoming VPN connections after the restart. However, the VPN clients cannot access any resources on the Internal network because there are no Access Rules enabling this access. You must create an Access Rule allowing machines belonging to the VPN clients network access to the Internal network. In contrast to other combined firewall VPN server solutions, the ISA firewall applies access controls for network access to VPN clients.
In this example, we will create an Access Rule allowing VPN clients access to the OWA server on the Internal network and no other servers. In addition, we'll limit the users to using only HTTP when making the connection.
This type of configuration would be attractive to organizations that want to allow secure remote access to their corporate OWA site, but that do not want to use SSL-to-SSL bridging because:
There may be potential vulnerabilities in the SSL/TLS encryption implementations, and
They want to allow non-encrypted communications through the corporate network to enable internal network IDS to evaluate the connections.
We will demonstrate other ways you can implement access control on VPN clients using user/group members later in this chapter.
Perform the following steps to create an unrestricted access VPN clients Access Rule:
In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Firewall Policy node. Right-click the Firewall Policy node, point to New, and click Access Rule.
In the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will name the rule OWA for VPN Clients. Click Next.
On the Rule Action page, select Allow, and click Next.
On the Protocols page, select the Selected protocols option in the This rule applies to list. Click Add.
In the Add Protocols dialog box, click the Common Protocols folder, and double-click the HTTP and HTTPS Protocols. Click Close.
Click Next on the Protocols page.
On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click the Networks folder, and double-click VPN Clients. Click Close.
Click Next on the Access Rule Sources page.
On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click the New menu, and click Computer.
In the New Computer Rule Element dialog box, enter the name of the OWA server in the Name text box. In this example, we'll name it OWA Server. Enter the IP address of the OWA server in the Computer IP Address text box. Click OK.
Click the Computers folder and double-click the OWA Server entry. Click Close.
Click Next on the Access Rule Destinations page.
On the User Sets page, accept the default setting, All Users, and click Next.
Click Finish on the Completing the New Access Rule Wizard page.
Click Apply to save the changes and update the firewall policy.
Click OK in the Apply New Configuration dialog box. The OWA for VPN Clients policy is now the top-listed Access Rule in the Access Policy list (Figure 9.57).
Figure 9.57: The resulting firewall policy
Make the Connection from a PPTP VPN Client
All the elements are in place to support RADIUS authentication for VPN clients. In the following exercise you will establish a PPTP VPN connection from an external network VPN client.
Perform the following steps to connect to the VPN server via RADIUS authentication:
In the Dial-up and Network Connections window on the external network client, create a new VPN connectoid. Configure the connectoid to use the IP address 192.168.1.70 as the address of the VPN server. Log on with the user name Administrator.
Click OK in the dialog box informing you that the VPN connection is established.
At the domain controller machine, click Start and point to Administrative Tools. Click Event Viewer.
In the Event Viewer, click on the System node in the left pane of the console. Double-click on the Information entry with the source as IAS. (See Figure 9.58).
Figure 9.58: Event Viewer Entry
In the Event Properties dialog box, you will see a Description of the log-on request. The information indicates that the RADIUS server authenticated the request and includes the RADIUS-specific information sent to the domain controller. Review this information and close the Event Properties dialog box (Figure 9.59).
Figure 9.59: Log-On Request Details
At the ISA firewall, you can see log file entries specific to this VPN request. Note the PPTP and the RADIUS connections (Figure 9.60).
Figure 9.60: Log File Entries for VPN RADIUS Authentication
At the ISA firewall server, you can see the VPN client session in the Sessions tab in the Monitoring node of the Microsoft Internet Security and Acceleration Server 2004 management console (Figure 9.61).
Figure 9.61: VPN Session Appears in Sessions Section
At the VPN client computer, disconnect the VPN connection.
If you run a Network Monitor session on the RADIUS server, you can see that a single RADIUS Access Request is sent from the ISA firewall to the RADIUS server and a single Access Accept message is sent to the ISA firewall from the RADIUS server (Figure 9.62).
Figure 9.62: RADIUS Messages in Network Monitor Trace
