Microsoft KB Archive/186374

= Enable Auditing of Microsoft Windows NT Server Password Registry =

Article ID: 186374

Article Last Modified on 10/31/2006

-

APPLIES TO


 * Microsoft Windows NT Server 4.0 Standard Edition
 * Microsoft Windows NT Workstation 4.0 Developer Edition
 * Microsoft Windows NT Server 4.0 Enterprise Edition

-



This article was previously published under Q186374



SUMMARY
Microsoft Windows NT Server operating system includes built-in auditing capability. This allows administrators to track which user account was used to attempt access to files or other objects in an application. Auditing can also be used to track logon attempts, shutdowns or restarts of the system, and similar events.



MORE INFORMATION
While Windows NT Server has extensive auditing and logging features, some of these are not enabled by default. The following directions will let users turn on logging for password database access.

 Ensure that auditing is enabled. To do this:

 On User Manager's Policies menu, click Audit. Click Audit These Events and then click Close.

Auditing may add performance overhead to your system; therefore, you should carefully determine what should be audited and which users and/or groups to audit. Please refer to the book "Windows NT 3.5 Guidelines for Security, Audit, and Control" for an in-depth discussion on the subject. Using the Services tool in Control Panel, start the Scheduler service and ensure that the Startup settings for Scheduler allow the service to be started as System. Open a command prompt and type the following:

at /interactive "regedt32.exe"

where, is replaced with the current time plus about a minute to take care of your command typing time. At, Registry Editor (Regedt32.exe) appears on your desktop. This execution of Regedt32.exe will be running in the system's security context. As such, it will allow you access to the entire registry, including SAM and SECURITY hives. Hence, make changes very carefully. Note that this will not work against a remote registry; you must do this locally on the system you want to modify.</li> The goal is to enable auditing on certain portions of the registry. Therefore, click the HKEY_LOCAL_MACHINE window within Registry Editor.</li> Click the SAM key and then on the Security menu, click Auditing.</li> Click Add and then click Show Users.</li> Add SYSTEM, Domain Admins, Administrator, Backup Operators, and any other groups which have the following user rights, and then click OK:

<ul> Take ownership of files or other objects</li> Back up files and directories</li> Manage auditing and security log</li> Restore files and directories</li> Add workstations to domain</li> Replace a process level token</li></ul> </li> Select the "Audit Permission on Existing Subkeys" checkbox.</li> Next, select Success and Failure checkboxes for the following entries

<ul> Query Value</li> Set Value</li> Write DAC</li> <li>Read Control</li></ul> </li> <li>Click OK and then click Yes.</li> <li>Repeat steps 7-11 for the SECURITY key. (This is not required if you just want to audit password keys, but this will allow you to track other security relevant changes to the system).</li> <li>Exit Registry Editor.</li> <li>Stop the Scheduler service. If you want the Scheduler service running, run it under a different user. If required, create a user account for this purpose and allow that account to have only service logon rights (not "Log on Locally" or "Access this Computer from the Network").</li></ol>

You will now have applied auditing to the entire SAM ensuring you will be notified through the Event Logger of any failed or successful access to your sensitive information by the only accounts which have the ability to access such information. Part of a good security policy is an appropriate audit policy, which would dictate how the event logs are reviewed, how the information is verified, and what actions should be taken for each possible event.

This will turn on auditing on the entire SAM. You can now use the Event Viewer to view failed or successful access to your sensitive information by the accounts you specified. Note that this may generate a large number of audits as the security subsystem will access these keys to do normal logons, and so on. Hence, you will need to periodically review and archive these audit trails.

However, you must remember that running untrusted programs from such powerful accounts means that these untrusted programs can devise sophisticated attacks that will use the powers of such accounts to remove traces of such accountability. Hence, the best solution still is that you do not use administrative accounts to run untrusted code and users who have access to administrative accounts are themselves trusted.

Additional query words: schedule

Keywords: kbhowto KB186374

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.