Chapter 3 - Securing Exchange 2000 Servers Based on Role

Article
03/24/2009

This chapter is part of the Security Operations Guide for Exchange 2000 Server.

In the previous chapter we examined some general recommendations for securing your Exchange 2000 environment. Now we look at the specifics of increasing the security of your Exchange 2000 servers based upon the role they perform in your IT environment.

Ensuring the security of Windows 2000 is fundamental to the security of Exchange 2000, as Exchange 2000 is an application that runs in a Windows 2000 environment. Security Operations Guide for Microsoft Windows 2000 gives you recommendations for securing particular server roles, and in this chapter we extend the recommendations given in that guide to incorporate Exchange 2000. We specifically examine the OWA front-end server and Exchange back-end server roles.

Note: This chapter is supplemental to the recommendations made in Chapters 3 and 4 of Security Operations Guide for Microsoft Windows 2000 Server. For your convenience those chapters have been included at the back of this book as Appendices A and B. For details on the rest of the guide, see the "More Information" section at the end of this chapter.

Test Environment

It is vital that you thoroughly assess any changes to the security of your IT systems in a test environment before you make any changes to your production environment. Your test environment should mimic your production environment as closely as possible. At the very least, it should include multiple domain controllers and each member server role you will have in the production environment.

Testing is necessary to establish that your environment is still functional after you make changes, but is also vital to ensure that you have increased the level of security as intended. You should thoroughly validate all changes and perform vulnerability assessments on the test environment.

Note: Before anyone performs vulnerability assessments in your organization, you should ensure that they have obtained written permission to do so.

Using OWA Front-End and Back-End Servers

By default, every Exchange 2000 server has OWA functionality, allowing users to connect to their Exchange server via Hypertext Transfer Protocol (HTTP). This is possible because the components that make up the OWA solution are installed on an Exchange server in a default installation. However, in most medium to large scale environments it is better to implement a front-end/back-end solution to allow access to OWA. In this case users connect to the front-end server, which then accepts the request, verifies user credentials in Active Directory, and then forwards the request to the appropriate back-end Exchange server. The back-end server provides access to mailboxes and public folders. This provides the following benefits:

Users do not have to know the name of their local Exchange server in order to access it.
The name of the servers holding the mailboxes are hidden.
The front-end servers can be load balanced.
Secure Sockets Layer (SSL) overhead can be offloaded to the front-end server.
You can further secure the back-end server behind additional firewalls.

Note: Front-end servers can also be used for connections over POP3 and IMAP4. However, in this guide we are assuming that you will only be enabling HTTP and MAPI connections.

Note: For a detailed discussion of OWA front-end/back-end server environments in Exchange, see the "More Information" section at the end of this chapter.

Securing Server Roles for an Exchange 2000 Environment

For this guide, we have supplied security templates to modify the security on the Exchange 2000 server roles. You will need to import these templates into your Group Policy settings in order for them to be applied to Exchange.

The following table defines the server roles and the templates used to increase their security.

Table 3.1 Exchange 2000 Server Roles

Server Role	Description	Security Templates
OWA Server	Dedicated OWA front-end server for Outlook Web Access	Baseline.inf and OWA front-end Incremental.inf
Exchange 2000 back-end server	Server for mailbox, public folder access and routing	Baseline.inf and Exchange back-end Incremental.inf

In addition to the templates specified above, you will also need to apply an additional security template to your Baseline Group Policy for domain controllers. The settings defined in Security Operations Guide for Microsoft Windows 2000 Server do not assume that Exchange will be part of your environment and so therefore require alteration to accommodate Exchange 2000.

To modify your domain controller settings, allowing them to support Exchange operations, we supply a template Exchange DC Incremental.inf. This should be imported into a Group Policy object (GPO)at the Domain Controllers organizational unit (OU). In fact only one setting is changed, the security option shown in the table.

Table 3.2 Security Option on Domain Controllers to Support Exchange 2000

Option	Security Operations for Windows 2000 Server	Security Operations for Exchange 2000 Server
Additional restrictions for anonymous connections	No access without explicit anonymous connections	None. Rely on default permissions.
Shut down your system immediately if unable to log security audits	Enabled	Disabled
Account logon event auditing	Success and Failure	Failure
Logon event auditing	Success and Failure	Failure

The anonymous restriction setting needs to be changed because Outlook 2000 and 2002 clients will contact the global catalog server anonymously for information. With the settings defined in Security Operations Guide for Microsoft Windows 2000 Server, Outlook users are unable to send internal mail and will have to use external addresses.

Note: For more information on this issue see the Knowledge Base article 309622, "XADM: Clients Cannot Browse the Global Address List After You Apply the 299687 Windows 2000 Security Hotfix."

The other settings are modified because of the large number of success logon events that Exchange 2000 generates. If success auditing is enabled for logon events the security log will be rapidly filled.

Note: For more information on this issue see the Knowledge Base article 316685, "Active Directory-Integrated Domain Name Is Not Displayed in DNS Snap-in with Event ID 4000 and 4013 Messages."

Active Directory Structure to Support Exchange 2000 Server Roles

Security Operations Guide for Microsoft Windows 2000 Server recommends an OU structure that allows you to easily adopt the security templates supplied. The OU structure recommended in that guide can easily be extended to incorporate the two new server roles defined here. Exchange 2000 is an application, so we create an Exchange Servers OU under the Application Servers OU and add further OUs for these server roles under the Exchange Servers OU.

The diagram below shows the OU structure recommended to accommodate the two new server roles:

Figure 3.1: OU Structure with the Exchange Server and Application Server OUs added

Note: Creating the OU structure to support the recommendations in this guide is covered in much more detail in Security Operations Guide for Microsoft Windows 2000 Server.

Importing the Security Templates

The security templates described below are contained in the ExSecurityOps.exe file included with the guide. You will need to extract this file prior to importing the security templates. If you are using Windows 2000, Service Pack 2, you will also need to ensure that you have applied the hotfixes detailed in the following Knowledge Base articles:

295444: SCE Cannot Alter a Service's SACL Entry in the Registry.
272560: Race Condition May Lead to Loss of Group Policy Changes

Note: You will have to contact Microsoft Product Support Services (PSS) to obtain the hotfixes discussed in the above Knowledge Base articles. More information on contacting PSS can be found at https://support.microsoft.com.

Warning The security templates in this guide are designed to increase security in your environment. It is quite possible that by installing the templates included with this guide, you will lose functionality in your environment. This could include the failure of mission critical applications. It is therefore ESSENTIAL that you thoroughly test these templates before deploying them in a production environment, and make any changes to them that are appropriate for your environment. Back up each domain controller and server prior to applying new security settings. Make sure the system state is included in the backup, because this is where the registry data is kept, and on domain controllers it also includes all of the objects in Active Directory.

Note: The Domain Controller Baseline Policy and the Member Server Baseline Policy included in Security Operations Guide for Microsoft Windows 2000 set the LAN Manager Authentication level at NTLMv2 only. For Outlook clients to successfully communicate with Exchange servers and domain controllers they will also have to be configured to use NTLMv2 only.

The following procedure imports the security templates included with the guide into the OU structure suggested in this chapter.

To create the Domain Controller Group Policy Object and import the Security Template

In Active Directory Users and Computers, right-click Domain Controllers, and then select Properties.
On the Group Policy tab, click New to add a new Group Policy object.
Type Exchange DC Policy and press Enter.
Click Up until the Exchange DC Policy is at the top of the list.
Click Edit.
Expand Windows Settings, right-click Security Settings, and select Import Policy.

Note: If Import Policy does not appear on the menu, close the Group Policy window and repeat steps 4 and 5.
In the Import Policy From dialog box, navigate to C:\SecurityOps\Templates, and double-click Exchange DC Incremental.inf.
Close Group Policy and then click OK.
Force replication between your domain controllers so that all domain controllers have the policy.
Verify in Event Log that the policy was downloaded successfully and that the server can communicate with the other domain controllers in the domain.
Restart each domain controller one at a time to ensure that it reboots successfully.

To create the Exchange Server Group Policy Objects and Import the Security Templates

In Active Directory Users and Computers, expand Member Servers, expand Application Servers, expand Exchange Servers, right-click OWA Front-End Servers, and then select Properties.
On the Group Policy tab, click New to add a new Group Policy object.
Type OWA Policy and press Enter.
Click Edit.
Expand Windows Settings, right-click Security Settings, and select Import Policy.

Note: If Import Policy does not appear on the menu, close the Group Policy window and repeat steps 4 and 5.
In the Import Policy From dialog box, navigate to C:\SecurityOps\Templates, and double-click OWA Front-end Incremental.inf.
Close Group Policy and then click OK.
Repeat steps 1 through 7 for the Back-end Servers OU with Exchange Back-end Incremental.inf
Force replication between your domain controllers so that all domain controllers have the policy.
Move a server for each role into the appropriate OU.
On the server download the policy by using the secedit /refreshpolicy machine_policy /enforce command.
Verify in Event Log that the policy was downloaded successfully and that the server can communicate with the domain controllers and with other servers in the domain. After successfully testing one server in the OU, move the remaining servers in the OU and then apply security.

Note: For more information on verifying the success of the Group Policy download, see Appendix A: "Chapter 3: Managing Security with Windows 2000 Group Policy" of Security Operations Guide for Microsoft Windows 2000 Server.
Restart each server to ensure that they reboot successfully.

Exchange Server Policies

It is possible to define a large number of security settings in Windows 2000, including auditing, security options, registry settings, file permissions and services. In Security Operations Guide for Microsoft Windows 2000 Server we make suggestions for many of these settings and these recommendations do not need to be changed for Exchange 2000. The main area where additional settings are applied is for services, although we also make some file permission changes.

As they reside in OUs below the Member Servers OU, the Exchange servers inherit settings defined in the Member Server Baseline Policy. The Exchange policies modify those settings in two ways. First, some services that are not required for basic Windows 2000 functionality are needed for successful Exchange 2000 operations. Second, Exchange 2000 introduces a number of extra services, not all of which are required to allow the Exchange servers to function in their particular roles.

Note: Although not explicitly mentioned in the Exchange incremental policies, Network News Transfer Protocol (NNTP) is disabled by the Windows 2000 Member Server Baseline Policy. This service is required to install Exchange, but it is not needed for Exchange operations unless you require newsgroup functionality.

Exchange Back-End Server Policy

The Exchange Server Back-end Policy defines settings in two areas — services and file access control lists.

Exchange Back-End Server Services Policy

The table shows the services specified in the Exchange 2000 back-end policy:

Table 3.3 Services Configured in the Exchange Server Back-end Baseline Policy

Service Name	Startup Mode	Reason
Microsoft Exchange IMAP4	Disabled	Server not configured for IMAP4
Microsoft Exchange Information Store	Automatic	Needed to access Mailbox and Public Folder Stores
Microsoft Exchange POP3	Disabled	Server not configured for POP3
Microsoft Search	Disabled	Not required for core functionality
Microsoft Exchange Event Service	Disabled	Only needed for backwards compatibility
Microsoft Exchange Site Replication Service	Disabled	Only needed for backwards compatibility
Microsoft Exchange Management	Automatic	Required for message tracking to function
Windows Management Instrumentation	Automatic	Required for Microsoft Exchange management
Microsoft Exchange MTA Stacks	Automatic	Required for move user operations and needed for backwards compatibility or if there are X.400 connectors.
Microsoft Exchange System Attendant	Automatic	Needed for Exchange maintenance and other tasks
Microsoft Exchange Routing Engine	Automatic	Needed to coordinate message transfer between Exchange servers
IPSEC Policy Agent	Automatic	Needed to implement IPSec policy on server
RPC Locator	Automatic	Needed for communication with domain controllers and clients
IIS Admin Service	Automatic	Required by Exchange routing engine
NTLM Security Support Provider	Automatic	System Attendant depends on this service
SMTP	Automatic	Required for Exchange transport
World Wide Web Publishing Service	Automatic	Required for communication with OWA front-end servers

Note: The Exchange System Attendant depends on the following services to be up and running before it will start:

Event Log
NTLM Security Support Provider
RPC
RPC Locator
Server
Workstation

Key Services that Are Disabled

For the purposes of this guide we have disabled all the services that are not essential for the core functionality of Exchange 2000. In some cases you may need to re-enable services, providing you with the functionality you require in your environment. Here is a description of the key services disabled by the Back-end Server Incremental Policy.

Event Service

Introduced in Exchange Server 5.5, the Exchange Server Event Service supports server-side scripts triggered by folder events, either in public folders or individual mailboxes. Exchange Event Service is provided in Exchange 2000 for backward compatibility with Exchange 5.5 event scripts. New applications written specifically for Exchange 2000 should use native Web Storage System Events instead of Exchange Event Service, as described in the Exchange 2000 Software Development Kit (SDK) available on MSDN, see the "More Information" section for further details.

Microsoft Search

The information store process creates and manages indexes for common key fields for faster lookups and searches of documents that reside in a store. An index allows Outlook users to search for documents more easily. With full-text indexing, the index is built prior to the client search, thus enabling faster searches. Text attachments can be included in the full-text indexing.

Indexing is provided by the Microsoft Search service. Both the Information Store service and the Search service must be running for the index to be created, updated, or deleted.

Microsoft Exchange Site Replication Service

The service responsible for replicating Exchange 5.x site and configuration information to the configuration naming partition of Active Directory when an Exchange 2000 server belongs to an existing Exchange 5.5 site.

Exchange Back-End Server File Access Control Lists Policy

The Exchange Back-end Server Policy modifies access control lists (ACL) on several directories. The table shows the settings that are defined.

Table 3.4 File Access Control Lists Configured by the Exchange Back-end Server Policy

Directory	Old ACL	New ACL	Applied to Subdirectories?
%systremdrive%\Inetpub\mailroot	Everyone: Full Access	Domain Admins: Full Access Local System: Full Access	Yes
%systremdrive%\Inetpub\nntpfile\	Everyone: Full Access	Domain Admins: Full Access Local System: Full Access	Yes
%systremdrive%\Inetpub\nntpfile\root	Everyone: Full Access	Everyone: Full Access	Yes

%systremdrive%\Inetpub\mailroot

Everyone: Full Access

Domain Admins: Full Access

Local System: Full Access

Yes

%systremdrive%\Inetpub\nntpfile\

Everyone: Full Access

Domain Admins: Full Access

Local System: Full Access

Yes

%systremdrive%\Inetpub\nntpfile\root

Everyone: Full Access

Yes

Note: The settings defined on the nntpfile directory and subdirectories are not strictly required as NNTP does not run on the server. However, we define the setting as it increases restrictions on the file system and is ready to use in case you later decide to enable NNTP.

OWA Front-End Server Policy

The OWA Front-end Policy defines settings in two areas – services and file access control lists.

OWA Front-End Server Services Policy

Since the role of this server is to only support Web-based e-mail, many of the Exchange services installed by the default configuration can be disabled. The table shows the services that are configured in the OWA Front-end Server Policy.

Table 3.5 Services configured in the OWA Front-end Server Policy

Service Name	Startup Mode	Reason
Microsoft Exchange IMAP4	Disabled	OWA server not configured for IMAP4
Microsoft Exchange Information Store	Disabled	Not required as there is no Mailbox Store or Public Folder Store
Microsoft Exchange POP3	Disabled	OWA server not configured for POP3
Microsoft Search	Disabled	No stores to search
Microsoft Exchange Event	Disabled	Only needed for backwards compatibility
Microsoft Exchange Site Replication Service	Disabled	Only needed for backwards compatibility
Microsoft Exchange Management	Disabled	Required for message tracking
Microsoft Exchange MTA	Disabled	Only needed for backwards compatibility or if there are X.400 connectors
Microsoft Exchange Routing Engine	Automatic	Provides Exchange routing functionality
IPSEC Policy Agent	Automatic	Needed to implement IPSec filter on OWA server
RPC Locator	Automatic	Needed for communication with domain controller and required for system attendant to start
IIS Admin Service	Automatic	Required by MSExchange routing engine
World Wide Web Publishing Service	Automatic	Required for communication with OWA front-end servers

Key Services Disabled in the OWA Front-End Server Policy

As with the back-end configuration, you may need to re-enable some services, providing you with the functionality you require in your environment. Here is a description of the key services disabled by the OWA Front-end Server Incremental Policy.

Microsoft Exchange POP3 and Microsoft Exchange IMAP4

As already mentioned in Chapter 2, you should determine whether you need the full functionality of Exchange in your environment. In many cases you will not have POP3 or IMAP4 clients and so you can ensure that these services are disabled by Group Policy. You should also confirm that you do not have any custom programs running in your environment that require this functionality before you disable it.

System Attendant

On a front-end server, the System Attendant is only required if you wish to make configuration changes to the server. We therefore disable the System Attendant in the template. This means that to make any changes to a server which uses the OWA Front-end Server Policy (including making the server an OWA Front-end server), you need to temporarily start the System Attendant and associated services first.

To make a change to the configuration of a server with the OWA Front-end Server Group Policy applied

Start the Services administrative tool.
Right-click NTLM Security Support Provider and select Properties.
In the Startup Type drop down list box, select Automatic.
Click Apply.
Click Start.
Click OK.
Repeat steps 2 through 6 for System Attendant.
Make any configuration changes you require.
Start the Services administrative tool.
Right-click System Attendant and select Properties.
In the Startup Type drop down list box, select Disabled.
Click Apply.
Click Stop.
Click OK.
Repeat steps 2 through 6 for NTLM Security Support Provider.

Information Store

The Information Store service is not required since no mail is delivered to this server. With no Information Store service, the M: mapped drive that you normally find on all Exchange 2000 servers will be removed. This is to be expected, as the Exchange installable file system will have nothing to map to.

Microsoft Exchange Management

This service was introduced as part of Exchange 2000 Server, Service Pack 2. The service allows you to specify, through the user interface, which domain controller or global catalog server Exchange 2000 will use when accessing the directory. It is also required for message tracking. You can disable this service without affecting the core functionality of Exchange. However, you will probably find that you require Message Tracking as part of your auditing of Exchange functionality. In this case, the OWA front-end server is used to access mail rather than to route mail, you should not find that the Microsoft Exchange Management Service needs to run on your OWA front-end servers.

SMTP Service

The OWA front-end server does not require SMTP in this case because it is only acting as an OWA server. You will need to enable the SMTP service, if you have configured your front-end server to receive SMTP mail, either to act as a gateway, or as a front-end server for IMAP4 or POP3.

OWA Front-End Server File Access Control Lists Policy

The policy defines file access control lists in exactly the same way as the Back-end Server Policy. For details, see "Exchange Back-End Server File Access Control Lists Policy" earlier in this chapter.

Installing and Updating Exchange in an Increased Security Environment

If you have followed the procedures specified so far in this chapter, you will have moved existing Exchange servers into the appropriate OUs to increase the level of security in your environment. To maximize your security, new servers must be moved into the appropriate OU prior to installing Exchange. However, while the environment will allow core Exchange services to run, it will not, by default, allow Exchange to install, or allow you to upgrade Exchange to future service packs. To install Exchange or Exchange Service Packs on locked down servers, use the following procedure.

Note: When installing Exchange 2000 on a server that has already been secured, you will receive "Digital Signature Not Found" errors. This is a result of the increased security on the server and can be bypassed.

To install Exchange or an Exchange Service Pack on a locked down server

Start the Services administrative tool.
Right-click Distributed Transaction Coordinator and select Properties.
In the Startup Type drop down list box, select Automatic.
Click Apply.
Click Start.
Click OK.
Repeat steps 2 through 6 for Network News Transport Protocol (NNTP) and Windows Installer.

Note: If you are performing these steps on a server in the OWA Front-End OU, also repeat steps 2 through 6 for Windows Management Instrumentation.
Install Exchange 2000 or the latest Exchange 2000 Service Pack.

Note: When installing Exchange 2000, at the end of setup a dialog box may appear indicating a non-fatal setup error occurred because the Microsoft Search service did not start. This is expected when installing an already secured server and can safely be ignored.
Start the Services administrative tool.
Right-click Distributed Transaction Coordinator and select Properties.
In the Startup Type drop down list box, select Disabled.
Click Apply.
Click Stop.
Click OK.
Repeat steps 2 through 6 for Network News Transport Protocol (NNTP) and Windows Installer.

Note: If you are performing these steps on a server in the OWA Front-End OU, also repeat steps 9 through 14 for Windows Management Instrumentation.

Note: The incremental policies for OWA front-end and Exchange back-end servers enable NTLMv2. This allows the Exchange servers to communicate with your secured domain controllers. If you do not place your servers in the appropriate OU prior to installing Exchange, the servers will not be able to contact domain controllers.

Additional Security Measures

In addition to the enhanced security provided by the Group Policy templates, there are additional security measures that should be implemented on Exchange 2000 servers. This section covers those measures.

IIS Lockdown Tool

After the security template is applied to your Exchange 2000 servers, you will need to apply additional security controls on IIS, particularly on your OWA front-end servers. To automate many of the changes to IIS, the IIS Lockdown tool can be used. IIS Lockdown will specify settings needed to harden IIS, but still allow Exchange 2000 to function as either a back-end server or an OWA front-end server.

Note: The IIS Lockdown tool can be obtained from https://www.microsoft.com/technet/security/tools/locktool.mspx

The IIS Lockdown tool has two modes: an express mode appropriate for most basic Web servers and an advanced mode that allows administrators to pick and choose the technologies the server will support. The tool provides an undo feature that allows the effects of the most recent lockdown to be reversed.

IIS Lockdown also implements URLScan, which screens all incoming requests to an IIS server and only allows those that comply with a specific rule set to pass. This significantly improves the security of the server by helping to ensure that it responds only to valid requests. URLScan allows you to filter requests based on length, character set, content and other factors. A default rule set is provided, which can be customized to meet the needs of a particular server.

To lockdown Exchange 2000 OWA front-end servers

Install and start IISLockd.exe on your server.
Click Next.
Read the license agreement, select I Agree, and then click Next.
Select the server template Exchange 2000 (OWA, PF Management, IM, SMTP, NNTP), select the View Template check box, and then click Next.
In the Internet Services dialog box, four services will be displayed (Web Service (HTTP), FTP, SMTP, and NNTP). If the check box is dimmed for a specific service, then that service is either not installed or already disabled. Make sure that only Web Service (HTTP) is enabled and click Next to continue.

Note: If IIS Lockdown is executed after applying the OWA front-end security template from the Group Policy object, then the Web Service (HTTP) should be the only service displayed as enabled while all the other services are disabled.

The Script Maps dialog box allows you to disable support for specific ISAPI applications by removing their associated script map. The table shows the default settings that are implemented within the Exchange 2000 template. Only Active Server Pages will be enabled. All other script mappings will be disabled. Click Next.

Table 3.6 Default Script Mapping Settings in the Exchange 2000 Template for IISLockDown

Type	Entry	Status
Active Server Pages	.asp	Enabled
Index Server Web Interface	.htw, .ide, .idq	Disabled
Server-side Includes	.stm, .shtm, .shtml	Disabled
Internet Data Connector	.idc	Disabled
HTR Scripting	.htr	Disabled
Internet Printing	.printer	Disabled

Note: If you disable support for the .htr script map then the OWA change password feature will not work. This OWA feature is disabled by default by IIS LockDown.

The options in the Additional Security dialog box allow you to remove the default virtual directories that are created from the default IIS installation, and apply file ACLs to specific directories and to all the system32 executables. Click Next to continue.

The table shows the virtual directories that will be removed.

Table 3.7 Virtual Directories Removed by IISLockdown

Name	Virtual Directory	Default Location
IIS Samples	\IISSamples	c:\inetpub\iissamples
IISHelp	\IISHelp	c:\winnt\help\iishelp
MSADC	\MSADC	c:\program files\common files\system\msadc
Scripts	\Scripts	c:\inetpub\scripts
IISAdmin	\IISAdmin	c:\winnt\system32\inetsrv\iisadmin

To restrict access to the file system, IIS Lockdown will create two new local groups on the OWA server called Web Anonymous Users and Web Applications. It will place any anonymous users or anonymous application accounts in the applicable group. Typically, IUSR_<computername> will be placed in the Web Anonymous Users group and IWAM_<computername> will be placed in the Web Applications group. IIS Lockdown will then set permission denying write access for these groups to the specific directories

C:\inetpub\wwwroot

C:\Program Files\Exchsrvr\ExchWeb

and also denying execute access to all system utilities, such as cmd.exe, in the c:\winnt\system32 folder. Remember that Group Policy from the baseline template will apply a specific access control entry (ACE) to the executables in the system directory allowing only Administrators Full Control and no other users or groups will be defined. These settings will override the IIS Lockdown setting when Group Policy is reapplied.

You will now be prompted to install the URLScan. By default it is already checked to be installed. Click Next.
Review the tasks to be performed and then click Next.
The Installing Unknown Software Package dialog box appears because of the increased security, click Yes.
IIS Lockdown will produce a report detailing the changes that were made and if there are any errors to report. You will see errors in the report that IIS Lockdown failed to ACL some NTFS directories. These directories are the mailbox and public folders that were deleted as part of the OWA server configuration. Click Next.
Click Finish.

Note: To run IIS Lockdown on an Exchange 2000 back-end server, repeat the above procedure and in step 5 ensure that HTTP and SMTP are enabled.

Modifying IIS Lockdown and URLScan Settings for OWA Front-End Servers

You may need to modify the default IIS Lockdown and URLScan settings for your environment. The URLScan settings are stored in the URLScan.ini file located in <WinDir>\System32\Inetsrv\Urlscan. If you encounter any issues with OWA and UrlScan is enabled, examine the Urlscan.log file in <WinDir>\System32\Inetsrv\Urlscan for the list of requests that are being rejected.

Note: For information on troubleshooting and configuring IIS Lockdown and URLScan, see the Knowledge Base article 309508 "XCCC: IIS Lockdown and URLscan Configurations in an Exchange Environment"

Change Password Support in OWA

By default, IIS Lockdown disabled .htr files. When this file type is disabled, the OWA Change Password feature does not function. If .htr files are disabled, you should also hide the Change Password button in OWA to avoid user confusion and help desk calls.

Note: For information on disabling the Change Password button in OWA, see the Knowledge Base article, "297121 XWEB: How to Hide the "Change Password" Button on the Outlook Web Access Options Page."

Blocked E-Mail

The [DenyUrlSequences] section of the URLScan.ini file, lists characters that are explicitly blocked can potentially affect access to OWA. Any e-mail subject or mail folder name that contains any of the following character sequences is blocked:

Note: The ".." in the URLScan.ini file will block e-mail messages with a subject line that ends with a period character.

Dismounting the Mailbox Store and Deleting the Public Folder Store

As the role of the OWA front-end server is to forward requests to the back-end servers, you do not need Exchange Server mailboxes or public folders on the OWA front-end servers. The back-end Exchange server will manage them. You can therefore dismount and delete these stores.

To dismount and delete the mailbox and public folder databases

Start the Services administrative tool.
Right-click NTLM Security Support Provider and select Properties.
In the Startup Type drop down list box, select Automatic.
Click Apply.
Click Start.
Click OK.
Repeat steps 2 through 6 for System Attendant.
Start Exchange System Manager on the OWA front-end server.
Expand Servers, expand the OWA front-end server, and then expand First Storage Group.
If the mailbox store is mounted, right-click Mailbox Store, select Dismount Store, and then click Yes to dismount the mailbox store.
Right-click Mailbox Store and select Properties.
Select the Database tab, click the Do not mount this store at start-up check box, and then click OK.
If the public folder store is mounted, right-click Public Folder Store, select Dismount Store, and then click Yes to dismount the public folder store.
Right-click Public Folder Store and select Delete.
Click Yes, click OK, select a back-end server, and then click OK.
Click Yes to delete the public folder store, and then click OK to close the message.
Restart the OWA Server.

Note: You do not need to disable the NTLM Security Support Provider and the System Attendant again as this will happen automatically when the server is rebooted.

Note: The private store needs to be mounted if you have SMTP running on the front-end server.

Note: Once the mailbox store and public folder store are dismounted, the M: mapped drive that you normally find on all Exchange 2000 servers will be removed. This is to be expected, as the Exchange installable file system will have nothing to map to.

You will notice event errors (Event ID 101) in the system log indicating that the path to a specific virtual directory is invalid. These virtual directories, "public, Exchange, and Exadmin", will also display a status of "Stop" in the Internet Services Manager console. These errors will be produced after the Exchange Server is installed on the IIS server and then the server is rebooted. After a reboot, the IIS (W3SVC) service will start up before the Exchange Information Store service starts. The Information Store service is responsible for creating the mapped virtual drive (M:) that these 3 virtual directories are assigned to and since the mapped drive is not created yet, IIS will produce the error messages. Since the Information Store service is disabled when security is applied through Group Policy, the mapped virtual drive will never be mounted and these errors will continue to appear in the Event Log. However, they are completely harmless.

Note: For more information on the Event Log ID 101, see Knowledge Base article 259373, "XADM: W3SVC Logs Event ID 101 in the System Event Log."

The less information you provide an attacker, the more difficult it is to attack your system. One way an attacker may attempt to gain information about which version of Exchange is being run is to use Telnet to connect to the SMTP service. By default, when you connect to the SMTP service on an Exchange server, the following banner is displayed:

220 hostname.domain.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.1600 ready at current date and time.

You should consider changing this on all back-end Exchange servers so that it does not display the specific version. You may also wish to include a legal statement that unauthorized use of the SMTP service is prohibited.

To modify the Windows 2000 SMTP banner

Using a metabase editing tool such as MetaEdit, locate:

Lm\Smtpsvc\ virtual server number.
Click Edit, click New, and then click String.
Verify that the entry in the ID box is Other, and then type 36907 (decimal) on the right side of the ID box.
In the Data box, type the banner that you want to be displayed.
Stop, and then restart the SMTP virtual server or the SMTP service.

To confirm that the banner has been changed, Telnet to port 25 of the virtual server (the default setting). The "ESMTP MAIL Service, Version: 5.0.2195.1600" banner should no longer be displayed. However the fully qualified domain dame (as it was entered in the SMTP service properties) and the date and time are still displayed.

Group Lockdown for Exchange Domain Servers

As part of a default installation, an Exchange Domain Servers group is created for each domain within the forest. This group contains the computer accounts for each Exchange server within a given domain. By default the Exchange Domain Servers groups are granted access to all Exchange public folder and mailbox stores in the forest. You can restrict access to mailbox stores to only the local server that hosts the stores by running the EDSLock script.

Note: For further details on the EDSLock script see Knowledge Base article 313807, "XADM: Enhancing the Security of Exchange 2000 for the Exchange Domain Servers Group."

Exchange Cluster Considerations

Exchange 2000 in a clustered environment is not within the scope of this guide. However, it is clear that you will need to make certain changes to the security settings shown here to allow Exchange 2000 to work in a clustered environment. These include:

Enabling NTLM on the cluster servers and domain controllers as NTLMv2 is not supported on Windows 2000 clusters, see the Knowledge Base article 272129, "Cluster Service Does Not Start on "Joining" Node in Windows 2000".
Modifying the setting for the NTLM Security Support Provider (NTLMSSP) in the Security Template for your Exchange back-end servers. NTLMSSP must be set to 0:

MACHINE\System\CurrentControlSet\Control\LSA\MSV1_0\NtlmMinServerSec=4,0
Enabling the Cluster service in the Security template for your Exchange back-end servers.
Not implementing IPSec for OWA front-end/back-end communication as IPSec is not supported on clusters, see Knowledge Base article 306677, "IPSec Is Not Designed for Failover".

Summary

Increasing the security of your Exchange Servers is a vital part of securing your enterprise. If you follow the advice listed in this and the previous chapter, along with increasing the security of your Windows 2000 environment, you will significantly reduce the risk of successful attack against your Exchange environment.