Managing Service Account Password Changes

Managing Service Account Password Changes

When accounts are assigned to a service, the Service Control Manager (SCM) requires the correct password for that account before it can make that assignment. If an incorrect password is supplied the assignment will be rejected by the SCM. Configuring services to use the Local System, Local Service, or Network Service accounts negates the need to manage account passwords because the operating system manages them instead.

For other service accounts, the SCM stores account passwords in the services database. After passwords are assigned, the SCM does not verify the passwords stored in that database and the password assigned to a user account in Active Directory will continue to match. This can cause problems when situations such as the following occur:

1. A service is configured to use a specific user account.

2. The service starts by using that account with the current password.

3. The password for that user account is changed while the service continues to run.

4. The service continues to run until it is stopped. After it is stopped, the service cannot restart because the SCM is still trying to use the old password. Password changes in Active Directory do not synchronize with passwords stored in the services database.

Any service that uses a standard domain or local user account must be updated with new authentication information every time that user account password is changed. This can take a significant amount of time and effort if services and the accounts they use are not properly documented.

Of course, the existence of a document that stored account information for all services used on all servers presents its own unique security risk—so steps should be taken to secure such a document. Larger organizations can record this information in an encrypted file, which is taken offline and stored in a secure location. Smaller organizations may simply record such information on paper in a binder that is locked in a safe or other secured location.

Some applications may also use service account passwords, such as Exchange Server or SQL Server™, so care should be taken to change relevant passwords at the application interface in such situations.

For information about how to write tools to automate the process of changing service account passwords, see the article "Changing the Password on a Service’s User Account" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/changing_the_password_on_a_serviceampaposs_user_account.asp.

Enforcing the Use of Strong Passwords

As mentioned in the corresponding section for administrator accounts, the use of strong password policies should be strictly enforced on all administrator equivalent accounts as well as all service accounts. To enforce such rules, Group Policy can be used to enforce password expiration dates, minimum length restrictions, and other strong password rules.

For more information about strong password policies, see the "Account Passwords and Policies" white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx

For more information about how to enforce the use of strong passwords, see the Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?linkid=14845.

Weak passwords represent one of the most common vulnerabilities on a network, and when used with administrator equivalent accounts they are one of the easiest ways an attacker can gain access to network resources. The use of automated testing tools to detect administrator equivalent accounts that use weak passwords should be a regularly scheduled task for those responsible for the security or administration of a network.

To accomplish this task, the Microsoft Baseline Security Analyzer (MBSA) tool can scan every computer on the network in search of weak passwords. The MBSA can enumerate all user accounts and check for the following password-related vulnerabilities:

• Blank passwords.

• Passwords that match user account names.

• Passwords that match computer names.

• Passwords that use the word “password,” “admin,” or “administrator.”

When used, the MBSA will attempt to use each of the listed vulnerabilities to change an account’s password. When a weak password is discovered the password will not be changed, but the MBSA will report that password as being a security risk. The MBSA will also report any disabled accounts or accounts that are locked out.

Although the MBSA does detect the most common poor password practices, it does not provide full-featured password auditing capabilities. For these needs there are some third-party offline scanning tools and applications available on the market.

For more information about the MBSA or to download this tool, see the Microsoft Baseline Security Analyzer Web page at www.microsoft.com/technet/security/tools/mbsahome.mspx.

Note The MBSA will reset any account lockout policies detected on a computer to prevent locking any accounts during the scanning process. Also, the MBSA will not perform password scans on computers designated as domain controllers.

 

Source: Securing Critical and Service Accounts