Authentication


Windows handles all authentication for Exchange. 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. In Windows Server 2003, a new account, LocalService, has been introduced; it allows local services to run in a service context without receiving the same high level of privilege granted to the LocalSystem account. Exchange Server 2003 services run as LocalSystem on Windows Server 2003 servers.

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 and Windows Server 2003, 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 Server 2003; if you want to group people so you can send them mail, you ll need a mail-enabled distribution group.

start sidebar
Global, Domain Local, and Universal Groups

I lied in the preceding paragraph: Windows Server 2003 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 do in Windows NT and Windows 2000. 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 the domain functional level is Windows Server 2003, 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 when the domain functional level is either Windows 2000 native or Windows Server 2003.

    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.

end sidebar
 

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 or Windows Server 2003 computer. They include the following groups:

  • The Administrators group grants full privileges 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 on the local machine.

  • 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.

  • The 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, but they don t have privileged access to any service or object except the ones they ve created.

  • 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 and Windows Server 2003 domain environments, which you ll have if you re running Exchange Server 2003. 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 Server 2003 or to upgrade an Exchange 2000 Server organization when the first Exchange 2003 server is installed into a forest, but other schema modifications must be tightly controlled.

Finally, there are four 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. The fourth principal, SELF, is what its name implies: it s shorthand for the SID of the current user or service.

What Happens When You Log On?

When you log on to a computer in a domain running Windows 2000 or Windows Server 2003, 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 can be validated against the SAM database of the local machine, against the local credential cache, or against a domain controller, depending on whether the caller is logging on with a local or domain account, whether the local or domain policy allows the use of cached credentials, and whether the domain controller is reachable . 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, which is why Exchange 2003 supports it for use between front-end/back-end combinations and between Outlook 2003 clients and Exchange 2003 servers!) 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.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net