Controlling Service and Batch Job Accounts' Access to Resources

What's the best way to handle passwords for accounts for services (such as SQL Server and Exchange) and batch jobs (such as scheduled tasks) so that IT staff who leave the company can't use these accounts to access resources?

You have a couple options. Most people think of the least desirable one first: Keep a list of all such accounts and who knows their passwords and when someone leaves, change the passwords on all the appropriate accounts. This approach is onerous, and it's risky—processes or services can break if you make mistakes when changing a password, or you might fail to update the password for a service or scheduled task.

Another option is to leverage Windows logon rights in such a way as to prevent a terminated user with knowledge of a service or batch account's password from being able to use it to access any resources. No matter how an account logs on, it must have the appropriate logon right. To log on at the console of a computer, you need the Log on locally right. To access a computer from over the network, such as through a shared folder, you need the Access this computer from the network right. Scheduled tasks require the Log on as a batch job right, and services need the Log on as a service right. To access a computer via Terminal Services (aka Remote Desktop), you need the Log on through Terminal Services right. Each of these logon rights has a corresponding deny right that takes precedence if both the allow and deny rights are assigned to an account.

Human users can directly exploit only the Log on locally, Access this computer from the network, and Log on through Terminal Services rights, so the trick is to make sure service and batch accounts don't have any of these rights. The easiest way to do this is to create a group with all service and batch accounts as members and set a policy that explicitly denies these three rights. Then if someone leaves the company with knowledge of a service account's password, the individual won't be able to exploit that knowledge.

Of course, if you have any service or batch account that needs to access other computers, you won't be able to deny that account the Access this computer from the network right because that would break the process. You'll need to keep track of such situations and resort to the less desirable method of changing the account's password when someone leaves the organization or changes positions.

TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.