Lesson 3: Exchange 2000 Server and the Windows 2000 Security Architecture | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Exchange 2000 Server not only stores the vast majority of its configuration and recipient information in Active Directory, it also integrates with the Windows 2000 security architecture for controlling access to its resources. This integration has several consequences. For instance, as soon as you install the first Exchange 2000 server in your environment, several Windows 2000 administrators automatically receive permissions to the Exchange 2000 organization. Exchange 2000 administration is now unified with Windows 2000, and it is not that simple to separate the management of user accounts and mailboxes or split the network and messaging administration.

This lesson discusses how Exchange 2000 Server integrates with the security architecture of Windows 2000 Server and how this affects user account and system management. It is vital to document and reevaluate existing administrative models and responsibilities for account, mailbox, and server management. To a large extent, your Exchange 2000 organization depends on the administrative structures implemented in Windows 2000 and Active Directory.

After this lesson, you will be able to

Explain how Windows 2000 security mechanisms are used to control and monitor access to the resources in an Exchange 2000 organization
Identify potential Exchange administrators for mailbox and system management
Analyze the suitability of existing administrative structures for an Exchange 2000 organization in different scenarios

Estimated time to complete this lesson: 60 minutes

Understanding Windows 2000 Security Mechanisms

Computer security relies on three essential processes often referred to as authentication, authorization, and auditing. Authentication refers to identifying users and systems, authorization entails granting or denying access to resources, and auditing means recording and analyzing security-related events that happen on your systems, such as user logons and object access, in a security log.

Authentication

Whenever you want to establish a session with a Windows 2000 server, either through a local logon or over the network, you need to provide security information to the operating system to identify yourself. Usually, Windows 2000 expects a user name and password. Correspondingly, a domain controller in your domain must find your user account in Active Directory to verify who you are. If the specified user account does not exist, if it is disabled, or if the password is incorrect, you are denied access.

Windows 2000 supports various authentication protocols, including the LAN Manager and Windows NT challenge/response protocol (NTLM), Kerberos version 5, Secure Sockets Layer/Transport Layer Security (SSL/TLS), and clear text. NTLM is the authentication protocol of Windows NT, supported in all Windows versions. Workstations running Windows 2000 Professional in a Windows 2000 domain prefer to use Kerberos. Between domains of different forests, Kerberos cannot be used and Windows 2000 machines fall back to NTLM. Internet-based clients utilize SSL/TLS and clear text. However, when transmitted in clear text over the Internet, user names and passwords may be exposed to eavesdroppers. You can prevent this through SSL encryption, which is discussed in more detail in Chapter 9, "Implementing Security for Hosted Services." For detailed information about individual authentication protocols, see the Microsoft Windows 2000 Server Resource Kit.

Authentication Across Domains

Recall that user accounts reside in the domain NC. Active Directory replicates this information only to the domain controllers in the local domain, but not across domain boundaries. Therefore, in the local domain, every domain controller is able to authenticate local users, but domain controllers in other domains are unable to perform the authentication. This arrangement implies that you cannot work with the resources in another domain. For instance, if you wanted to manage an Exchange 2000 server in a resource domain, the server would have to decline your logon attempt because your account does not exist in that domain. To allow you access, the server’s local domain must trust your home domain about the validity of your user account. If this trust relationship exists, the local domain controller forwards your account information to a domain controller in your home domain, which has the required information available to perform the authentication (Figure 3.18).

Trust relationships play an important role in every multiforest environment. In a single Active Directory forest, all domains trust each other automatically because Windows 2000 establishes two-way transitive trust relationships between them. However, domains in different forests and legacy Windows NT domains do not trust each other by default. Here, you need to configure trust relationships manually. These trusts are unidirectional and nontransitive, which means that you need to configure them separately in each domain.

Note

Forests and domains are elements of the logical Active Directory design. The logical design is independent of the physical network structure and driven by organizational (political) requirements. Enterprise and domain administrators are primary candidates for Exchange administrators.

Figure 3.18 - Authentication within and between domains

Security Identifiers

The most important information returned from the domain controller to the workstation during the process of authentication is the SID of your user account. The domain controller also returns the SIDs of all those groups to which you belong and information about your user rights. The collection of SIDs allows the operating system to determine whether you have the required permissions to access the desired resources, such as the configuration information of Exchange 2000 Server in Active Directory. User rights, on the other hand, pertain to the entire computer rather than a particular system object, such as the right to log on locally, access a computer from the network, and other privileges.

Windows 2000 SIDs uniquely identify user, security group, and machine accounts. Every account object associated with a SID is called a security principal. Basically, Windows 2000 knows you as Mr. or Ms. S-1-5-21-606747145-436374069-1708537768-500, who belongs to the groups S-1-5-21-606747145-436374069-1708537768-512 and S-1-5-21-606747145-436374069-1708537768-513. If you are interested in analyzing SIDs in your environment, open the following Registry key on your workstation:

 HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft  \Windows NT    \CurrentVersion  \ProfileList

You will find the SIDs of all users who logged on locally to your computer in the past (Figure 3.19).

Figure 3.19 - Two examples of security identifiers

Note

Distribution groups are not security principals because they do not own a SID and therefore cannot be used to grant or deny permissions.

Security Identifiers in Multidomain Environments

When you examine the SIDs in your environment, you will find that in a particular domain a significant portion of the IDs is always the same. For instance, the SIDs in Figure 3.19 have S-1-5-21-606747145-436374069-1708537768 in common. This portion contains authority and subauthority identifiers and is domain-specific. Accounts from other domains would show different IDs. The remaining part of the SID, such as –500 or –1112 in these examples, is known as an RID, which is built when the user or security group is created. RIDs are variable in length and uniquely identify the security principals relative to the domain. The RID master in each Windows 2000 domain assigns each domain controller an exclusive pool of RIDs for new accounts.

Because SIDs are domain-specific, it is impossible to move user accounts between domains without changing the SID. In other words, it is impossible to move users without creating new accounts. This dependency can affect your flexibility when deploying Exchange 2000 Server in a multidomain environment. This subject is covered in more detail in Lesson 4.

Authorization

A secure system lets authorized users in and keeps unauthorized persons out. To specify who has access permissions to a particular resource, each distinct resource has a security descriptor, which contains, among other things, information about the object’s owner and a discretionary access control list (DACL). The DACL contains the access control entries (ACEs) that grant or deny a set of permissions to security principals, such as reading and writing object properties, or creating and deleting child objects. You can access an object only if its security descriptor grants the necessary access rights to one of your SIDs or a combination of multiple SIDs. For instance, if you are granted Read permissions for a particular system object (a file, a directory object, your mailbox, a public folder, and so on) and you are a member of a group, such as Enterprise Admins, that has the Full Control permission for this object, you are allowed full control.

Access to a resource is evaluated until one of the following occurs:

An ACE in the DACL denies the requested permissions. ACEs that deny permissions are listed first in the DACL and therefore override all other permissions.
One or many ACEs together grant the requested permissions.
The end of the DACL is reached with only a subset or no permissions granted.

Note

You should be very careful if you intend to deny special accounts, such as the Everyone account, the Full Control permission to a resource. Denied permissions cannot be regranted through other groups, but if server services are denied access to their resources, such as the configuration information in Active Directory, Exchange 2000 Server cannot function properly. In fact, you may severely damage the entire organization.

Auditing

Besides the DACL, security descriptors may also hold a security access control list (SACL). Similar to the DACL, the SACL contains ACEs, but these specify auditing directives, not user permissions. ACEs in SACLs reference SIDs and the type of access to be monitored. For example, you may specify that all access to the configuration of the Exchange 2000 organization should be audited for Enterprise Admins, whether or not the access was successful. In this case, when a member of the Enterprise Admins group views or changes the configuration, an event is written to the security event log on the server. However, before any security-related events are written to the security event log, you need to turn on auditing explicitly using Windows 2000 Security Tools, such as Group Policy or Domain Controller Security Policy (Figure 3.20).

In Group Policy or Domain Controller Security Policy, you will find various categories for which you can enable success and failure audits under:

 /Computer Configuration /Windows Settings  /Local Policies  /Auditing Policies (Group Policy)

 /Security Settings /Local Policies  /Auditing Policies (Domain Controller Security Policy)

Failure audits can help to reveal break-in attempts that rely on password-guessing methods (also known as brute force attacks, in which all possible password combinations are tried until a password is discovered). You can find detailed information about the Windows 2000 Security Tools in the Windows 2000 product documentation.

Note

Auditing degrades the performance of your server because a large number of events may be written to the security event log. For this reason, you should activate security auditing carefully and only in situations when you suspect critical activities in your environment. You should also monitor the security log regularly to ensure excessive events are not being recorded.

Figure 3.20 - Enabling security audits

Access Control to Directory Objects

Every object and attribute in Active Directory holds a security descriptor and users with write access to these items are generally known as administrators. For instance, if you have the Full Control permission for user objects, you can consider yourself a user account administrator. If you have Full Control permissions for the objects in the configuration NC, you are a system administrator, and if you can control the objects in the schema NC, you are a schema administrator. All three administrative roles assume important responsibilities in the Exchange 2000 organization.

Organizing the User Account Management

OUs are important elements in the logical design of Active Directory. They allow you to delegate the management of user accounts, groups, computers, domain controllers, printers, applications, and so forth to individual administrators. Different administrators may be responsible for specific groups of user accounts, and OUs can contain other OUs to support hierarchically structured account management. You can design OUs according to business functions, geographical locations, object types, or any other criteria that suit the needs of your organization (Figure 3.21). In multidomain environments, you need to define an OU hierarchy for each domain separately.

Figure 3.21 - An OU structure based on business units

The hierarchy of OUs is also an important design factor for your Exchange 2000 organization because it strongly influences the administration of mailboxes. An administrator with Full Control permission to an OU can manage all user accounts in this OU and sublevel OUs, including their Exchange attributes. The directory objects within an OU inherit the security settings from their parent containers. If you move objects between OUs, the account and mailbox administrators change automatically.

The Delegation Of Control Wizard, available in the Active Directory Users and Computers console, allows you to delegate administrative permissions most conveniently. You can choose from a list of common administrative tasks, such as Create, Delete, And Manage User Accounts, or create a custom task (Figure 3.22). The latter enables you to specify administrative privileges in great detail. Most important, you can choose to grant property-specific permissions for specific directory objects, such as user objects only. This may be a suitable option if you need to separate the user account and mailbox administration. User account administrators do not require access to Exchange-specific properties and mailbox administrators do not need to write Windows 2000 properties, but the configuration at this level is very burdensome. You have to make choices from approximately 200 properties, and separating the user account administration from mailbox management complicates the administrative infrastructure significantly. If possible, keep the administration of user accounts and mailboxes unified.

Figure 3.22 - Delegating property-specific permissions for user objects

Note

Even without explicit permissions in the Exchange 2000 organization, user administrators with Write permission to all user properties can manage delivery restrictions, delivery options, storage limits, protocol settings, custom attributes, hiding the user from the Exchange address lists, and so on. There are only a few things that these administrators cannot accomplish, such as creating, moving, or deleting mailboxes; setting mailbox rights; and creating or modifying e-mail addresses.

Permission Inheritance in the Active Directory Service

The inheritance of ACEs from parents by child objects simplifies the task of granting permissions to OUs and user accounts. Furthermore, permissions defined for parent objects in the configuration NC are also applied consistently to all of their child objects. Among other things, this gives the members of the Enterprise Admins group complete control over all resources in the forest, including the Exchange 2000 organization because this group has Full Control permissions to the top-level container objects in the domain and configuration NCs.

The situation differs for the Domain Admins group. Only the Domain Admins of the root domain are granted access rights to the root of the configuration NC. Domain Admins of other domains in the forest do not have access to the forest configuration by default. Furthermore, Domain Admins are not granted any permission to the domain NCs in other domains. Yet in the local domain, they can manage all user accounts in the existing OUs.

If you are interested in examining the security settings of the domain and configuration NCs and their child objects, use ADSI Edit (Figure 3.23). However, you should not use ADSI Edit to modify the settings. To assign permissions, always use the Delegation Of Control Wizard.

Figure 3.23 - Top-level permissions granted to the Enterprise Admins group in the configuration naming context

Note

You can block the inheritance of ACEs from parent objects by clearing the Allow Inheritable Permissions From Parent To Propagate To This Object check box, which you can find on each object’s Security property page. However, keep in mind that this requires you to apply permissions to the child objects manually, which can be a confusing and error-prone undertaking.

Documenting the Existing Administrative Infrastructure

The hierarchy of administrative control in Active Directory is an important Exchange 2000 design factor. Your project team will need to know who will become an Exchange administrator by default. You also need to determine those administrators who require explicit permission assignments to the Exchange 2000 organization. This includes mailbox administrators and domain administrators in child domains. Depending on your business requirements, you also may have to appoint further administrators or refine your domain topology and OU hierarchies.

When documenting the administrative infrastructure, include the following information:

The existing domain topology that outlines the arrangement of OUs and domains in the forest as well as relationships to foreign forests and Windows NT domains. This was discussed in Lesson 2.
The administrators who control the configuration of the corporate network, Active Directory, and user accounts.

Documenting Administrative Topologies

It is a good idea to provide a separate diagram displaying the current administrative topology to clearly describe who is responsible for which part of the environment. A sample diagram is shown in Figure 3.24.

Figure 3.24 - The administrative topology of Adventure Works

Your documentation should provide answers to the following questions:

Who are the Enterprise Admins in each Active Directory forest of your environment?
Who are the Schema Admins in your forests?
Who are the Domain Admins in each Windows 2000 domain?
What OUs exist in each domain and who are their administrators?

Tip

You can use the Domain Topology worksheet in the ACTIVE_DIRECTORY.XLS workspace to document the administrative topology of your environment.

Analyzing and Optimizing Administrative Structures

You should review the management structures in your Windows 2000 environment for two reasons: You need to determine all those administrators that will inherit permissions for the Exchange 2000 organization, and you need to check whether the current domain topology supports the administrative requirements of the future messaging environment. (See Figure B.9 in Appendix B.)

Determining Default Administrators

The relationship between Active Directory and Exchange 2000 is so close that it does not seem possible to separate the management responsibilities with reasonable effort. Basically, all your Windows 2000 administrators will become Exchange administrators, as Table 3.5 demonstrates. You should determine the future role of each administrator because each will require a different level of access to the organization. System administrators have different requirements than mailbox administrators, for instance. It may also turn out that you need additional administrators, which you have to add to the appropriate Windows 2000 security groups.

Table 3.5 Typical Windows 2000 Administrators and Their Roles in an Exchange 2000 Organization

Role in the Windows 2000 Domain	Typical Group Membership	Role in the Exchange 2000 Organization
User Account Administrator	Account Operators	Mailbox Administrator
System Administrator	Enterprise Admins	Exchange Full Administrator
System Administrator	Domain Admins (root domain)	Exchange Full Administrator
System Administrator	Domain Admins (other domains)	Mailbox Administrator
Schema Administrator	Schema Admins (plus Enterprise Admins)	The only administrator who can prepare the forest for Exchange 2000 Server

Implementing a Dedicated Resource Domain for Exchange 2000 Server

If you must split system management tasks because of organizational requirements, it would be best to place all Exchange 2000 servers in a dedicated domain, add the Exchange administrators to the local Domain Admins group, and grant this group explicit permissions for the Exchange 2000 organization. The Exchange administrators can then control the entire Exchange 2000 organization, but not the user accounts, their mailboxes, or any server accounts in other domains. Mailbox administrators from other domains, on the other hand, only need read access to the organization, and ordinary Windows 2000 administrators with no messaging responsibilities do not require any access. You can read more about the design of administrative structures and the assignment of administrative permissions to an Exchange 2000 organization in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

You can also grant an ordinary domain user the rights of an Exchange administrator, but this user would not be able to accomplish all system management tasks. Several basic activities, such as stopping and restarting services, require administrative permissions on the server. You would either have to add the user to the local Administrators group on all relevant servers or create a dedicated Exchange domain and add the user to the Domain Admins group, as suggested earlier. Implementing a dedicated domain results in a clearer architecture and is therefore preferable.

Analyzing the Administrative Structure of Adventure Works

If you take a look at the administrative design of Adventure Works (Figure 3.24), you will find that several account administrators perform the user management in this company according to the OUs in the various domains. All of them will become mailbox administrators and will require at least read access to the future Exchange 2000 organization. The members of the Enterprise Admins group, on the other hand, will automatically become full Exchange administrators. Adventure Works does not intend to separate the administration of Windows 2000 and Exchange 2000. Mailbox and Exchange administrators will receive appropriate administrator training before the rollout of Exchange 2000 Server. Table 3.6 summarizes the situation for Adventure Works.

Table 3.6 Administrators with Permissions to Manage Mailbox Settings

Windows 2000 Administrators	Domains and OUs	Exchange Role
Schema Admins: John Y. Chen	Entire forest	Can prepare the Active Directory forest for Exchange 2000 Server
Enterprise Admins: John Y. Chen, Michael Patten	Entire forest (all OUs)	Exchange Full Administrator
Andrew R. Hill	us.adventure-works.com (all OUs)	Mailbox Administrator
Doris Hartwig	us.adventure-works.com (OU: Human Resources)	Mailbox Administrator
Kirk DeGrasse	adventure-works.co.za (all OUs)	Mailbox Administrator
Stephanie Bourne	adventure-works.co.za (OU: Safari Managers)	Mailbox Administrator
Nancy Buchanan	adventure-works.com.au (all OUs)	Mailbox Administrator
John Evans	adventure-works.com.au (OUs: Tourist Managers and Travel Agents)	Mailbox Administrator

Activity: Analyzing Administrative Active Directory Structures

In this activity, you will analyze the administrative structures of Coho Vineyard & Winery and Woodgrove Bank. Both companies were introduced in Lesson 2.

TIP

The workspaces COHO.XLS and WOODGROVE.XLS, which you can find in the \Chapter03\Examples directory on the Supplemental Course Materials CD, contain detailed information for this activity.

Scenario: Coho Vineyard & Winery

Figure 3.25 shows the current Windows 2000 administration structure of Coho Vineyard & Winery. Paul West, Information Technology Administrator, is responsible for all aspects of system administration. He is the enterprise and schema administrator in the Windows 2000 domain. His colleague Don Funk, User Support Specialist, supports Dale as a domain administrator with a focus on user account administration. The company did not find it necessary to implement OUs for user account management and does not plan to split the administration of Windows 2000 and Exchange 2000 Server.

It is your task to determine the future roles of Paul West and Don Funk in the Exchange 2000 organization.

Which administrative roles will Paul West and Don Funk automatically receive in the Exchange 2000 organization?
Who will be able to prepare the Active Directory forest for Exchange 2000 Server?

Figure 3.25 - The administrative topology of Coho Vineyard & Winery

Scenario: Woodgrove Bank

Figure 3.26 shows the current administrative structures of Woodgrove Bank’s Active Directory environment. In the past, the bank had separated the management of network and messaging resources. Woodgrove Bank now hopes to lower their administrative overhead by combining these responsibilities through Active Directory and Exchange 2000 Server.

It is your task to determine the roles of the current Windows 2000 administrators in the future Exchange 2000 organization of Woodgrove Bank.

Which administrative roles will the administrators of Woodgrove Bank automatically receive in the Exchange 2000 organization?
Who will be able to prepare the Active Directory forest for Exchange 2000 Server?

Lesson Summary

Windows 2000 uses SIDs to uniquely identify all users and security groups in the Active Directory forest. The system relies on these SIDs to determine level of access to the resources, such as user accounts and configuration objects in Active Directory. Each distinct object has a security descriptor, which contains, among other things, a DACL of ACEs to specify the SIDs with granted or denied permissions.

An important feature of Windows 2000 security is the inheritance of ACEs of parent containers by child objects, which greatly simplifies the task of granting permissions to a large number of objects. This inheritance gives the members of the Enterprise Admins and Domains Admins groups Full Control permissions for the Exchange 2000 organization because the organization receives its security settings from the top-level container in the configuration NCs. You can block the propagation of permissions, but this is not advisable—it would force you to manage permissions for individual objects manually.

Figure 3.26 - The administrative topology of Woodgrove Bank

Because Windows 2000 administrators are granted management privileges in Exchange 2000, it is important to document and reevaluate the administrative models that exist in your Active Directory environment. User account administrators become responsible for mailbox management and domain administrators for the configuration of the Exchange 2000 organization. Only members of the Schema Admins group have the permission to modify the schema, which is a requirement when preparing a forest for Exchange 2000 Server. It is possible to split the network and messaging administration, but at the cost of increasing the complexity of the environment.