Running Exchange Services from LocalSystem

The service account has been an integral part of Exchange Server since version 4.0. As every Exchange administrator knows, the service account provides a context for the set of Exchange services (e.g., the Information Store—IS—the Message Transfer Agent—MTA—the Directory Service—DS) to run under. The service account also provides a mutually held secret (the account name and password) for all the servers in a site to use to authenticate with one another.

However, Exchange 2000 Server takes a different approach: It uses the Windows 2000 LocalSystem account to run all its services, as Figure 1 shows. Let's look at how Exchange uses the service account, some reasons that Microsoft altered the Exchange architecture to use the LocalSystem account, and the benefits that Microsoft expects from this change.

What the Service Account Does for Exchange
Exchange uses the service account to authenticate services when you start Exchange. The account's details are in two locations—the Windows NT SAM and the Exchange Directory Store—and if those details don't match, the service won't start. A commonly encountered problem is that services won't start because you've changed the password in the SAM and failed to update the directory. Administrators have been known to delete the service account in error because they didn't realize its importance, only to learn a hard lesson when Exchange fails. The problem becomes evident the next time you try to start services after you change the password, typically at the most inconvenient time—for example, following a system reboot late at night. The problem is frustrating but easy to fix. Exchange lets you set the service account password in the Site Configuration object's Properties dialog box, as Figure 2 shows. Changing the password here changes it in both locations.

Exchange also uses the service account to authenticate Exchange servers to one another before the servers exchange data within a site. For example, every time the MTA on one server transfers messages to the MTA on another server in the site, the two MTAs authenticate each other by means of the service account password. The same process occurs when Exchange synchronizes directory information across the site.

All the servers in a site must share the same service account, and they're typically all in the same NT domain. Installing all the servers in the same domain isn't a requirement; servers can use a service account from a different domain as long as a suitable trust relationship is in place. Because you can easily break a trust, however, I don't recommend using a service account from a different domain. The simplest approach is to run the service account and all the servers in a site in the same domain.

Some Potential Problems
Just as using a service account from another domain isn't a good practice, using the default Administrator account for the service account isn't good practice either. You must use a service account only to run Exchange services and authenticate servers. You don't need to log on to a service account to perform administrative operations with an Exchange server; an account with suitable permissions can carry out these functions. Using the Administrator account as a general-purpose account for systems management is an open invitation to intruders to try to break into one of the few accounts they know exist on Win2K and NT systems.

A better practice is to create a new account with an obscure name (e.g., EXCHSRVADM01) and use it for the service account. For information about how to change the service account if you've used an account you shouldn't have, see the Microsoft article "XADM: How to Change the Service Account" (http://support.microsoft.com/support/kb/articles/q152/8/08.asp). The process of changing a service account requires careful attention to detail. The white paper "How to Change the Microsoft Exchange Server 5.5 Service Account" (http://support.microsoft.com/support/exchange/content/whitepapers/changingserviceaccount.doc) provides the background you need.

The Exchange permissions model, which is separate from the NT security model, grants Service Account Admin permission to the service account. This set of permissions lets the service account perform all the administrative and operational tasks that it needs to, such as starting the services. If you follow best practice and don't use the service account for day-to-day management, you don't need to give the same permissions as the service account to the accounts that you use for management tasks. The admin permissions are adequate to let administrators set up or modify objects in the directory without exposing user mailboxes to potential unauthorized access. Never allocate service account permissions to any account other than the service account. You don't need these permissions to administer Exchange Server 5.5.

Microsoft has published many articles about the service account—a fact that demonstrates that the service account needs care and attention. For example, the Microsoft article "XADM: What to Do If the Service Account Is Deleted" (http://support.microsoft.com/support/kb/articles/q163/6/86.asp) explains how to rebuild a service account if someone deletes it in error. Getting the news that you either have to restore a backup of the SAM (how many other accounts have been changed since the last backup?) or reinstall Exchange isn't a great way to start a day. The Microsoft article "XADM: Service Account Can Log In to Any Mailbox" (http://support.microsoft.com/support/kb/articles/q147/3/54.asp) reminds administrators that anyone can use the service account to log on to any mailbox—another good reason never to use this account interactively.

Moving to LocalSystem
Most administrators understand the potential problems with the service account and take appropriate measures to avoid those problems. Users have encountered all the common problems, and solutions exist to help rescue the unwary. So, why did Microsoft elect to make changes in this area for Exchange 2000?

Microsoft decided to move from the service account to LocalSystem for two reasons. First, Microsoft wanted to make Exchange easier to install and manage. Removing the requirement to select an account eliminated an opportunity to make a mistake. You can't trust some administrators to set up or select a service account correctly, and some administrators use accounts in such a way that compromises system security.

Second, using LocalSystem to log on to Exchange services, as Figure 3 shows, creates a more secure Exchange server. Microsoft designed the LocalSystem account for system activities and protected it against interactive access, in contrast to the service account, which anyone with the password can log on to. Remember that if you can log on to the service account, you can access anyone's mailbox on a server. If you can access mailboxes, you can read anyone's mail or even send messages by using other people's mailboxes. The use of LocalSystem has removed this interesting opportunity for administrators to access mailboxes. Administrators can still break into someone's mailbox if they really want to, but it takes more work in an Exchange 2000 environment.

Third, LocalSystem has no password to manage. Win2K automatically changes the password for the LocalSystem account every 7 days. The resulting password is more secure than the values administrators typically generate because Win2K's passwords are random.

In Exchange 2000, Active Directory (AD) supersedes the Exchange directory, so the problems of synchronizing passwords between the SAM and the DS have disappeared. Exchange engineers might have chosen to use a service account, but using LocalSystem means that you no longer need to manage accounts to successfully operate Exchange 2000. With LocalSystem, the account is part of Win2K and Win2K manages the account. Therefore, an Exchange administrator needs to know only that services run under the LocalSystem account.

The change to LocalSystem makes installation easier, too. All Exchange 2000 systems use LocalSystem, so an administrator has to think about a service account only when the servers run in mixed-mode organizations that include legacy (pre-Exchange 2000) servers. In such mixed-mode situations, the Site Replication Service (SRS) has to know about the service account before it can successfully mimic the Exchange DS on an Exchange 2000 server. SRS exchanges configuration data between Exchange 2000 servers and legacy servers.

The installation procedure for Exchange 2000 is more complex than it was for Exchange Server 4.0 (and later) because Exchange 2000 has much more code (e.g., Instant Messaging—IM) to install. However, dropping the need for a service account has removed some complexity from the equation.

In Operation
Moving to LocalSystem offers advantages for administrators. The change eliminates some known problem areas and gives administrators less to think about, but only in this specific area. Exchange 2000 is a large and complex product. Although Microsoft has simplified and improved matters with the change to LocalSystem, an administrator still has a great deal of new information and many new operational procedures to master in the brave new world of Exchange 2000.