Installing the Microsoft Certificate Service
To install the CA component, log on to the server that抯 going to hold the CA service, and then do the following:
1. Click Start | Control Panel | Add or Remove Programs.
2. Select Add/Remove Windows Components.
3 Put a check mark in the Certificate Services box
A Microsoft Certificate Services warning dialog box will appear. The box informs you that you cannot change the machine name or the domain membership of the machine while it acts as a certificate server. Read and take note of this message; otherwise, you could end up in quite a mess.
4. Click Yes, then click Next.
5. Select Enterprise root CA (recommended when you have an AD), then click Next
Reality Check…
When dealing with OWA environments, you should typically choose to install an enterprise root certificate service unless a standalone root certificate service is specifically required. We won’t go into detail on the differences between the types of CA in this book, but if you want to read more about them, we suggest you take a look at the following two links at Microsoft Technet:
Enterprise certification authorities www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CSEnterCA.asp?frame=true
Stand-alone certification authorities www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_CSStandCA.asp?frame=true
Alternatively, check your CA server Help file.
In the screen that appears , type in a common name for this CA. The common name of the CA is typically the DNS host name or NetBIOS name (computer name) of the server running the certificate services. In this specific example, the name of the machine is TESTS01, so we will enter TESTS01 in the Common name field. The default Validity Period of the CA self-signed certificate is five years, which in most cases should be sufficient, so leave this setting at the default. Click Next.
6. On the Certificate Database Settings page , use the default locations for the Certificate Database and Certificate Database Log. Note that when the server is part of an Active Directory, it's typically not necessary to store configuration information in a shared folder. Click Next.
7. Another warning dialog box will appear. This time it informs you that to complete the installation, the IIS must be stopped temporarily. Click Yes.
8. The wizard will now complete the installation of the Certificate Authority Services. Click Finish
9. Close the Add or Remove Components window.
The CA is now installed, and we can issue the necessary SSL certificate to our OWA virtual directories.
Creating the Certificate Request
Now that we have installed the online Certificate Authority Service, it's time to create the Certificate Request for our Exchange 2003 server's default Web site. Do the following:
1. Click Start | Administrative Tools | Internet Information Services (IIS) Manager.
2. Expand Web Sites, right-click Default Web Site, and select Properties.
3. Click the Directory Security tab
4.Under Secure Communications, click the Server Certificate button. You will be presented with the Web Server Certificate Wizard screen shown. Click Next.
5. Because we are going to create a new certificate, leave this screen to with its default settings. Click Next.
6. Because we’re configuring an online enterprise authority, select the Send the request immediately to an online certificate authority option from the Delayed or Immediate Request screen. Click Next.
7. In the next screen that appears, enter a name for the certificate in the Name text box . This is only a descriptive name, meaning it doesn’t affect the functionality of the certificate in any way, so enter something that describes the certificate. Because the default bit length key in most situations is sufficient, leave it at its default value of 1024. (This bit length is capable of generating 128-bit encryption, which is what we’re going to use.) Click Next.
8. We now have the option of specifying our organization and organizational unit. Using the defaults is just fine. Click Next.
9.In the screen that appears, we need to pay extra attention, since the common name reflects the external fully qualified domain name (FQDN). This is the address external users have to type in their browsers to access OWA from the Internet. If this common name doesn’t match the name (FQDN) that the OWA clients connect to, the client will see an error message. Type your site’s FQDN in the Common name field. Click Next.
10. Type your information in the Country/Region, State/province, and City/locality boxes. Click Next.
11.We now have the option of specifying the SSL port for the Web site. Because SSL typically uses port 443, leave the defaults. Click Next.
12.In following Figure, select the respective certification authority. Since we only have one in this example, leave the defaults. Click Next.
13.We now have a chance to review the information we specified throughout the IIS Certificate Wizard. If you find you made a mistake, this is your final chance to correct it. Carefully review the information in the Certificate Request Submission screen, and if you’re satisfied, click Next and then click Finish.
Note
Because the SSL certificates were created using an online CA, SSL has been enabled automatically (see Figure 5.28). If you used a third-party certificate or an offline CA, you would have to manually put a check mark in Require secure channel (SSL) and Require 128-bit encryption.
SSL has now been enabled on our default Web site using our own Enterprise Certificate Service. Let’s see if it works as it’s supposed to.
14. From a client, launch Internet Explorer, then type http://exchangeserver/exchange. You should see an error message like the one shown in Figure
15. Now type https://tests01/exchange instead. You will be presented with a Security Alert box like the one shown in Figure .
Note
The yellow warning icon tells us The name on the security certificate is invalid or does not match the name of the site. This is expected, since during this little test we aren’t accessing the site via its common name (mail.testdomain.com).
16.Click Yes. You will now be prompted for a valid username/password, as shown in Figure
17.Enter a valid username and password, and your OWA session will load (see Figure ).
Notice the little yellow lock icon in the lower-right corner of the screen; this indicates we’re viewing a secure site, so fortunately our SSL-enabled OWA site works correctly.
Allowing Password Changes Through OWA
In this section you will learn how to enable the Change Password functionality in OWA 2003.
Because of Microsoft’s Trustworthy Computing initiative, one of the OWA 2003 things that is disabled by default is the user’s option to change his or4 her account password through the OWA 2003 interface. As you might remember, this option was enabled by default in Exchange Server 2000, but many organizations actually disabled the feature because, before Windows 2000 Service Pack 4, it was considered quite insecure. Before Microsoft released Windows 2000 Service Pack 4, the technology for changing passwords through OWA (or more specifically, through IIS) was based on HTR files and an ISAPI extension (Ism.dll), which potentially exposes the Web server to quite a security risk because the ISAPI extension (Ism.dll) needed to run under the security context of System. This basically means that if the system is compromised, a hacker could get full control over the local machine.
Now the Change Password functionality has been modified to use Active Server Pages (ASPs), which makes the functionality more secure, since it is run under the configurable security context of the current process (such as DLLHost, which uses the user, IWAM_, by default).
Before adjusting the Change Password functionality in OWA 2003, you first need to implement SSL on your OWA server, as shown earlier in this chapter.
Creating the IISADMPWD Virtual Directory
We first need to create a new virtual directory in the IIS Manager, you should therefore do the following:
1. Log on to the Exchange server.
2. Click Start | All Programs | Administrative Tools | Internet Services Manager.
3. Expand Local Computer | Web Sites.
4. Right-click the Default Web Site and point to New, then click Virtual Directory.
5. The Virtual Directory Creation Wizard is launched. Click Next.
6. In the Virtual Directory Creation Wizard, type IISADMPWD in the Alias box, then click Next (see Figure).
7. You now need to specify the directory path. Type C:\windows\system32\inetsrv\iisadmpwd (see Figure), then click Next.
8.Verify that only the Read and Run scripts (such as ASP) check boxes are set, as shown in Figure , then click Next and then Finish.Note
Note
It’s important you only give Read and Run Scripts permissions in Step 8. Giving write permissions would allow a potential hacker to replace the scripts with his own versions!
As you can see in following Figure , we now have a IISADMPWD virtual directory under our default Web sites.
We now have to verify that the IISADMPWD virtual directory has anonymous access enabled. Otherwise, we can end up in situations where the client and server go into a so-called endless loop when you attempt to authenticate users who are prompted to change an expired password. You can read more about this issue in MS KB Article 275457: “IIS 5.0 May Loop Infinitely When A User Is Forced to Change Their Password,” at support.microsoft.com/?id=275457.
9. Right-click the IISADMPWD virtual directory, then select Properties.
10. Select the Directory Security tab, and then under Authentication and access control, click Edit (see Figure).
11. Put a check mark in the Enable anonymous access box, as shown in Figure .
12. Click OK twice and close the IIS Manager.
If you are running Exchange Server 2003 on a Windows Server 2000-based machine, there is one more thing to do: You need to reset the PasswordChangeFlags flag in the IIS 5.x Metabase to zero. This is done the following way:
13. Click Start | Run, and type CMD.
14. Change to the C:\Inetpub\Adminscripts directory by typing cd c:\inetpub\adminscripts, and type adsutil.vbs set w3svc/passwordchangeflags 0.
Enabling the Change Password Button in OWA
Now it’s time to make the Change Password button visible in OWA. You do this in the registry of the Exchange 2003 server:
1. On the Exchange server, click Start | Run and type Regedt32.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA (see Figure).
3. Change the value of DisablePassword REG_DWORD from 1 to 0 (see Figure)
4. Close the registry editor.
5. Restart the IIS Services—for example, by opening a command prompt and typing IISRESET.
Testing the Change Password Feature in OWA
We now need to check to see if the Change Password option is available, and last but not least, working as it’s supposed to:
1. Launch Internet Explorer.
2. Enter the URL to OWA—in this example, https://mail.testdomain.com.
3. Log on with your username and password.
4. Click the Options button.
5. In the Options window, scroll all the way to the bottom, and click the now visible Change Password button under Password (see Figure).
If it works, you will be presented with the window shown in Figure .
6. To test if we are able to actually change a password, fill out the fields with a valid user account, as shown in Figure 5.44, then click OK. You should now see a message stating that your password was changed successfully.
Depending on your organization’s specific setup, you might experience what is known as lag time (delayed change) when users change their passwords. This is especially true if your domain controllers are located at another site than the OWA servers.
Reality Check…
Be aware that if you have installed Exchange Server 2003 on a Windows Server 2000 machine (with SP3 or earlier), on which you also have run the Urlscan 2.5 security tool, you will get an error message when trying to change your password through OWA. The reason is that by default, the Urlscan 2.5 security tool blocks files with the .HTR extension. (Remember, Windows 2000 SP3 and earlier uses the HTR technology for changing passwords.) To resolve this problem, remove .htr from the Deny Scripts section of the urlscan.ini file (by default located in C:\WINDOWS\system32\inetsrv\urlscan). If you plan to install the Urlscan 2.5 security tool on your Exchange 2003 server, there are quite a few things you should take into consideration, so it’s highly recommended that you read MS KB article 823175, “Fine-Tuning and Known Issues When You Use the Urlscan Utility in an Exchange 2003 Environment,” at http://support.microsoft.com/?kbid=823175.
Note
If OWA is installed on a Windows Server 2000 with Service Pack 4 applied or on a Windows Server 2003-based computer, OWA uses the IIS 6.0 ASP Change Password program. Therefore, OWA is not affected by .htr files that are not enabled.
