Some of the most frequent questions posted to Microsoft public newsgroups are about setting up Outlook Web Access to use SSL for security. Michael Bell explains, step-by-step, how to do this in his latest 'Learn Exchange 2000' article.
by Michael Bell
Some of the most frequent questions posted to both the 2000trainers.com newsgroup and the Microsoft public newsgroups are about setting up Outlook Web Access (OWA) to use SSL for security. This is especially important in a scenario where you are using a front-end/back-end configuration as front-end servers support only basic authentication. This might not seem like a big deal at first, but when you consider that this means information is being sent across the wire in an unencrypted format, you can see how important it becomes.
Some administrators also prefer to force users to a secure connection, rather than manually requiring them to type it in. Finally, a lot of users want to take advantage of the functionality included with OWA that allows them to change a user's domain password. We are also going to cover all of this, but be aware that this last step requires SSL to be used on the OWA server.
Having said all that we will begin by actually enabling SSL on the Exchange Virtual Server. To do this, I used a digital certificate from my own certificate authority (CA) that I installed into my network. You can get your certificate from a local CA or from any of the CAs that exist out on the Internet. Where the digital certificate comes from isn't important. Installing it into the Exchange Virtual Server to enable SSL for OWA is what is important to us. We start by going into the Default Virtual Web Server through Internet Services Manager, as you can see in Figure 1.
Next, we go into the properties of the Default Web Server, as you can see in Figure 2.
From there, we go to the Directory Security Tab, and select the install a new digital certificate option. This launches the certificate wizard seen in Figure 3.
Once you have stepped through the wizard you should be able to go in and view the properties of the new digital certificate that you have installed, as you can see from Figure 4. An actual walk through of the Certificate Wizard can be found
That was the easy part.
Now that we have our certificate installed, we first want to make certain that our clients using OWA can connect using SSL. Once we verify SSL connectivity is working, we are going to automate the process so that even if a user doesn't type in HTTPS: they will be redirected to the secure link without having to type anything in. Finally, we will configure IIS to allow an OWA user to change his or her domain password.
To start off, we want to verify that HTTPS works, so type in the URL HTTPS://exchangeservername/exchange and verify that we can get to our mailbox. As you can see from Figure 5, everything is working fine.
The only problem at this point is that a user can still access his or her mailbox using an
unsecured link as well. Figure 6 illustrates what we mean.
So the problem here is that although SSL is enabled users are still able to access their mailboxes using an
unsecured link. This obviously is undesirable because we can't count on our users to remember to type in HTTPS when they attempt to access their mailboxes through OWA. Luckily, we don't have to rely on the users doing this.
Now we are going to look at how to set this up so that the user has to use SSL to access the Web site, and will be redirected to the secure port even if he types in the
unsecured (HTTP) port.
First, we need to go into the C:\inetpub\wwwroot directory and create a folder called Owaasp, as seen in Figure 7.
Next, we actually create a file called owahttps.asp and put it into the directory previously specified. The content of the file is included in Figure
8, but I have also included the content below the graphic so that
you can copy and paste it into your own file as needed.
Note that this information comes from a Q article originally published on Technet.
If Request.ServerVariables("SERVER_PORT")=80 Then
strSecureURL = "https://"
strSecureURL = strSecureURL & Request.ServerVariables("SERVER_NAME")
strSecureURL = strSecureURL & "/exchange"
Now that we have done that, we need to go to the properties of the Exchange Virtual Directory inside Internet Services Manager. We are going to go to the Custom Error Messages Tab.
Figure 9 illustrates where we are at.
Once on the Custom Errors tab, we need to edit the properties of error 403.4. We are going to provide the information included in Figure 10.
Next up, we go to the Directory Security Tab and select Edit under Certificates (from the Exchange Virtual Directory) and select to require security. You can see this in Figure 11.
Now that we have finished that, select OK and OK to close out the dialog boxes. The only thing left at this point is to stop IISadmin and restart it. The easy way to do this would be to restart the server, but if that isn't an option you can stop and restart the services from the command prompt. Take a look at Figure 12 for the command line syntax necessary to stop iisadmin.
You have to make note of the other services that will shut down when you stop iisadmin. As you can see from Figure 13, several services are dependent on the iisadmin service. Also keep in mind that based on the products and services installed your information might vary. Finally, if you don't know the command line syntax to start all the individual services, remember that you can always use the Services Manager to restart them. Just right click on My Computer, Select Manage, and go to the Services option. Using your command console as a reference, restart all the appropriate services.
Now we should be able to verify that users will be forced to use an SSL connection regardless of whether they type in HTTP or HTTPS. Take a look at Figure 14 to see if all our hard work has
We can see that it works if we type in the secure port (HTTPS). See what happens if you type in "HTTP." Figure 15 provides the proof. Be sure to look in the address bar to see that we are being redirected to the secure site even though we use the unsecured port (HTTP).
With the completion of this step, we have accomplished two of our three goals to this point. We have enabled SSL on our OWA server, and we have configured it so that users are forced into an SSL connection when they connect to the OWA server. All that remains is configuring the password change utility.
Password Change Through OWA
To allow users to change their passwords through OWA we first have to enable SSL on the OWA server. As you can see we have already accomplished that. The next step requires us to create a virtual directory in Internet Services Manager. The virtual directory is called Iisadmpwd and points to a physical directory located on the Exchange box at C:\winnt\system32\inetserv\iisadmpwd. Figure 16 shows us the beginning steps to creating the Virtual Directory.
Make certain to point the Virtual Directory at the physical drive location discussed previously. As you go through the Create Virtual Directory Wizard, be certain to allow only Read and Script Access check boxes. By default, these should be the only two boxes selected. Finally, go into the properties of the Iisadmpwd folder and ensure that anonymous access is selected. There can be other authentication options selected as well, but this one is critical to the success of the venture. If it isn't enabled, a user whose password has expired will not be able to get in to change their password. See
Q275457 for more information relating to this particular setting.
One final thing to finish now. Open up a command prompt and change to the c:\inetpub\adminscripts directory. At the command prompt, type the following command, exactly as you see it here: adsutil.vbs set w3svc/passwordchangeflags 0
Note that there is no space between w3svc/passwordchangeflags. Be aware that you may initially get a prompt that indicates that the current script engine isn't capable of handling the request and asks you if you want to change the script engine. Select yes, and you should receive verification that the command completed successfully. Now that we have finished this we can go into our OWA client to verify that users can change their domain password from within OWA.
As illustrated in Figure 17, I have connected to my mailbox using OWA and gone to the options shortcut. Note that it is still using a secure connection!
When you click on the change password button, you should see the dialog box that is Figure 18.
Now we just have to fill in the information requested in Figure 19. The articles specify that the username must be specified in the Domain\Username format, as you can see that I have done.
In my case I am using Exchange 2000 SP3. When I got to this point I simply specified the appropriate information as required by the dialog box, and it worked. It actually didn't work when I tried to use the Domain\username setting as specified in some of the Q articles that I had read. You will want to test this setting based on the SP that you are using and educate your users appropriately.
That wraps it up for this week. I do want to point out three articles that I found to be extremely useful in performing these tasks. I would recommend that you review them prior to attempting to configure any of the above functions.
- Q320291 explains how to configure OWA for SSL
- Q279681 to configure OWA so that SSL was required
- Q267596 shows us how to use the password change functionality within OWA and IIS