Authentication

Windows handles all authentication for Exchange 2000. Accordingly, it’s helpful to understand how Windows authentication works. The first concept you’ll have to assimilate is that of the security principal. It’s simple enough: a security principal is an entity (a user, computer, or service) that has credentials and can use those credentials to log on. Once Windows has the credentials, it can verify them to determine whether or not the user can be authenticated. Users who successfully authenticate can then go through the access control decision-making process (described in the next section) to receive access to the resources they’ve requested.

Built-In Accounts and Groups

Windows creates a number of built-in accounts and groups. First and foremost is the Administrator account. Like its counterparts, the SYSTEM and LocalSystem pseudo-accounts, the Administrator account has complete power over the local machine. Accordingly, it is a key target for attackers (along with service accounts, which often have administrative privileges but are often unmonitored). You can rename the account to something less obvious, but you cannot remove or disable it. The Guest account used to be commonly used to grant temporary resource access. However, it was so widely abused that Microsoft now disables it by default, and enabled guest accounts are one of the red flags that the Microsoft Baseline Security Analyzer (MBSA) tool looks for first. However, by default Guest has very limited privileges.

Groups are just container objects that collect accounts into an easier-to-manage aggregate. Adding an account to a group gives the account the privileges associated with the group. A common recommendation is to never grant resource access to individual accounts when you can do so by using a group instead; it’s much easier to remove Joe’s account from the Secret Project group when he leaves than to manually remove an ACE for Joe’s account from each Secret Project resource.

In Windows 2000, there are two basic types of groups. Security groups have a SID, so they can be used for granting permissions. Distribution groups don’t have a SID that can be used to assign permissions, but—like security groups—they contain a list of SIDs, one for each group member. Either type of group can be mail-enabled; for example, you can have a mail-enabled security group or a non-mail-enabled distribution group. Security groups correspond to the Windows NT 4-style groups you’re already familiar with, whereas distribution groups are closer in purpose (and use) to Exchange 5.5-style distribution lists. In fact, there’s no such thing as a distribution list in Exchange 2000; if you want to group people so you can send them mail, you’ll need a mail-enabled distribution group.

Global, Domain Local, and Universal Groups

I lied in the preceding paragraph: Windows 2000 actually supports several kinds of groups, not just security and distribution groups. For the most part, the distinctions between these other group types are of no import to Exchange, but it’s still useful to understand how these group types work and what you can, and cannot, use them for:

• Local groups work just like they did in Windows NT. They’re local to a single computer (be it a workstation or server) and cannot be used anywhere else; they’re stored in the security accounts manager (SAM) of the machine where they’re created.

• Domain local groups are created in, and can only be used in, a single domain. They are stored in the domain naming context of Active Directory, so they’ll be replicated to all domain controllers in that domain. They can contain members from anywhere in the Active Directory forest, however. To be specific, domain local groups can contain other domain local groups from the same domain, global groups from other domains, universal groups, and user accounts from any domain in the forest.

• Global groups correspond very closely to the global groups familiar to Windows NT administrators. They can contain users and groups from the same domain that they’re in. In a welcome departure from Windows NT 4, global groups can contain nested global groups (provided you’re in Windows 2000 native mode, in which there are no Windows NT–compatible domain controllers).

• Universal groups are just that: they can be used anywhere in the forest, and they can contain user accounts, universal groups, and global groups from any domain. These groups are available only in Windows 2000 native mode.

Combine these four group types with the security and distribution group types and you can see why it’s no longer enough to just say “group”—you have to specify what kind of group. Distribution or security? Global, domain local, or universal? Mail-enabled or not? Some combinations are more useful for Exchange than others; for example, mail-enabled universal security groups offer an easy way to gather up all the accounts that should have permission to do something in one place. In the rest of the book, I point out places where a particular group type is well- or ill-suited to solve a particular problem, but I’m not going to talk about the pros and cons of particular group types for replication, expansion, and so on.

Windows automatically creates two sets of groups that are of interest for security. The first are the built-in groups—these exist on every Windows 2000 computer. They include the following groups:

• Administrators group grants full privilege to all its members. Normally, its only member is the local machine’s Administrator account. However, a common goal of privilege escalation attacks is to get another account added to this group, because any account so added then becomes all-powerful.

• Authenticated Users represents all users that can log on, either interactively or remotely. You’ll often see general ACE entries like Authenticated Users:Read on Exchange objects.

• Users group contains ordinary user accounts. This group doesn’t have any special privileges; these accounts can log on, create files, and so forth within their own security context.

• Backup Operators, Server Operators, Print Operators, and Account Operators groups all have elevated privileges compared to Authenticated Users and Users. For example, Account Operators members can create and remove accounts and reset passwords, Backup Operators can read and write files that they don’t own, and Server Operators can shut down or reboot computers. None of these groups have all of the powers that the Administrators group has; in particular, they don’t have the ability to take ownership of objects. However, a clever attacker can often exploit these elevated privileges to achieve his or her dastardly ends. These groups only exist on domain controllers.

The other more interesting set of groups are the predefined groups. These exist in Windows 2000 domain environments, which you’ll have if you’re running Exchange 2000. Many of these groups are close counterparts to their local-machine equivalents; for example, Domain Admins is the domain equivalent of the Administrators group. Likewise, Domain Users contains all user accounts in the domain, and Domain Computers and Domain Controllers contain ordinary computers and domain controllers, respectively.

There are two particularly sensitive predefined groups that you should be aware of. Most dangerous is the Enterprise Admins group, whose members have full privileges on every machine in an Active Directory forest. That means that if an attacker can compromise Enterprise Admins, he or she can own your entire network—not a happy thought! The Schema Admins group is only slightly less worrisome; its members have the ability to change the Active Directory schema, which defines the physical and logical structure of Active Directory itself. It’s necessary to modify the schema to install Exchange 2000 into a forest, but other schema modifications must be tightly controlled.

Finally, there are three special security principals that are worth knowing about. First is EVERYONE, a pseudo-group that evaluates to mean any user, anonymous or not, logged in locally or over the network. In Windows NT, EVERYONE was often used as a default ACE, but the problem is that EVERYONE includes anonymous users. Because almost no one wants anonymous users to be able to gain widespread resource access on their networks, Windows 2000 and later versions use Authenticated Users in place of EVERYONE under most circumstances.

The INTERACTIVE and NETWORK principals aren’t real accounts per se; instead, they represent users who are logged on to a physical machine (either at the console or through Terminal Services) or over the network, respectively. For example, when I’m logged on to the console of my Exchange server, the INTERACTIVE principal on that machine has the same SID as my domain user account. When no one is logged on, these principals are essentially inert.

What Happens When You Log On?

When you log on to a Windows 2000 computer, the end result is that you get access to the resources whose owners have granted access to your account. This isn’t magic; there’s a well-defined process that takes place to accomplish this desirable state of affairs.

Your credentials, however they’re entered, end up in the hands of the LSA service (Lsass.exe) on the machine you’re trying to log on to. The LSA, in turn, is responsible for figuring out where to pass the credentials to get an authentication result. The credentials are validated against the SAM database of the local machine or against a domain controller, depending on whether the caller is logging on with a local or domain account. The authentication protocol used to talk to the domain controller varies, too, according to the rules described in Chapter 2, “Security Protocols and Algorithms”: Windows 2000 and later clients use Kerberos against a Windows 2000 or later domain controller, but earlier clients or domain controllers force a fallback to some variant of LAN Manager (LM) or NT LAN Manager (NTLM). For this discussion, though, we don’t really care. (As a practical matter, we care a lot: Kerberos is much more secure than NTLM or LM!) Let’s assume that, whatever combination is used, the authentication is successful.

Before we can discuss what happens next, a brief digression. Each security principal and security group has a unique SID. The SID identifies the principal and the domain that it comes from. For example, the SID for my domain account is S-1-5- 21-1253671183-4038120074-3871617788-1112. The S-1-5 portion indicates that this is a version 1 SID generated by Windows 2000; the -1112 on the end is the unique value assigned to my account. The other numbers represent unique IDs for the domain. All of the access control processes described later in this chapter evaluate the SIDs for groups and users; they never look at any other account attributes.

Once a principal successfully authenticates, the LSA returns a token. This token contains the SID of the principal’s account, along with a list of SIDs for security groups that the account belongs to. Once the token has been issued, the client can use it as shorthand to indicate who the owning user is, although access control decisions still rest with resource owners.