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.
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:
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.
- On User Manager's Policies menu, click Audit.
- Click Audit These Events and then click Close.
- 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 <time> /interactive "regedt32.exe"
where, <time> is replaced with the current time plus about a minute to
take care of your command typing time.
- At <time>, 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.
- The goal is to enable auditing on certain portions of the registry.
Therefore, click the HKEY_LOCAL_MACHINE window within Registry Editor.
- Click the SAM key and then on the Security menu, click Auditing.
- Click Add and then click Show Users.
- Add SYSTEM, Domain Admins, Administrator, Backup Operators, and any
other groups which have the following user rights, and then click OK:
- Take ownership of files or other objects
- Back up files and directories
- Manage auditing and security log
- Restore files and directories
- Add workstations to domain
- Replace a process level token
- Select the "Audit Permission on Existing Subkeys" checkbox.
- Next, select Success and Failure checkboxes for the following entries
- Query Value
- Set Value
- Write DAC
- Read Control
- Click OK and then click Yes.
- 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).
- Exit Registry Editor.
- 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").
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
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.
Article ID: 186374 - Last Review: October 26, 2013 - Revision: 2.0
- Microsoft Windows NT Server 4.0 Standard Edition
- Microsoft Windows NT Workstation 4.0 Developer Edition
- Microsoft Windows NT Server 4.0 Enterprise Edition
|kbnosurvey kbarchive kbhowto KB186374|