Planning for SMS Account Lifecycles

Because many organizations have security policies that require frequent account password changes, it is especially important to understand how to change SMS passwords without disrupting SMS functionality in your site.

Developing an effective password management strategy is critical to maintaining strong security in your site. With an effective password management strategy, you can minimize the risk of account lockouts.

Use password change techniques that minimize administrative effort and are appropriate for the account (if the account is one that can be managed by an administrator).

General Guidelines for Managing SMS Accounts

Following are general guidelines to help you manage SMS accounts.

Do not manually change accounts that are automatically maintained by SMS processes

Unless otherwise noted, do not change the passwords, account names, or permissions for accounts that SMS automatically creates and maintains. For enhanced security, SMS randomly generates and encrypts the passwords for these accounts. If you change the following accounts manually, the related processes do not run successfully, and you run the risk of causing account lockouts by forcing the accounts out of synchronization:

• The default Client Connection (SMSClient_sitecode)

• The default Server Connection (SMSServer_sitecode)

• Remote Service (SMSSvc_sitecode_xxxx)

• Client Services (Non-DC) (SMSCliSvcAcct&)

• Client Services (DC) (SMS&_domain_controller_name)

• Client User Token (Non-DC) (SMSCliToknLocalAcct&)

• Client User Token (DC) (SMSCliToknAcct&)

• CCM Boot Loader (Non-DC) (SMSCCMBootAcct&)

• CCM Boot Loader (DC) (SMS#_domain_controller_name)

To change passwords on accounts that cannot be manually changed, use the relevant SMS tool to change the password. For example, to change the Remote Service Account password, do a site reset.

In general, change passwords, instead of accounts, to maintain security

Your organization's security policy might require changing accounts or passwords on a regular basis. When working with SMS accounts, change the password of an existing SMS account that you have created instead of adding new accounts or deleting old ones, with the following exceptions:

• Client Connection Account

• Remote Service Account, if this account is shared by more than one site

• Database accounts, if these accounts are shared by more than one site

For these accounts you must create new accounts for these roles and cycle the accounts when the clients have servers that have all been configured with the new accounts.

Never modify any account properties for accounts generated and maintained by SMS. For a complete list of accounts created by SMS and accounts that you can create and maintain, see Chapter 5, "Understanding SMS Security."

If only one administrator knows an account password, seal and store it centrally

To maintain SMS security, make the passwords of the most powerful SMS accounts (or possibly all accounts) known to only one administrator. This is usually possible in smaller organizations. In such cases, the administrator can store the written passwords in a sealed envelope in a secure location, such as a company safe, that can be accessed only by authorized staff.

With this provision in place, if the SMS administrator is unavailable when important SMS changes must be made, a manager or other authorized staff member can provide the necessary passwords to a sufficiently knowledgeable SMS expert. The sealed envelope shows that no one has obtained the passwords since they were set.

It is important to remember to update the record of the passwords in the envelope whenever the passwords are changed.

Changing SMS Account Passwords

Different SMS accounts are managed in different ways. Table 12.2 lists the SMS accounts and the password change method to use for accounts whose passwords you can change.

Table 12.2 Overview of Password Change Methods for SMS Accounts

Site reset is the process of running the SMS Setup Wizard and selecting the Modify or reset the current installation option to initiate configuration changes in an SMS site. During site reset, changes specified while running the SMS Setup Wizard are written to the master site control file. SMS components and threads are removed from site servers and site systems, and then reinstalled. Accounts are also deleted and recreated. Unless noted otherwise, site reset automatically changes the passwords for the following accounts:

• SMS Client Connection (If you specify additional SMS Client Connection Accounts, SMS site reset does not automatically change the password for those accounts - site reset automatically changes the password only for the default account created by SMS.)

• SMS Server Connection (If you are using the SMSAccountSetup.ini file, see the "Account-Specific Guidelines for Managing SMS Account Passwords" section later in this chapter.)

• SMS Remote Service

You can change passwords for the following SMS accounts by using either site reset or the SMS Administrator console (with Active Directory Users and Computers administrative tool or SQL Server Enterprise Manager):

• SMS Service

• Database (SQL Server)

For ease of administration, especially in organizations with geographically widespread sites, use the SMS Administrator console to change passwords for these accounts. By using this approach, you can enable administrators to use remote SMS Administrator consoles to change account passwords. But keep in mind that for this approach to work, all SMS services must be running. If these services are not running, or if they stop before the password change cycle is completed, you must run site reset or you will not have access to the SMS Administrator console.

If your organization has geographically dispersed sites, you do not have to be physically present at each site server to perform this change. To use site reset to change SMS account passwords without traveling to the site server, do either of the following:

• Use the software distribution feature of SMS to send a setup package with an appropriate script to the site server at the remote site.

  - or -

• Use SMS Remote Tools to run the Setup.exe file from the following folder: SMS\Bin\i386\.

Specific Guidelines

Some SMS accounts must be managed in specific ways to avoid problems. Use the following guidelines to avoid account lockouts and orphaned clients in your SMS site.

Managing the SMS Service Account

Multiple sites and domains can share the SMS Service Account if you configure appropriate trust relationships and group inclusion, and if you specify the same domain name and account name for this account on the appropriate site servers. If the SMS Service Account is shared by multiple sites, or if you plan to change account passwords on secondary sites, create a second SMS Service Account before you change the first.

The same SMS processes that use the changed account information also use the SMS Service account to start up and authenticate sessions. By creating a second account and leaving both accounts active until the transition to the new account is completed, you ensure that no matter which account a process attempts to use to start up or to authenticate a session, that process can gain the access it requires.

Managing the Server Connection Account

You should not change the default Server Connection Account created by SMS unless you created the account by using the setup command-line option, or by using the SMSAccountSetup.ini file. For information about using these methods to create the Server Connection Account, see Chapter 5, "Understanding SMS Security."

If you have to run site reset, you must use the same command-line context or SMSAccountSetup.ini file to specify the same account that you specified during site setup. Otherwise, when you run site reset, SMS creates the default SMS Server Connection Account it usually creates and changes the password to a randomly generated password. As a result, remote site systems cannot access the site server because they attempt to use the SMS Server Connection Account that you manually specified during site setup.

If you delete the Server Connection Account and then run site reset to recreate it, site reset does not recreate all of the NTFS permissions for this account. For example, you lose permissions to the inboxes that client files on a CAP must be transferred to (such as DDM.box, Inventry.box, and Sinv.box). This occurs because the security identifiers associated with the permissions on those inboxes apply to the old account, not the new one. If the Server Connection Account is deleted, you must do a site reset and then run the ACLreset.exe tool available for download at www.microsoft.com/sms.

Managing the Client Connection Account

SMS client components on clients that are running Microsoft Windows NT 4.0, Microsoft Windows 2000, Microsoft Windows XP, or Windows Server(tm) 2003 use Client Connection Accounts to connect to CAPs and distribution points, to transfer data and retrieve configuration settings. For example, a client component that is updating its configuration to match the configuration settings defined at the site level uses this account to retrieve the new settings from the CAP. To prevent your clients from being orphaned, it is important to ensure that at least one valid Client Connection Account is always available to clients. Careful planning is essential if you are removing and reinstalling an SMS site server. Client computers that are running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 use the Client Connection Account to connect to the CAP. If account lockout is enabled in your site, a single client with an password that is not valid can cause the Client Connection Account to become locked out for all clients. For example, an SMS client that has been offline for a long time can cause a lockout because its Client Connection Account password might have expired. When it attempts to connect to a CAP using a Client Connection Account with an old account password, it causes that Client Connection Account to be locked out.

Because Windows account information typically propagates down the domain more quickly than SMS account information in an SMS hierarchy, when a Client Connection Account password is changed, the SMS client with the old password fails. If the SMS client software is installed on the client through Client Push Installation, it is difficult for that client to recover from the account lockout because the client receives updated account information from the CAP by using the account that just failed. However, if you have set up your logon scripts to install (or reinstall) the SMS clients during logon, the client receives the updated account and password information during the next logon (if logon scripts are used). If you have not enabled some method to install clients during logon, the only way for such a client to recover from account lockout is for you to use SMSman.exe to reinstall. You could also remove the client and then reinstall the client using Client Push Installation.

Do not remove and reinstall an SMS site server without enabling a logon client installation method. The password for the default SMS Client Connection Account (SMSClient_sitecode) is randomly generated and resynchronized with the domain account during each SMS client logon (if SMSls.bat is run). However, if you remove and reinstall an SMS site server without either enabling a logon or other client installation method, the clients are orphaned.

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.