Creating a Customer VPN Client Access Policy to Connect Outlook MAPI Clients to Microsoft Exchange (Part 2)

If you missed the first part in this article series please read Creating a Custom VPN Client Access Policy to Connect Outlook MAPI Clients to Microsoft Exchange (Part 1)

In the first part of a two part series on how to configure the ISA Firewall to support secure MAPI connections to the Exchange Server over a remote access VPN client connection, we went over the basic premises on why the ISA Firewall is a more secure solution that other firewall/VPN server solutions, and then went on to enable the VPN server component on the ISA Firewall. We then created the user and group that we will use to demonstrate how we can enforce strong granular access control over who can access the Exchange Server using MAPI/RPC over the remote access VPN connection.

Discuss this article

This week we will finish up by creating the required protocol definitions and firewall policy to allow only authorized users to connect to the Exchange Server.

Create Access and Server Publishing Rules Restricting Access to the Exchange Server

We are now ready to create an Access Rule and a Server Publishing Rule that will restrict access to the Exchange Server when using the full Outlook 2000 MAPI client (the same rule will work for the Outlook 2002, Outlook 2003, and Outlook 2007 clients). The Access Rule will allow members of the VPN Exchange Users group access to the DNS and Direct Access (445) protocols. The table below contains the pertinent details of the rule.

Note:
This step isn’t actually required, as you can use the Microsoft CIFS (TCP) Protocol Definition. However, since we’re not using this protocol for CIFS, and you cannot rename the built-in protocol names, I choose to create the custom protocol definition for access to the Exchange Server.

Name

Direct Access/VPN Clients

Action

Allow

Protocols

DNS

Direct Access (445)

From

VPN Clients

To

Exchange Server

Users

VPN Exchange Users

Schedule

Always

Content Types

All content types

Table 1: RPC for VPN Clients Access Rule

The Direct Access (TCP 445) protocol is required for directory service access (LDAP conversion) for the Outlook client in this scenario.

The second Access Rule will deny all RPC traffic from all users on the VPN clients network except for members of the VPN Exchange Users group. This rule prevents users who are not members of the VPN Exchange Users group from connecting to the Exchange Server via Secure Exchange RPC.

Name

Deny RPC All Interface

Action

Deny

Protocols

RPC (all interfaces)

From

VPN Clients

To

Exchange Server

Users

All Users except VPN Exchange Users

Schedule

Always

Content Types

All content types

Table 2: Deny Rule Blocking RPC Access

Perform the following steps to create the Direct Access/VPN Clients Access Rule:

  1. In the ISA Firewall Console, expand the server name and click the Firewall Policy node.
  2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Create New Access Rule link.
  3. On 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 enter RPC over VPN Clients and click Next.
  4. On the Rule Action page, select the Allow option and click Next.
  5. On the Protocols page, select the Selected protocols entry in the This rule applies to list. Click Add.
  6. In the Add Protocols dialog box, click the All Protocols folder. Double click the DNS entry.
  7. Click the New menu in the Add Protocols dialog box. Click the Protocol command.


Figure 1

  1. On the Welcome to the New Protocol Definition Wizard page, enter the name for the Protocol Definition in the Protocol definition name text box. In this example we will name the protocol Direct Access (445). Click Next.
  2. On the Primary Connection Information page, click the New button.
  3. On the New/Edit Protocol Connection page, set the Protocol type to TCP. Set the Direction as Outbound. In the Port Range frame, set the From entry to 445 and the To entry to 445. Click OK.


Figure 2

  1. Click Next on the Primary Connection Information page.


Figure 3

  1. On the Secondary Connections page, select the No option and click Next.
  2. Click Finish on the Completing the New Protocol Definition Wizard page.
  3. Double click the Direct Access (445) entry that now appears in the All Protocols list, then click Close.


Figure 4

  1. On the Protocols page, click Next.
  2. On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click the Networks folder and then double click the VPN Clients network. Click Close.
  3. On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click the Networks folder and then double click the Internal network. Click Close.
  4. Click Next on the Access Rule Destinations page.
  5. On the User Sets page, click the All Users entry and then click the Remove button. Next, click the Add button.
  6. In the Add Users dialog box, double click the VPN Exchange Users entry. Click Close.
  7. Click Next on the User Sets page.
  8. Click Finish on the Completing the New Access Rule Wizard page.

Now that the Exchange VPN Users group has access to the DNS and Direct Access (445) protocols, the next step is to create the Deny rule to prevents VPN users who are not members of the VPN Exchange Users group from connecting to the Exchange Server via the Secure Exchange RPC protocol.

Perform the following steps to create the Deny RPC All Interfaces Rule:

  1. In the ISA Firewall Console, expand the server name in the left pane of the console and then click the Firewall Policy node.
  2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Create New Access Rule link.
  3. On the Welcome to the New Access Rule Wizard page, enter the name of the rule in the Access Rule name text box. In this example, we will name the rule Deny RPC All Interfaces. Click Next.
  4. Select Deny on the Rule Action page.
  5. On the Protocols page, select the Selected protocols option in the This rule applies to list. Click Add.
  6. In the Add Protocols dialog box, click the All Protocols folder and then double click on the RPC (all interfaces) protocol. Finally, double click on the DNS protocol. Click Close.
  7. Click Next on the Protocols page.
  8. On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click the Networks folder. Double click on the VPN Clients entry. Click Close.
  9. Click Next on the Access Rule Sources page.
  10. On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click the Computers folder. Double click on the Exchange Server entry. Click Close.
  11. Click Next in the Access Rule Destinations dialog box.
  12. On the User Sets page, accept the default entry, All Users, and then click Next.
  13. Click Finish on the Completing the New Access Rule Wizard page.
  14. In the Details pane of the Microsoft Internet Security and Acceleration Server 2004 management console, double click on the Deny RPC All Interfaces Access Rule.
  15. In the Deny RPC All Interfaces Properties dialog box, click the Add button in the Exceptions section. In the Add Users dialog box, double click on the VPN Exchange Users entry. Click Close.


Figure 5

  1. Click Apply and then click OK in the Deny RPC All Interfaces Properties dialog box.

Now we’re ready to create the Secure Exchange RPC Server Publishing Rule that allows the Outlook MAPI clients to connect to the Exchange Server.

Perform the following steps to create the Secure Exchange RPC Publishing Rule:

  1. In the ISA Firewall console, expand the server name and click the Firewall Policy node.
  2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Create New Server Publishing Rule link.
  3. On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the rule in the Server publishing rule name text box. In this example we will call the rule Secure Exchange RPC. Click Next.
  4. On the Select Server page, enter the IP address of the Exchange Server on the Internal network in the Server IP address text box. In this example, the IP address is 10.0.0.2 and we will enter that address into the text box. Click Next.

Discuss this article


Figure 6

  1. On the IP Addresses page, put a checkmark in the VPN Clients checkbox. Click Next.


Figure 7

  1. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Create an Access Rule Allowing Access to the Web Enrollment Site

Although all hosts are denied access to the RPC protocol on the Exchange Server, we do want to allow connections to the same machine so that all hosts can request certificates on the Web enrollment site, which is located on the same machine. We can accomplish this task by creating an Access Rule that allows allow VPN clients access to the machine using the HTTP and HTTPS protocols. In addition, we will allow all users access to the DNS server protocol, as the DNS server is located on the same machine.

Perform the following steps to allow VPN clients access to the Web enrollment site:

  1. In the ISA Firewall Console, expand the server name in the left pane of the console and then click the Firewall Policy node.
  2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Create New Access Rule link.
  3. On the Welcome to the New Access Rule Wizard page, enter the name of the rule in the Access Rule name text box. In this example, we will name the rule VPN Clients to CA Web. Click Next.
  4. Select Allow on the Rule Action page.
  5. On the Protocols page, select the Selected protocols option in the This rule applies to list. Click Add.
  6. In the Add Protocols dialog box, click the Common Protocols folder and then double click on the HTTP protocol. Next, double click on the HTTPS protocol. Finally, double click on the DNS protocol. Click Close.
  7. Click Next on the Protocols page.


Figure 8

  1. On the Access Rule Sources page, click Add. In the Add Network Entities dialog box, click the Networks folder. Double click on the VPN Clients entry. Click Close.
  2. Click Next on the Access Rule Sources page.
  3. On the Access Rule Destinations page, click Add. In the Add Network Entities dialog box, click the New menu. Click the Computer entry.
  4. In the New Computer Rule Element dialog box, enter the name of the computer in the Name text box. In this example we will name the computer Web Enrollment Site. Enter the IP address of the Web enrollment site in the Computer IP Address text box. In this example, the IP address is 10.0.0.2 so we will entry that value into the text box. Click OK.


Figure 9

  1. In the Add Network Entities dialog box, click the Computers folder and then double click the Web Enrollment Site entry. Click Close.


Figure 10

  1. Click Next in the Access Rule Destinations dialog box.
  2. On the User Sets page, accept the default entry, All Users, and then click Next.
  3. Click Finish on the Completing the New Access Rule Wizard page.

Arrange the Rule Order

We need to arrange the Access Rules so that they are processed in a sequence that provides Exchange RPC access to members of the VPN Exchange Users group but will not let other users access to the Exchange Server via RPC in the event that another rule ends up inadvertently allows members of other groups RPC access.

Perform the following steps to arrange the rule in the desired order:

  1. In the ISA Firewall Console, expand the server name and click the Firewall Policy node.
  2. You goal is to move the rules up or down on the list so that they appear in the order shown in the figure below.


Figure 11

  1. You can move the rules by click on one and then using the up or down arrow buttons in the button bar.


Figure 12

  1. Click Apply to save the changes and update the firewall policy.
  2. Click OK when the configuration changes are saved.

Establish a VPN connection and Connect to Microsoft Exchange via Secure RPC

We are now ready to connect to the Exchange Server form a VPN client machine on the external network. The external VPN client machine is a Windows 2000 Professional computer and Outlook 2000 is installed on the machine. The Outlook 2000 application is configured to connect to the Exchange Server. However, because the Outlook client must be able to resolve the name of the Exchange Server using DNS, we must make sure that the client operating system is able to fully qualify the Exchange Server’s host name. There are a number of ways this can be accomplished. In this example we will configure the VPN client machine with a primary domain name that it will append to the unqualified DNS queries. Since the Exchange Server belongs to the msfirewall.org domain, we will configure the VPN client machine to use the msfirewall.org primary domain name.

I should note here that I’ve chosen the Outlook 2000 client example as the worst case scenario. However, name resolution issues are important for all Outlook clients. You must be sure that the VPN client computers are able to resolve the name of the Exchange Server to the correct internal IP address. The procedure I describe below will work for all versions of Outlook and all types of VPN client connections. There are other methods that you can use, but this is the most straightforward.

Perform the following steps to configure the VPN client machine with the proper primary domain name:

  1. Right click the My Computer icon on the desktop and click Properties.
  2. In the System Properties dialog box, click the Network Identification tab.
  3. On the Network Identification tab, click the Properties button.
  4. In the Identification Changes dialog box, click the More button.
  5. In the DNS Suffix and NetBIOS Computer Name dialog box, enter msfirewall.org in the Primary DNS suffix of computer text box. Click OK.
  6. Click OK in the Identification Changes dialog box.
  7. Click OK in the Network Identification dialog box informing you that you will need to restart the computer.
  8. Click OK in the System Properties dialog box.
  9. Click Yes in the System Settings Change dialog box
  10. Log on as Administrator when the machine restarts.

Now that the VPN client machine can fully qualify the Exchange Server’s name, we can establish the VPN connection. The Outlook 2000 application has been configured with an Outlook Profile that connects it to the Administrator account on the Exchange Server. The Exchange Server name in the Outlook 2000 profile is EXCHANGE2003BE. The VPN client machine will be able to use the DNS server address provided to it by the VPN server to find the Exchange Server.

Perform the following steps to connect to the VPN server and the Exchange Server:

  1. Create the VPN client connectoid from the Make New Connection icon in the Network and Dial-up Connections window. Use the IP address of 192.168.1.70 for the VPN server.
  2. Establish the VPN connection with the user account MSFIREWALL\Administrator. The connection will use PPTP because we have not deployed certificates in this scenario.
  3. Start the Outlook 2000 application. There will be a delay and you will see a dialog box indicating that Outlook cannot connect to the Exchange Server. The reason for this is that you logged onto the VPN using an account that does not have access to the RPC protocol. Click Work Offline in the Microsoft Exchange Server dialog box.


Figure 13

  1. Click OK in the Microsoft Outlook dialog box informing you that it cannot open the default e-mail folders.
  2. Click No in the Microsoft Outlook dialog box asking if you want to open the default File System folder.
  3. Right click the connection icon in the System Tray and click the Disconnect command.

Now that we’ve determined that users that are not member of the VPN Exchange Users group cannot connect to the Exchange Server from the Outlook MAPI client, the next step is to show that a member of the group can connect to the Exchange Server.

Perform the following steps to test a successful connection to the Exchange Server:

  1. Use the same VPN connectoid, but this time log on with the account MSFIREWALL\user1.
  2. Open the Outlook 2000 client application.
  3. Outlook 2000 successfully connects. If you look in the log file, you will see entries indicating that the Direct Access (445) allows user1 access to the Exchange Server Publishing Rule and the Exchange Server.


Figure 14

  1. Close Outlook and then disconnect the VPN connection.

Establish a VPN connection and Connect to the Web Enrollment Site

Now we can test whether a user who is not a member of the VPN Exchange Users group can connect to resources on the Internal network using another protocol. In this example, we’ll log in as Administrator (who is not a member of the VPN Exchange Users group) and attempt to connect to the Web enrollment site on the Internal network.

Perform the following steps to test the connection:

  1. Create a VPN connection using the same VPN connectoid you used in the previous exercise. Log on a MSFIREWALL\Administrator.
  2. Open Internet Explorer and enter http://10.0.0.2/certsrv into the Address bar. Click Go.
  3. Log on to the Web site with the User Name of Administrator and the Administrator’s password.
  4. You will be able to log on to the site and see the Welcome page. If you check the log file, you will see that the VPN Clients to CA Web rule allowed the connection.


Figure 15

  1. Close Internet Explorer and close the VPN connection.

Discuss this article

Conclusion

In this article we finished up our two part series on how to enable MAPI access to Exchange Servers over a secure remote access VPN client connection. You can extend the security of this solution by enforcing two factor authentication on the remote access VPN client configuration by using EAP-TLS authentication. In this way, you can circumvent the security issues due to the Outlook client’s inability to support two factor authentication. You can find an article on how to configure the ISA Firewall to support EAP-TLS authentication on the www.isaserver.org Web site.

If you missed the first part in this article series please read Creating a Custom VPN Client Access Policy to Connect Outlook MAPI Clients to Microsoft Exchange (Part 1)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top