| As you undoubtedly know, Outlook Web Access (OWA) is a component of Microsoft Exchange 2000 in Microsoft Small Business Server 2000 (SBS) that provides an easy web-based interface to users’ email. By default, OWA uses HTTP, therefore enabling OWA on SBS is the same as hosting your own website, which requires the opening of port 80 for inbound access. Since SBS is not only a domain controller, but for most organizations their only server that houses sensitive data, and that port 80 is one of the single most attacked ports, it is considered best practice not to host a public website on your SBS. However, with more and more small businesses needing remote access to vital information such as email, calendars and contact lists, SBS administrators must provide remote access to users without compromising security.
The most secure method to use for remote access is Virtual Private Networking. VPNs offer encryption of data. However, they are not always feasible, especially if remote users are using public computers such as those found in libraries or cyber-cafes where they often do not have access to create the necessary VPN connection. In this instance, the only remaining option for most SBS administrators is to use Secure Socket Layer publish OWA. Enabling OWA to use SSL is actually a rather straight forward process.
Before beginning this configuration, please read the known issues section at the end of this document. This document details the process necessary to create your own SSL Certificates. If you have already purchased an SSL Certificate or plan to purchase an SSL Certificate, please see the notes at the end of this document before continuing. Also, if you would like more information on how the new OWA Wizard in ISA Feature Pack 1 does not completely address a proper configuration, see my notes on the subject at the end of this document.
The first step is to install Microsoft Certificate Server on your SBS. To do this, open Control Panel | Add/Remove Programs and select Add/Remove Windows Components.
- Select Certificate Services and click Next.
- If you get an error message saying that after installing Certificate Services you will not be able to rename the server or unjoin the domain, click OK.
- Click Next to accept Terminal Services in Remote Administration Mode.
- Click Next again to accept Enterprise Root CA as your Certification Type.
- Enter a CA Name – this can be virtually anything – then click Next.
- Click Next to accept the default data store locations.
- If you get an message box stating that Internet Information Services is running on the computer, click Yes to stop the service.
- If you encounter a problem where Windows is unable to locate the xenrx86.dll file, see the footnotes for a resolution.
- Once the wizard has finished, close Add/Remove Programs and Control Panel.
SSL Certificates are normally issued by a certain number of providers. Before a web browser can install an SSL certificate, it has to trust the provider that issued the certificate. By default, Windows includes an extensive list of trusted root certificate authorities. As a result, installing SSL certificates issued by these trusted providers is relatively simple. We can still create and use our own SSL certificates, but before remote users can install our SSL certificate, they need to trust the issuer – which just also happens to be ourselves. In order to get this to work, we are going to need to make some configuration changes in Certificate Services.
- Open My Computer Navigate to c:\winnt\system32\certserv\certenroll\ Write down the filename of the crt file.
- (This file will be in the form: _.crt)
- Go to Start | Programs | Administrative Tools | Certification Authority
- Right-click on the Certification Authority you just created and select Properties
- On the Policy Module tab, click Configure
- On the X.509 Extensions tab, click Add AIA
- Enter your public website address followed by /certenroll/ and the filename you recorded above.
- For example, my entry is “http://www.laytonflower.com/certenroll/lfis-sbs.laytonflower.local_laytonflower.crt”
- Click OK
- Click OK
- You will receive a warning that Certificate Services must be restarted – Click OK
- Click OK
- Stop the Certificate Service
- Start the Certificate Service
When an SSL Certificate is created, it contains information about the issuing authority. In order for remote users to install our SSL Certificate, they first need to add us as a trusted root certification authority. If they don’t add us as a trusted root ca, the remote user cannot install the SSL certificate for our website, which means they will get a warning message indicating that the certificate was issued by a company they have chosen not to trust every time they access OWA, which can be slightly annoying for the remote user. In order to add us as a trusted root certification authority, remote users have to be able to access our Certification Authority certificate. This is where your current public website from the steps above comes into play. You will need to create a new subdirectory in your public website named “certenroll” Once you have created this directory, you will want to upload a copy of your crt file from your c:\winnt\system32\certserv\certenroll\ directory. When we create the SSL certificate for OWA, it will include the link to your public website that we added to the Certification Authority settings above. Therefore, when a remote user first accesses OWA, they will be able to download your Certification Authority certificate from your website and install it to their trusted root certification authority store. Once they have added you as a trusted root certificate authority, they can install the SSL Certificate you created for OWA and not have to worry about certificate errors when accessing OWA from that PC in the future.
- Once we have installed and configured Certificate Services, we need to create a certificate to use for OWA.
- Open the Small Business Administrator Console.
- Expand Internet Information Services | | Default Web Site.
- Right-click on Default Web Site and select Properties.
- On the Directory Security tab, click Server Certificate.
- When the Web Server Certificate Wizard starts, select to create a new certificate and click Next.
- Select to Send the Request immediately, and click Next.
- Enter the name of your certificate. This can be anything, but should be something easy to remember.
- Select 1024 for your encryption key bit length.
- Enter your organization’s information:
- Enter your site’s common name and click Next (note this should be the url users enter to access OWA. This will be the same as your MX record, which is typically “mail..com”)
- Enter your geographical location and click Next
- Click Next until you finish the wizard.
- Click OK to close the Default Web Site properties.
Now that the certificate has been created and installed, we need to configure OWA to require SSL. To secure OWA, we need to require three separate webs under the Default Web Site to require SSL.
- Right-click on Exchweb and select Properties.
- On the Directory Security tab, click the Edit button in the Secure Communications area.
- Click to Require Secure Channel then click OK.
- Click to Require 128 bit Encryption
- Click OK to close the Exchweb properties.
- Repeat the process for both the Public and Exchange web folders.
Once you have configured the Exchweb, Exchange and Public folders to require SSL, you can test this by opening Internet Explorer and browsing to http:///Exchange from an internal client. You should get a 403.4 error – “The page must be viewed over a secure channel” Change your URL to use https and you will receive a security alert like this one:
- Click View Certificate
- Click Certification Path
- Click on your Certification Authority
- Click View Certificate
- Click Install Certificate to install your Certification Authority certificate to the trusted root store
- Click Next through the Certificate Import Wizard
- Click Finish
- Click Yes to install the certificate to the root store
- Click OK
- Click OK
- Return to the General tab and click Install Certificate to install the SSL Certificate for OWA
- Click Next through the Certificate Import Wizard
- Click Finish
- Click OK
- Click OK
- Click Yes
The steps above outline what remote users will need to do to install the SSL certificate. If they do not install both certificates as instructed, they will continue to see the Security Alert above every time they access OWA. You should now have accessed OWA. If you log off OWA, close your browser window and navigate back to OWA, you should be able to access it without any Security Warning. Be sure to log off OWA before continuing.
The next necessary task is to make OWA over SSL available from the outside world. To do so, you need to configure ISA by creating a server publishing rule.
- In ISA Management, expand Publishing
- Right-click on Server Publishing Rules and select New | Rule
- Enter OWA SSL as your rule name
- In the IP address of internal server enter the internal IP of your SBS.
- Click Browse to select the external IP of ISA.
- Select your external IP and click OK
- Click Next
- Select HTTPS Server from the Apply the rule to this protocol drop-down box and click Next
- Select to apply the rule to Any request and click Next
- Click Finish
- Close ISA Management
The last configuration necessary is to disable socket pooling in Internet Information Services.
- Open your command prompt
- Navigate to x:\inetpub\adminscripts (where x = the drive IIS is installed on (C:\ by default))
- Once in the \adminscripts directory, enter the following command:
- cscript adsutil.vbs set w3svc/disablesocketpooling true
- If the command was successful, it will return Disablesocketpooling : (BOOLEAN) True
- Exit the Command Prompt.
- Open the Services applet
- Restart the IISAdmin service.
- Restart the Microsoft ISA Server Control service.
There’s a very good chance that you’re thinking to yourself that this is all fine and dandy, but your users are still going to complain about having to remember to use https:// instead of http:// Well, we can even make it so they don’t have to remember to use https:// Remember that one of our primary reasons for using OWA over SSL is to allow us to keep port 80 closed. As a result, our redirection options are limited. The easiest solution for remote clients is to place a link on your public web site that points to your OWA using the correct https:// protocol, and have remote users go to your website and follow the link to OWA.
As for internal users, we have to contend with the My Email entry added to each user’s Favorites when clients were set up. However, there are two separate approaches to fix this, each with their own side-effects. Both methods include having the 403.4 error point to an asp page that redirects the user to an https:// URL. As you know, the My Email link in Favorites points to /exchange. However, since our SSL certificate was issued to match your mx record, not the internal netbios name of your server, users will receive a certificate warning that the name on the certificate is invalid or doesn’t match the name of the site each time the open OWA.
Alternatively, if internal users point to the public address of OWA (i.e. mail.yourcompany.com/exchange), they will not receive a certificate related security alert, but integrated Windows security will not be available, so they will need to enter a username and password to log on to OWA. Therefore, the choice is whether to automatically redirect internal users to https:///exchange or https://mail..com/exchange. I personally prefer redirecting traffic to https://mail.’t to users you your mailbox.< Administrator?s access account grant or Administrator as workstation a on log having without mailbox easy very it makes Lastly, own. their see only can everyone why explain have email his if asking boss thus users, end security of impression increased an adds Secondly, OWA. they time every alerts constant with deal not do First, reasons: different few for exchange P in user the>
To redirect users, we need to create an asp to do the redirection and configure OWA to use that page for the 403.4 error. Open My Computer and browse to the Inetpub\wwwroot directory. Create a new directory named owaasp. By default, this folder should have anonymous access enabled in IIS. Note that in order for redirection to work, this folder needs anonymous access. Once you have created this directory, download the owahttps file and save it to this directory. The owahttps file includes the following lines. You can create this file yourself, just be sure to add a TAB at the beginning of each line after the first. (as you may know, http doesn't handle tabs very well, which is why the lines below do not include them. However, our asp file needs the tabs in order to function properly. Thus, if you just copied and pasted the lines below, your owahttps.asp file would not work)
The file available for download uses the above code to redirect internal users to https://.com/exchange, edit the owahttps.asp file in notepad and change
strSecureURL = strSecureURL & Request.ServerVariables(“SERVER_NAME”)
to
strSecureURL = strSecureURL & “”
Save and close your owahttps.asp file. Open the Small Business Administrator Console. Expand Internet Information Services | | Default Web Site | Exchange. Right-click on Exchange and select Properties. On the Custom Errors tab, double-click on 403.4. Select URL as the message type and enter /owaasp/owahttps.asp in the URL field.
Click OK to close the Error Mapping Properties, then OK again to close the Exchange properties. Close the Small Business Administrator Console and you should be set.
If you have purchased, or plan to purchase an SSL Certificate from a Certification Authority, the steps outlined are slightly different. First, you do not need to install or configure Certificate Services on your SBS. In this case, your configuration will start by either installing or requesting your SSL Certificate.
- Open Small Business Administrator Console
- Expand Internet Information Services | | Default Web Site.
- Right-click on Default Web Site and select Properties.
- On the Directory Security tab, click Server Certificate.
- When the Web Server Certificate Wizard starts, you can select to create a new certificate if you have not yet purchased your certificate, or assign an existing certificate if you have already purchased a certificate.
- If you have not purchased a certificate, on the next screen you will want to select to “Prepare the request now, but send it later”
- Make sure to note the location of your request file, as you will need to provide that to the Certification Authority when you purchase your certificate.
- Continue with the rest of the instructions starting here
When you receive your certificate, you will repeat these steps, except that when the Web Server Certificate Wizard starts, you will choose to “Process the pending request and install the certificate.” You will then browse to the certificate file you purchased and complete the wizard to install it. In addition to the above differences in this procedure, when testing the SSL outlined on page 5, you will only need to follow the wizard to install the SSL Certificate for OWA, you will not need to view and install the Certification Authority certificate.
Google
ISA Feature Pack 1 includes a new OWA Wizard to help secure OWA. After running this wizard, it is obvious that is falls short from the configuration outlined in this paper on several counts. The OWA wizard in ISA Feature Pack 1 addresses securing OWA from ISA’s standpoint – therefore, all the wizard does is to handle a few of the configuration tasks in ISA that we complete manually here. Specifically, when you run the wizard and select to require SSL, the wizard creates the necessary destination set pointing to the internal IP of our server, creates the necessary web publishing rule and enables SSL listeners in ISA. The wizard does not install the certificate for the Default Web Site, configure the Exchange, Exchweb or Public subwebs to require SSL, or disable socket pooling. Therefore, I chose not to include the OWA wizard as I felt that in the wrong context it could be possible for an SBS administrator to believe that the wizard was all that was necessary to secure OWA using SSL.
You may encounter an error while copying files to install Certificate Services that says setup cannot copy the file xenrx86.dll - you’ll need to insert your Windows 2000 SP3 CD, open W2KSP3.exe with WinZip (or other zip utility), and extract xenrx86.dl_ to your hard drive. Then return to the Certificate Services setup and browse to the location you extracted the file to.
Also - Special Thanks to Daniel Kingsley for correcting me by pointing out that the web publishing rule in earlier drafts was not necessary.
|