9.5 Windows Server security features

Before we begin to discuss locking down our Exchange servers, it is important that we look at the role that the operating system and its core services play in making Exchange secure (or, conversely, the role they play in making Exchange insecure). This section explains the different features in Microsoft Windows Server and how Exchange 2000/2003 takes advantage of them. Many of these key features are not found in previous versions of the Microsoft Windows Servers family of products. They define a new environment in which the enterprise messaging system operates. It is necessary to understand these features because users need to know how the systems behave in other platform environments. The Windows Server security features that impact Exchange can be loosely categorized into two key areas:

1. Windows authentication and authorization

2. Windows Services security

9.5.1 Windows authentication and authorization

A key to securing your Exchange servers is to understand how Windows provides authentication and authorization to services and applications that run on it. Authentication provides a means to verify a requestor identity, and authorization ensures specific permissions. Since Exchange relies completely on Windows for these functions, it is crucial that you ensure that the security posture of your Windows environment and infrastructure and as well as the servers running Windows Server and Exchange are rock-solid. In this section, I will take a look at the important focus areas with regards to authentication and authorization.

The Windows AD and Exchange

The AD database on a domain controller replaces the Security Accounts Manager (SAM) in Windows NT 4.0 as the security database. Every object in AD that takes part in any security process needs to have a Security Identifier (SID). A SID is a sort of random identifier that is a globally unique, 96-digit number to identify users and computers. Unlike Exchange 5.5, Exchange 2000/2003 does not have its own separate directory service. Exchange 2000/2003 uses Windows AD to store its configuration and information about its mail entities. This has important management and security consequences. While an NT4 and Exchange 5.5 administrator had to manage two distinct objects (a user’s NT account object and a user’s Exchange mailbox object), a Windows and Exchange administrator now has to manage only a single object: the AD object. The two user objects have been unified into one AD object. The mailbox object of Exchange 5.5 is now stored as different properties of the AD user object. From a security point of view, this means that typical mail objects, such as a mailbox, now have a SID of a security principal associated with them. This is simply because they are linked to an AD user object. Table 9.1 shows the equivalents of the Exchange 5.5 directory objects in an AD Exchange 2000/2003 world. It discusses whether they are security, mail, or mailbox enabled. Security-enabled means you can use the object for any security-related operation (such as access control or delegation). Mail-enabled means that the object has a mail address to which you can send mail messages. Mailbox-enabled means the object has a mailbox on an Exchange 2000/2003 server or another messaging system that utilizes the AD.

There are two different sets of objects on Windows NT 4.0 and Exchange 5.5. The directory for Exchange 5.5 and earlier versions is separate from the directory (domain space) structure of Windows NT 4.0. However, these are unified in the Windows 2003/2003 AD, greatly reducing overall system administrative overhead as compared with managing two separate directory structures with NT 4.0 and earlier versions of Exchange. Essentially, the objects in Exchange 2000 and Windows 2000 are linked to a SID. Custom recipients in Exchange 5.5 are mail-enabled contacts in Exchange 2000/2003 and do not have a SID. Distribution lists are changed to groups. There are security groups with a SID and distribution groups without a SID. When an object does not have a SID, the object cannot be placed in the ACL. Table 9.1 illustrates the differences between Exchange 5.5 recipients and Exchange 2000/2003/AD recipients and how they are mapped when migrated. Finally, Windows defines various types of objects (shown in Table 9.2) that can be hosted in Active Directory and that Exchange 2000/2003 can utilize.

Table 9.1: Comparison of How Exchange 5.5 Objects Are Represented in the AD with Exchange 2000/2003

Exchange 5.5 Recipient Object	Windows AD Equivalent
Mailbox	A mailbox is a mailbox-enabled user. An e-mail address shows the Exchange server where the e-mail is to be routed. Mailboxes from Exchange 5.5 are replicated into the AD (using the Active Directory Connector) as users or contacts.
Distribution lists	A distribution list is a distribution group or a security group in the AD. Windows groups appear as distribution lists in an Exchange directory. The administrator can specify the group as a security group, which allows the group to be placed in an access control list. Whether a security group or a distribution group in the AD, both are mail enabled.
Custom pecipients	An AD mail-enabled contact is a custom recipient in an Exchange directory. It has an e-mail address associated with it, but not an Exchange mailbox. It does not have an SID and cannot log on.

Table 9.2: AD Objects That Are Mail Disabled, Mail Enabled, or Mailbox Enabled

Windows Object	Description
Mail disabled	Has no e-mail capability. A security group like Domain Admins is an example.
Mail enabled	Has an e-mail address but no mailbox. A distribution group is an example.
Mailbox enabled	Has an Exchange mailbox associated with it. Only Windows user accounts can be mailbox-enabled.

Kerberos authentication

Kerberos is the new security protocol for Windows Server, supplementing (and potentially replacing, longer term) NTLM authentication used in NT 4.0. It is provided natively within the Windows domain and is integrated into the administrative and security model. This is convenient since the administrator does not need to learn additional administrative tools to manage the infrastructure. Kerberos identifies the client through secured means to a DC. Kerberos authentication services are built into every Windows DC and CG server. When the user logs on, he or she authenticates to the Kerberos key distribution center (KDC). The KDC issues a ticket-granting ticket. The client then uses the ticket-granting ticket to access a service. A client who has the ticket to access the service can simply present the ticket for subsequent uses. All of the tickets are encrypted through public key technology, which is more secure than secret key encryption. Figure 9.1 shows the steps involved in Kerberos authentication with the Windows DC and member and an Exchange 2000/2003 mailbox server. In the Kerberos authentication environment, Exchange 2000/2003 is treated like a service. When the client needs to access Exchange, the client requests an Exchange service ticket from the KDC in the Windows DC. The service ticket is then used for authentication with the Exchange 2000/2003 server. For subsequent access to Exchange, the client uses the service ticket, and authentication is faster.

The Exchange services also use Kerberos to make a service logon to the DC through the local system account. The local system account uses computer credentials, which consist of the account and a password that is automatically changed every 7 days. This provides better security as compared with Exchange 5.5, which uses a site service account. The name of the Exchange 2000/2003 server is added to the Exchange Domain Servers Group, which is added to the ACL of the core objects. To facilitate the administration over what these accounts, and thus an Exchange server and its services, can do with other system, domain, and Exchange resources, Microsoft creates two groups during the Exchange 2000/2003 installation process. The two groups are the global group Exchange Domain Servers and the domain local group Exchange Enterprise Servers. Both groups contain machine accounts of servers running Exchange 2000/2003. The Exchange Domain Servers group contains all Exchange 2000/2003 servers of a domain; it is updated automatically when a new Exchange 2000/2003 server is installed in the domain. The name of the Exchange 2000/2003 Server is added to the Exchange Domain Servers Group, which is added to the ACL of the core Exchange objects. The Exchange Enterprise Servers group contains all Exchange Domain Servers groups from all domains in a Windows forest; it is updated by the Recipient Update Service (RUS). A member of the Exchange Enterprise Servers group can modify the properties of any mailbox- or mail-enabled object contained in its domain.

Figure 9.1: ient authentication to Exchange using Windows Kerberos.

Members of the Exchange Domain Servers group have read permissions to the Active Directory Exchange configuration container.

Important Exchange domain groups

Both the Exchange Domain Servers group and the Exchange Enterprise Servers group are powerful security objects and a careful understanding of these two groups is required by the Exchange administrator. By default, every Exchange server in the organization is a member of both of these security groups. Membership in either of these groups grants significant security permissions over the entire Exchange organization and all of its mailboxes. What’s worse, an errant or malicious Exchange administrator can add his or her user account to this group and escalate his or her privileges to open and log on to any mailbox in the organization. This means that as an Exchange administrator, I could open the CEO’s mailbox and send mail or access all objects as that user. The bottom line is that you must always “Trust your Administrators” (Microsoft’s mantra). However, you can also take steps recommended by Microsoft to increase the security of your Exchange organization. Microsoft recommends three steps be taken to address this situation and reduce the overall security risk:

1. Understand the Exchange security model: Take steps to ensure all administrators are aware of the risks and vulnerabilities, as well as the impacts, of their actions.

2. Use caution when installing Exchange servers on DCs: Windows DC access (locally to the console) enables easy privilege escalation. Whenever possible, keep Exchange administrators out of the Domain Admin group, and vice versa.

3. Implement the Exchange Domain Servers Lockdown (EDSLock) script: The EDSLock script will prevent Exchange administrators from mistakenly or maliciously elevating their permissions and accessing unauthorized mailboxes. EDSLock is discussed in Microsoft Knowledge Base article Q313807. This functionality is now built into Windows Server 2003.

Kerberos authentication delegation

If a client has already authenticated to Exchange 2000/2003 server A, and server A needs to request a resource from another server B running on another computer, server A can request the ticket on behalf of the client. This is possible because Kerberos supports authentication delegation. Authentication across different domains is also possible provided there is a trust relationship. It should also be noted that while trust is transitive for the computers in the same domain, for external domains and non-Windows systems, they are not transitive. They have to be explicitly set as NT 4.0–style trusts. Kerberos delegation is a property that can be set on the account and computer. The fact that the account is trusted for delegation means that any computer can forward the credentials of the account. A computer trusted for delegation can forward credentials to any other computer. An example of how authentication delegation is used in Exchange implementation is in multitier (front-end/back-end architecture) OWA. In this scenario, the Windows IIS server and Exchange 2000/2003 store are on separate computers in the same domain. The client needs to identify him or herself to the KDC, and using a forwardable flag on the ticket to the Windows IIS server, the client is authenticated through delegation when IIS needs to access the Exchange 2000/2003 store on another computer. The Kerberos ticket that IIS used has the authorization data of the user, not IIS. This is an improvement over NTLM, which does not support forwarding of credentials.

Access control with Exchange 2000/2003

Although the architecture of the Windows 2000/2003 access control model is very similar to the one used in Windows NT, it includes some critical new ACL extensions: property-based ACEs, object-type ACEs, better control over ACL inheritance, and the support for deny ACEs, property sets, and extended rights. When applied to AD objects, these extensions enable administrative delegation or the ability to delegate AD administrative tasks to different administrators. The Exchange 2000 access control model is fundamentally different from the one implemented in Exchange 5.5: Exchange 5.5 used its own access control model; Exchange 2000/2003 uses the Windows access control model. Every Exchange information store object now has a Windows security descriptor. Also, in Exchange 2000/ 2003, due to the integration with AD, access control can be set on directory objects. Every directory object has an NTSecurityDescriptor containing a Windows security descriptor. If you open up a mail enabled user-object in the AD Users and Computers MMC snap-in, you can examine both the AD security descriptor (in the Security tab) and the information store security descriptor (in the Exchange Advanced tab under Mailbox rights). Compared with its predecessor in NT 4.0, the new authentication and access control model in Windows 2003/2003 offers much more control over the inheritance of access control settings between parent and child objects. In Exchange 5.5, inheritance was fixed: If you set an ACL on the organization level, it was automatically inherited by all the sites in the organization. In Exchange 2000/2003, an administrator can enforce and block inheritance. Obviously, enforcement always has precedence over blocking.

Figure 9.2: Kerberos authentication used with an Exchange front-end/back-end architecture.

Public folder access control

It is also worthwhile to look at how the new access control model affects the way access control is set on Exchange 2000/2003 public folders. In Exchange 2000/2003, Microsoft has grouped all public folder access-control-related settings in the Permissions tab of a public folder’s properties. The tab shows three pushbuttons: one to set client permissions, one to set public folder administrator permissions, and another one to set ACLs on the AD public folder object. The last is a direct consequence of Exchange 2000’s integration with AD. Similar to 5.5, the client permission button lets an administrator set client permissions using predefined roles (author, contributor, and so forth). The roles mimic Windows object permissions; contrary to Exchange 5.5, they are now linked to security principals. The way public folder administrator permissions are set in Exchange 2000/2003 offers much more granularity than in Exchange 5.5. Exchange 2000/2003 includes permissions such as the ability to modify the public folder deleted-item retention period and to modify the public folder quotas, and so forth. Public folder access control in Exchange 2000/2003 involves three security descriptors: two on the public folder information store object (one for administrator, one for client permissions) and another on the public folder AD object.

Exchange administration roles

Another access control mechanism is an Exchange role. An Exchange role is a link that contains the SID and the Exchange 2000/2003 rights. They are essentially resource groups for Exchange administration. These roles are not defined in the directory, but rather in the Exchange stores. These roles are application driven and are customizable by the developer. A developer can define roles as part of the application design and then populate at deployment time with actual users and groups. In an Exchange 2000/2003 public folder store, the role-ACEs refer to the roles defined in the Exchange store. These roles are evaluated at run time and the security system of the store queries the role definition table for the contents of the role when the user accesses the public folder. Therefore, the changes in the roles are instantly updated. These changes in the access-level control are reflected in the Exchange public folder ACEs interface. User-level permissions, default message permissions, permissions on the AD object, and administrative permission on the objects contained in the store can be set.

Exchange System Manager (ESM) has the ability to delegate permissions. Rather than making this difficult, Microsoft has provided an Exchange Delegation Wizard. The wizard allows the top-level administrator in an Exchange organization to delegate permissions via these Exchange roles. Microsoft designed the roles to be scenario oriented so that the top level administrator can create junior admins based on the specific tasks that these roles need to accomplish. The role determines a specific and very granular set of permissions in the Windows AD. Table 9.3 illustrates the effective permissions of Exchange role-based administration at both the Exchange organizational (ORG) and the Administrative Group (AG) level.

Table 9.3: Effective Permissions for Exchange Role-Based Administrators

Effective Permissions	AG View	AG Admin	AG Full Admin	ORG View	ORG Admin	ORG Full Admin
Exchange View Only Admin (AG level)	*
Exchange Admin (AG level)	*	*
Exchange Full Admin (AG level)	*	*	*
Exchange View Only Admin (ORG level)
Exchange Admin (ORG level)
Exchange Full Admin (ORG level)			

*Permissions at the Local AG only.

Windows group policies and Exchange policies

Policies are another useful feature in Windows that are utilized by Exchange 2000/2003. A policy is a collection of configuration settings that you apply across objects. When a policy is changed, that change is propagated to every object to which the policy is applied. There are two types of policies that apply to Exchange 2000/2003—system policies and recipient policies.

System policies affect server-side objects such as mailbox stores, public folder stores, and individual servers. When making changes to system policies, you need to have permissions on all objects to which the system policy applies. Recipient policies are imposed on objects such as users and groups. Again, permissions are required when affecting changes to recipient policies. Please note that Exchange recipient and system policies are completely separate from Windows group policies. Windows and Exchange policies are a powerful tool for Exchange because they can trigger changes across an entire organization. Policies can play a vital role in Exchange 2000/2003 security measures. Policies, if improperly utilized or misconfigured, can also be a source of security issues, if they are not well managed.

9.5.2 Windows services security

Over the last few years security concerns have come to the forefront of our minds, and Microsoft has learned some lessons as well. In February 2002, Bill Gates launched Microsoft into the Trustworthy Computing (TWC) initiative that fundamentally changed not only how the company does business, but also how it builds software. Microsoft has invested huge amounts of money in making its products more secure by default. This has come about largely due to bad exposure and pressures that Microsoft faces in the industry because several major and public security outbreaks have been attributed to flaws or holes in Windows security. In addition, Microsoft has also fallen victim to devastating attacks over the last few years, such as “Code Red,” “Nimda,” and “SQL Slammer,” which have sunk the company’s reputation for secure software to all-time lows. In truth, much of the criticism and bad press Microsoft received was unfair. If you analyze security flaws over the last 5 years as reported on industry watch sites such as BugTraq (www.securityfocus.com), Microsoft’s security weaknesses actually pale in comparison with the number of vulnerabilities reported for competitors such as Linux and UNIX variants. Regardless of whether Microsoft’s security vulnerability exposure is real or imagined, the company has made great strides towards ensuring greater security. As part of the TWC initiative, Microsoft developers have had to attend training in writing more secure code: Products have been delayed weeks, even months, in order to perform extensive security audits on them before shipping, and a fundamental paradigm shift has occurred in Microsoft software development philosophy. Instead of focusing on making their products more user friendly and easier to administer (which sometimes comes at a cost to security), the company has become more aligned with the UNIX/Linux way of doing things—Secure by Default. Microsoft products such as Windows 2003 Server and Exchange Server 2003 that were shipping in 2003 were the first products to represent this paradigm shift, and I believe they will be substantially more secure out of the box (by default).

One area where this is strongly evident is in Windows core services. Services such as IIS, one of the most troublesome services from a vulnerability perspective, have not only become more secure but are no longer even installed by default. When you install Windows Server 2003, you now have to add specifically IIS to the installation in order to use this service with Windows. With all of the vulnerabilities reported over the last few years involving IIS, I cannot imagine what this one small change alone will do for the overall security of a default installation of Windows Server. To ensure base Windows security, I recommend three important measures: Windows auditing, the Microsoft Baseline Security Analyzer (MSBSA), and a Windows security checklist for your Exchange servers.

Windows auditing

Auditing gathers security-relevant information. Two tools available are Event Viewer and the Security Configuration Audit (SCA) tool. Event Viewer in Windows is extended to gather auditing information on several core operating system services, including the directory service, DNS service, and file-replication service. The SCA tool allows administrators to analyze the security of the system and reapply it. Both analysis and application are based on security templates that define values for a set of security-related system parameters. The administrative tool is also a snap-in. The security template is a set of predefined settings in terms of account policies, local policies, restricted groups, registry, file system, and system services. The settings are also classified into basic, compatible, secured, highly secured, and dedicated DC templates. These templates are later used to configure the SCA tool. The analyzer in the SCA tool is run to show whether there are discrepancies in the settings and templates. This is useful to check whether security policies are implemented and serve as another form of audit checking. This application has to be run on the local computer. Using SCA, you can analyze and configure file system and registry access control settings, system service startup parameters, membership in restricted groups, event log settings, account policies (such as password quality), and local policies (such as user rights). MOM and the Microsoft Audit Collection Service (MACS) can be valuable tools in this area as well.

The Microsoft Baseline Security Analyzer (MSBSA)

MSBSA is a tool that allows users to scan one or more Windows-based computers for common security misconfigurations. MSBSA will scan (MSBSA checks are detailed in Table 9.4) a Windows-based computer and check the operating system and other installed components, such as Windows Server’s IIS and SQL Server, for security misconfigurations and whether or not they are up to date with respect to recommended security updates. MSBSA can determine which critical security updates are applied to a system by referring to an Extensible Markup Language (XML) file ( mssecure.xml ) that is continuously updated by Microsoft and by using the HFNetChk tool technology. The XML file contains information about which security updates are available for particular Microsoft products. For Exchange, MSBSA specifically scans for critical security patch requirements to help ensure your Exchange server is locked down. This file contains security bulletin names and titles, and detailed data about product-specific security updates, including files in each update package and their versions and checksums; registry keys that were applied by the update installation package; information about which updates supersede others; related Microsoft Knowledge Base article numbers; and much more. If you would like to learn more about MSBSA, please see www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ tools/Tools/mbsahome.asp

Table 9.4: MSBSA Vulnerability Checks

Category	Specific Checks by MSBSA
Windows Core OS	Administrator Group membership Auditing Autologon enabled Unnecessary services Domain controller checks File system security Guest account Local account password strength OS version Password policy Restrict anonymous
IIS Service	MSADC and scripts virtual directories on IIS IISADMPWD virtual directory IIS on DC IIS lockdown tool IIS logging IIS parent paths IIS sample applications
Microsoft SQL Server	Members of the Sysadmin role Restricting CmdExec rights to Sysadmin SQL server local account passwords SQL server authentication mode SQL server BUILTIN\administrators in Sysadmin role SQL server directory access SQL server exposed “sa” account password SQL server guest account SQL server on DC SQL server registry key security SQL server service accounts
Desktop Applications	Internet Explorer security zones Office macro protection Outlook security zones

Windows security checklist for Exchange servers

Securing Windows Server is not a trivial task, but Microsoft takes this very seriously and provides ample resources that I will not attempt to duplicate. One example of this is Microsoft Windows Server Security Solution, which is a prescriptive to hardening and securing your Windows server. This Microsoft Prescriptive Architecture Guidance (PAG)—now called Microsoft solutions accelerators) document provides structured guidance to help you understand and implement the processes and decisions that must be made to secure your servers, and keep them secure. This prescriptive solution is aimed at reducing security vulnerabilities and lowering the costs of exposure and security management in the Windows environment. The detailed guidance focuses on providing a full life cycle’s advice on securing your Windows Server environment—risk assessment and analysis, securing specific critical Windows server roles, and operating a secure environment after the initial lockdown phases have completed. For more information, please see www.microsoft.com/technet/treeview/default.asp?url=/technet/ security/prodtech/windows/secwin2k/default.asp and www.microsoft.com/ technet/security/tools/ChkList/wsrvSec.asp. For the Windows 2003 Server Security Guide, see www.microsoft.com/downloads/details.aspx? displaylang=en&familyid=8a2643c1-0685-4d89-b655-521ea6c7b4db.

Microsoft also provides a checklist for securing Exchange servers and a complete Exchange Security Operations Guide available for free download. Security Operations for Exchange 2000 Server delivers the guidance necessary for IT pros to set up and operate a messaging and collaboration environment securely. This guide delivers procedures and best practices for system administrators to create and maintain a secure environment on servers running Exchange 2000/2003 with a focus on two specific server roles: OWA frontend servers and back-end servers. This guide is available on the Exchange Server Security site at: www.microsoft.com/technet/security/prodtech/mailexch/opsguide/. For a complete site on security checklists for Microsoft products, also see www.microsoft.com/technet/treeview/default.asp?url=/ technet/security/tools/tools.asp.

Windows 2000/2003 provides many new security enhancements compared with previous versions of Windows NT. Many of these security features require a significant amount of expertise in order to be properly leveraged and deployed. The administrator has to understand the different options available to enhance the overall security of the infrastructure. In an enterprise in which different platforms are available, it is necessary to also understand the level of security that can be implemented without causing interoperability issues. These features, found in both Windows Server and XP, provide a secure environment for messaging and collaboration with Exchange 2000/2003. These enhancements also provide a foundation for building additional levels of security into an Exchange deployment. In order to maximize these features, I recommend that you further delve into this technology to understand fully how it can be used with Exchange. In the next section, I will shift our focus to how we can lock down our Exchange deployments through improved network security, antivirus/antispam solutions, and message content security.