Learning the Right Lingo

Before I dive into a discussion of Windows security features, a little vocabulary- building is in order. Perhaps more than any other part of Windows, the security subsystem is rife with acronyms and subtle, difficult-to-grasp concepts. To help get you started, here s quick tour of some of the important objects and principles you re going to meet in this chapter; they re covered in more detail later in the chapter, but this primer helps set the stage:

• Many Windows objects, including user and computer accounts and some types of groups, have security identifiers (SIDs). The SID is a unique code that can be used to identify an account for access controls. Part of the SID can be used to identify well-known objects, like the built-in Administrator account; another part of the SID is unique to the domain it was issued in, and the rest is unique to the object being identified.

• Objects that have SIDs can be used to make access control decisions. SID- carrying objects that can log on (user and computer accounts again) are known as security principals. Exchange contacts aren t security principals , however, because they have no SIDs.

  Note  

  Exchange Server 2003 adds support for inetOrgPerson objects, which derive their name from the X.500 directory standard. These objects are typically stored in a foreign directory, but can be used for addressing and message routing by Exchange; Active Directory treats them as foreign security principals, so they can be used for some types of authentication.

• When a principal attempts to log on, its credentials are authenticated by the Windows Local Security Authority (LSA) service. The LSA can authenticate a principal against the local account database, locally cached credentials, or a remote domain controller using a variety of different authentication algorithms.

• Windows is responsible for providing access control services to Exchange. To do so, the Windows Security Reference Monitor (SRM) compares a requestor s SID with the list of SIDs specified in an object s permission list. If the requestor appears on the permission list, the request can be granted. This permission list is known as a discretionary access control list (DACL). The individual permissions listed in the DACL are access control entries (ACEs).

• The DACL is contained in an object called the security descriptor (SD). Every object in a Windows system has an SD; along with the DACL, the SD indicates who owns the object and whether the SD was inherited or explicitly set. Exchange-specific objects like administrative groups and mailbox stores have a second SD, called the Admin SD, that contains Exchange-specific administrative permissions.

• Windows objects can be collected together in various types of groups. Some groups have SIDs, so that they can be used as the subject of ACEs, and some do not.

With these concepts firmly in mind, let s see how Windows provides the foundation services on which Exchange depends.