Exchange allows administrators to configure who has access to OWA and OMA/ActiveSync through the gui. Those features can be turned on or off at will on an individual basis. But what if you want to restrict who has access to RPC over HTTP? There is nothing built into the GUI to restrict that feature, not even in Exchange 2007 (definitely a feature request for SP1). Although access to this feature is not configurable in Exchange, it can be done using Active Directory groups and ISA. I recently had the opportunity to set this up, and this article will detail the steps I took to isolate the use of this feature.
In the environment I was working on, the ISA server was a member of the domain. This is not necessary, it can be accomplished with or without the ISA server being a member server. Which way should you set up your ISA server? You'll have to figure that out on your own, I'm not getting into that debate. Also, the ISA server was configured with a single NIC. This article assumes that you have an ISA server in place currently controlling access to Exchange.
Modifications to the Existing Environment
Additional configuration for the ISA server will include an additional IP address for the ISA NIC, an additional web site for the Exchange front-end server, an additional SSL certificate mapped to the new ISA IP address, an additional firewall rule, an additional web listener, some modifications to the existing firewall rule, and optionally one additional firewall deny rule for client redirection. On the network side, an additional NAT statement will be required for the new ISA IP address if you are using NAT on your externally facing IP addresses, and an access-list rule to allow access to port 443 on the new IP address will also be required if you have an additional firewall in front of your ISA box, as well as an access-list rule permitting the ISA box to talk to the domain controllers for the purpose of authenticating users, if there is a firewall between your ISA server and your DCs.
Additional IP Address for the ISA Server
In order to separate users authenticating to RPC and all other Exchange requests (which all connect to the same port, 443), an additional IP address is needed so that an additional web listener can be configured to listen for RPC connections on the ISA server. After the IP address is added to the server, the existing firewall rule will need to be modified to only listen on the existing IP address.
Right-click the listener in the existing firewall rule and choose Properties. Highlight the item in the list that has the check mark and click the address button, then specify the existing IP address for the listener.
Additional Web Site for the Exchange Front-end Server
In order to create a new SSL certificate mapped to a new IP address on the ISA server, a new website on the Exchange front-end server will also be necessary. To configure the new website, open the IIS tool, right-click the Web Sites folder, and choose New then Web Site.
This brings up the Web Site Creation Wizard. Click Next.
Give the web site a name (this will be the DNS name that your clients will point Outlook to), click Next, then click Next on the IP Address and Port Settings window.
Enter the default IIS path. Click Next.
Ensure that the box for Read is checked, then click Next. Then click Finish.
There will now be a web site with the name you used during the wizard.
Additional SSL Certificate
The addition of a separate IP address for RPC communications will require an additional SSL certificate. This certificate will need to be requested from and installed on your Exchange front-end server (the one you just created an additional website on) and exported to the ISA server just as the original certificate was.
Instructions for that process can be found beginning on page 507 of the ISA Server 2004/Exchange Server Deployment Kit. Make sure to request the SSL certificate from the new website created on the Exchange front-end server.
Once the new cert is exported to the ISA server, the new website on the Exchange front-end server can be disabled, as it will not be used for any other purpose than obtaining an SSL certificate.
Additional Firewall Rule
An additional firewall rule will be required to further secure the Exchange RPC feature. This can be done by duplicating the existing Exchange rule and making a few modifications.
First, click on Firewall Policy, choose the Tasks tab, and click Publish Exchange Web Client Access.
Type in the name you want to give the rule and click Next.
On the Select Services window, make sure that only Outlook RPC/HTTP(S) is selected, then click Next.
On this screen, choose the option that matches your environment (I was working with a single server) and click Next.
We will be using an SSL certificate, so choose that option and click Next.
We will be publishing a separate feature for an existing website. For the Internal site name option, type in the internal name of the existing Exchange front-end website you currently use. If needed (usually if your ISA box is off the domain), check the box and enter in the IP for the front-end Exchange server. Click Next.
From the drop-down list, choose the option for This domain name and type in the name of the new SSL FQDN you chose earlier and choose Next.
The next screen will give the option of selecting an existing Web Listener or creating a new one. Choose the option to create a new one. In the next window, type in the name for the web listener and click Next.
Choose the option to require SSL and click Next.
On this screen, check the box for the NIC that inbound requests will go to, click the Select IP Addresses button, and choose the IP address that has been added to the ISA box for RPC access.
Choose the option for using a single certificate, click the Select Certificate button, and choose the certificate for use with the RPC service that was imported earlier.
Make sure that HTTP Authentication is selected in the drop-down list, and choose the option for Windows authentication. If your ISA box is NOT on the domain, you would choose LDAP on this screen. However, before you can select groups from AD to allow access, you will also need to configure an LDAP connection from your ISA box to one or more DCs.
If you are using SSO, then check the box. If not, leave it unselected. In my case, SSO was not implemented.
This connection will be using Basic authentication, so make sure that is selected in the drop-down list.
We will be changing the user set later, but for now, leave this screen as is and click Next, and then click Finish on the next window.
Once the wizard is complete, right-click on the new listener in the firewall rule that was just created and choose Properties. Go to the Authentication tab.
Click the Advanced button.
In this window, verify that the Require all users to authenticate box is checked, as well as the Allow client authentication over HTTP box.
As for the Client Credentials Caching, you can either accept the defaults or adjust them to your preferred settings. Click OK, then click OK in the listener properties window.
Next right-click the firewall rule and choose Properties, and select the Users tab.
Click the Add button.
On the Add Users window, click the New button.
This will start the New User Set Wizard. Give the user set a name, such as RPC Users, and click Next.
Click the Add button, and choose Windows users and groups. As mentioned earlier, if your ISA server is not on the domain, you will need to configure an LDAP connection before you will be able to resolve AD groups.
In this window, we will specify the group or groups whose members will be allowed to use RPC over HTTP.
Once you have selected the appropriate group(s), click OK.
Back on the Users tab, remove any pre-existing groups, such as All Users or All Authenticated Users, leaving only the group or groups that were just created. Click OK. In the main ISA configuration window, click the Apply button to activate the new settings.
At this point, the ISA server will be configured to support RPC connections on another IP address.
Allowing Only the Group Members to Use RPC Over HTTP
You should now populate your groups to contain the users who should be allowed access and instruct them to begin using the new SSL URL as the address instead of the one they were using previously.
Once the appropriate users convert over to using the new address, access to RPC will need to be disabled through the original address. Open the properties of the original firewall rule and go to the Paths tab.
If you have a list of paths as shown in the screenshot, simply remove the path for /rpc/*, and that will disallow access to RPC over HTTP via this firewall rule. If you upgraded from a previous version of ISA, the only path listed might be a wildcard (/*) allowing any traffic through.If there is a single wild card, highlight that path and click the Remove button. Once the wildcard path is gone, specific paths will need to be created to replace it. The screenshot above shows all possible locations. The /rpc/* path SHOULD NOT be created. However, the following five paths do need to be created:
/public/*
/OMA/*
/Microsoft-Server-ActiveSync/*
/Exchweb/*
/Exchange/*
Once those are created and the rule is applied, only members of the RPC users groups will have access to the RPC over HTTP service on the Exchange servers.
Create a Deny Web Publishing Rule that Redirects the / path to the /Exchange Path
If you had a single wild-card entry, this step will be necessary if you were using a redirection on your Exchange front-end server to direct web clients to the /exchange directory. Removing the wildcard will deny access to the root directory on the Exchange front-end server, and users will not get redirected, and won't get their email. And training them to put a /exchange on the end of their URL is usually too painful to attempt, so here's a workaround for that situation.
What you will need to do is create a deny rule for https://owa.yourdomain.com. Once the deny rule is set up, go into the properties and configure a redirect to https://owa.yourdomain.com/exchange. Then just make sure that the deny rule is higher in the list than the rule that allows access to /Exchange/*.