Microsoft Systems Management Server 2003 : Security - Accounts and Groups

You can categorize the various accounts that SMS can use in many ways. I have broken these down into four categories as follows:

• Accounts common to both advanced and standard security

• Accounts specific to advanced security

• Accounts specific to standard security

• Accounts specific to clients (advanced and standard security)

In this section we’ll review each of these account categories in more detail.

Accounts Common to Advanced and Standard Security

Three user accounts and six group accounts used at the SMS server level are common to both advanced and standard security. These are described in Tables 1 and 2.

Accounts Specific to Advanced Security

When we talk about advanced security, we usually refer to the local system account and the computer account. Strictly speaking, the local system account is sometimes used while running standard security. However, I’m including it here to emphasize its purpose under advanced security. Table 3 summarizes these two accounts.

Accounts Specific to Standard Security

Like SMS 2.0, SMS 2003 running in standard security mode uses many accounts to carry out various tasks on the server and on the client. Table 4 summarizes these accounts.

SMS Service Account

Here’s a bit more about the SMS Service account as you’re likely to encounter it if you’re upgrading from an SMS 2.0 site or need to maintain downward compatibility within your SMS hierarchy for a time. The SMS Service account is the primary account created by SMS in standard security mode. Site server services use this account to create shares and directories on site systems, set permissions, copy files, install services and components, and verify operation of the site system. Specifically, the SMS Executive, SMS Site Component Manager, SMS Site Backup, SMS SQL Monitor, and SMS Client Configuration Manager all use this account. The SMS Service account is created when the SMS site server is installed. By default, it’s named SMSService and made a member of the local Administrators group on the site server as well as the Domain Admins and Domain Users groups in the Windows domain the site server belongs to. Because the account is a domain administrator, you should probably rename it and provide password protection with a complex password composed of alphanumeric and special characters. (Just don’t forget the password.)

If your SMS site systems are members of trusted Windows domains, you can use the same SMS Service account throughout your site hierarchy for convenience. However, if SMS sites and site systems are in untrusted Windows domains, you must create the account separately in each domain. Although this won’t be a concern with Windows 2000 or higher domains, trust relationships might well be a concern if you still need to support Windows NT 4.0 domains. For example, the SMS Service account is used to access the SMS database on the server running SQL. If the server running SQL happens to be in a different, untrusted Windows domain than the SMS site server, SMS will need to use Windows’ pass-through authentication method to gain access to the server running SQL. This means that you’ll need to create the SMS Service account in the domain of the server running SQL using the same account name and password that are used on the site server.

SQL Server Account

The SQL Server account, created by SQL Server during its installation, is used to provide SMS services with access to the SMS database and the software metering database. The type of account that’s used depends on whether or not you’re using Windows Authentication mode when accessing SQL Server. 

By and large, you manage SQL Server accounts through SQL Server Enterprise Manager. If you need to change the account for SMS, first establish the account in SQL Server and then update SMS with the new account information, as shown here:

SMS Site Address Account

Here’s more information about the site address accounts. The SMS Site Address account is used to establish communications between a parent site and a child site in an SMS hierarchy for the purpose of forwarding data such as discovery data records (DDRs), site control information, inventory, and packages. Although the SMS Service account can be used to accomplish this task, it’s generally recommended that the SMS administrator create a separate account specifically for the purpose of intersite communications. This account can be made fairly secure as well because it need not be a member of the Domain Admins group. In fact, the account needs only Read, Write, Execute, and Delete permissions on the SMS_SITE share (SMS\Inboxes\Despoolr.box\Receive), so it could be simply a guest account with the appropriate permissions to the share.

Server Connection Account

SMS creates the SMS Server Connection account automatically during installation of the site server, and remote site systems use it to connect back to the site server to transfer information. The Inbox Manager Assistant component on CAPs uses this account to transfer client data to appropriate inboxes on the site server. The SMS Provider also uses this account to access SMS directories on the site server as well as the package definition file (PDF) store.

The SMS Server Connection account is named SMSServer_sitecode and is assigned a randomly generated password. Do not modify this account in any way. In fact, it’s a best practice not to modify any account created and maintained by SMS itself.

If you change the password for the SMS Server Connection account, you can reset it by running the Reset routine through SMS Setup. However, if you delete the account, calling Reset won’t restore it. Instead, you’ll need to reinstall SMS.

Accounts Specific to SMS Clients

The accounts used by SMS clients fall into three categories: those common to both the Advanced and Legacy Clients, those specific to the Advanced Client, and those specific to the Legacy Client. As you might have come to expect, the Advanced Client requires far fewer accounts than the Legacy Client does. Table 5 summarizes these accounts for you.

Client User Token Account

Here’s a bit more detail about the Client User Token account. When programs are executed at the Standard Client computer, they will run under the local user account’s security context. Since most users are logged on as users and not as administrators, these programs will run under the local user context. Although this isn’t such a big deal for non-Windows systems and for Windows 98 clients, it can be a big issue on Windows NT 4.0 and later clients because they maintain a local account database and provide more security over system modifications such as program installation. Thus, the security context poses a problem when dealing with SMS packages.

When you identify a program to SMS as requiring an administrator context to execute it, SMS uses the Client User Token account, named SMSCliToknAcct& if the client is a domain controller and SMSCliToknLocalAcct& if the client isn’t a domain controller, to create a user token on the client with sufficient access to run the program. This internal account is created automatically, assigned a random password, and granted the Act As Part Of The Operating System, Log On As A Service, and Replace A Process Level Token user rights on the client. This account will be sufficient in most cases.