I run a WinAt 2.30 scheduler on a Windows NT 4.0 Service Pack 5 (SP5) machine. I noticed that when I changed the logon password of the account that runs the WinAt service, the change wasn't reflected in the startup properties of the NT local Schedule service. The Service Startup failed with a Bad login event. I remedied the problem by updating my password for the Schedule service. However, I want to know where the password value is actually stored. I checked local .pwl files and the registry but found nothing. Is the WinAt account password floating somewhere unprotected outside the SAM?
WinAt is the GUI version of the At command-prompt schedule service. WinAt can run programs or batch scripts automatically on an NT machine. When you use regular user accounts to run an NT service, you must remember to change the password in the Service settings every time you change the account password. The alternative—running your service under the System account—has the key advantage that it never requires a password change. In NT, the System account has no password. You set the account in the Service dialog box, which Figure 1 shows. (To access this dialog box, right-click the Control Panel Service applet, then select Properties.)
To address your concern about the storage of the Service account's password, let's look at the difference between running a service under the System account and running a service under a user account. One of the fundamental rules of the NT security model is that any entity that accesses a domain or machine resource must authenticate itself to a security authority. This rule applies to users, machines, and services. In the case of a domain, this authority is a domain controller (DC); in the case of a standalone machine, it's the Local Security Authority (LSA). When a service starts up, it authenticates to a security authority, which is why you must link an account to a service.
Just like a user account, a service needs a way to remember its account password. A service uses the registry to store its password. For example, the Schedule service's password is stored in the HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\_SC_Schedule registry subkey. Obviously, the password isn't stored in the clear in the registry: The protected Storage service encrypts and manages it. The protected Storage service is a core NT service that cooperates tightly with the LSA. One of the LSA's tasks is securely storing machine and service passwords.
The service account-password link rule I mentioned earlier has one exception: the System account. The System account has the highest possible privileges on a local NT machine. However, although this account can access anything and do anything on the local machine, it has no permissions on any other machine. The System account's lack of other permissions is a logical consequence of its not having a password. On the one hand, without a password, it can't authenticate to another machine. On the other hand, not having to deal with password changes is an advantage. However, given the System account's unlimited power on the local machine, I recommend that you not grant a service or application privilege to run under the System account.