Building Access Lists
Windows will create an event-log entry every time a program accesses a file or registry key that is being audited, which in our case is the entire file system and the entire HKEY_LOCAL_MACHINE registry hive. Because using the Windows registry in this way could result in thousands of event-log entries, I prefer to use Microsoft's free Log Parser tool (see http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&DisplayLang=en) to extract the necessary information .
Use the following command to generate a list of files and registry keys that the application uses:
logparser "SELECT DISTINCT
EXTRACT_TOKEN(strings,1,'|')
AS Type, EXTRACT_TOKEN
(strings,2,'|') AS Name USING
EXTRACT_TOKEN(strings,7,'|')
AS Executable FROM Security
WHERE EventID=560 AND
Executable LIKE '%<Your
Application>%' ORDER BY
Type, Name" -i:evt
where YourApplication is your application or path name.
With this query, Log Parser will produce a list of all file and registry accesses. You can use this list to adjust permissions for each of the files or registry keys. For example, for shared items such as files in the Windows directory, grant the service account the necessary rights, leaving any existing permissions in place. For private files in the program's directory, remove all existing permissions, including inherited permissions, allow administrators Full Control, and give the service account you created at least Read and Execute access, although that account will often need to create or modify files, depending on the application.
Rather than using Windows Explorer to set each permission individually, use a tool such as CACLS or FILEACL (see http://www.microsoft.com/downloads/details.aspx?FamilyID=723f64ea-34f0-4e6d-9a72-004 d35de4e64&DisplayLang=en) to script each change. Doing so will save you from needing to redo this entire process if you later set up another server or must reinstall this one.
As you review the list, keep an eye out for undocumented registry settings that you might be able to use for further hardening of the product. You might, for example, notice settings to disable certain features that you aren't using, which can further reduce the application's attack surface. A program might also have an undocumented setting that determines where it stores its log files.
User Rights
Some applications require special Windows user rights to operate. A Web or FTP server, for example, might need to impersonate other user accounts as users log on. To assign user rights, open the MMC Local Security Policy snap-in (or domain policy if it's a domain account) and select User Rights Assignment under Local Policies.
At a minimum, the service account you created will need the Log on as a service right. It might also need other rights such as Generate security audits, Log on as a batch job, or Replace a process level token. Note that, by default, Windows assigns some rights to the built-in Service group, which includes any user that logs on as a service. By logging on as a service, the user account you created will automatically become a part of that group.
To make it more difficult for others to exploit your service account, you might want to specifically deny the account certain rights, such as Deny access to this computer from the network, Deny log on as a batch job, Deny log on locally, and Deny log on through Terminal Services.
The Final Run
After you configure permissions and rights, try running the application under the context of the service account you created. Stop the service and set the service properties to log on with the new user account. Start the service and wait for any errors. If the service doesn't start successfully, check the system's or application's event log for specific errors. You might need to repeat the Log Parser queries I mentioned earlier to track down the specific problem. Most applications will start fine with minor tweaking of permissions in file and registry access, unless the applications make extensive use of administrator privileges.
If you still have trouble getting the service to start, you might want to try troubleshooting the problem by using some of the tools that you see in Table 1. When you get everything working, take a few minutes to write up what changes were necessary to get the service-working. Send your list to the software publisher or post it in any relevant forums so that others might benefit.
Ultimately, some applications refuse to run with anything less than administrator privileges. If that's the case, make sure to inform the software developer of the security risks and ask the company to change its execution requirements. With enough effort and education, perhaps we can all make a difference.