When running a scheduled task, especially for things like scripts or back-ups or monitoring services, etc. you should ALWAYS try to make it work using the local SYSTEM account rather than a domain user "service" account. Why?
- No having to deal with passwords.
- Much more narrowly defined security model
- Local administrative rights
- Simple as dirt
What exactly am I talking about?
A domain user "service" account is simply a user account created in Active Directory, which is almost always granted special domain group and security rights, and is used to run scheduled tasks unattended. The problem is that such accounts are managed in the "open" and require a *known* password. Known by someone. Anyone. This introduces two problems:
- The person that knows the password has to record it securely and ensure there is a failsafe backup (someone else has access to the password in case person "A" is hit by a bus).
- The password may require being reset on a periodic interval (group policy or even worse: SOX)
By using the built-in, local "SYSTEM" account, you circumvent a lot of these issues, and make the security model much simpler to manage. For example:
- The password is managed by the computer itself (and AD). No human involvement here.
- The password resets are handled automatically.
To make this change, you need to understand that computers have account in Active Directory just like Users do. The only functional difference is that the name has a $ suffix appended and computers are only members of one domain group by default: Domain Computers. This group, by default, is not a member of any other groups. Not even "users" or "domain users". It's a group on a shelf, waiting to be used if needed.
So if you run a task on computer "A" that needs to read from, or write to, a shared folder on computer "B", you simply grant either (A) the specific computer account "A$" or the domain group "Domain Computers", the appropriate rights to the shared folder. That's it. Done. This model works extremely well in most cases. I've used it for back-ups, monitoring, scripting, reporting, scanning, and lot's of things.
Is this "new"? Not at all. Microsoft uses this model for SMS 2003 "Advanced Security" as does System Center Configuration Manager 2007 and System Center Operations Manager 2007. Many other products, Microsoft and others, use this security model as well.
So why haven't IT administrators and software developers climbed on board with this? I have no freaking idea. It's so much simpler and cleaner and less hassle. Maybe this will catch on, but so far I'm not seeing it spread like wildfire.