Auditing on windows nt server

  • kccobra
  • Novice
  • Novice
  • kccobra
  • Posts: 25

Post 3+ Months Ago

How do I set up auditing for a directory on windows nt. I also know this log will get big and would like to put it on a different disk. How do i do that?

The problem I am having is files are being deleted and I have no record who did it.

If you have a better option do tell. Thanks for you time.

  • hackeralert
  • Beginner
  • Beginner
  • User avatar
  • Posts: 60
  • Loc: India

Post 3+ Months Ago

you want to set up an auditing process for a domain called ims. Before you consider what audits to apply to AD objects and containers, you need to know the default auditing entries for the domain.

shows AD's default auditing settings. In Screen 1, the system is auditing all successful and failed events (All) of varying accesses (Special) in the ims domain (this object only) for AD's built-in group (Everyone). The default access control setting of Special means that the system audits multiple events. To see those events, you can either double-click the auditing entry line or highlight the line and click View/Edit. In the dialog box that appears, you'll see two tabs: Object and Properties Screen2


shows the default Object tab
shows the default Properties tab. Both screens display the audited events that apply to only the root of the ims DIT for the Everyone group.

As Screen 3 shows, AD audits only property writes for the ims domain object by default. This default makes sense when you consider that Microsoft designed AD for more reads than writes. Users log on to a DIT or query published resources much more often than they change their password or change the name of a printer. Consequently, if the system default were full auditing instead of write access, the log containing the auditing entries would fill up quickly and individual entries would be hard to find.

For the same reasons, the List contents, List object, Read all properties, and Read permissions check boxes in Screen 2 are empty. The system enables only the auditing of write, delete, and modify events of ims objects by default.

You might have noticed that Screen 3 has a Read all properties check box, but not a corresponding Write all properties check box. NT 5.0 beta 1 had a Write all properties check box in the Properties tab. But in NT 5.0 post-beta 1, the developers moved this option to the Object tab (as Screen 2 shows) and added a duplicate Read all properties check box. This modification is a good reminder that NT 5.0 is still prerelease software and therefore can change.

Creating Auditing Entries
To show you how to create auditing entries, I used object examples from "Managing Permissions for NT 5.0's Active Directory" and created a DIT for the ims domain. This DIT has an organizational unit (OU) container, TestOU1, which contains a user, TestUser1. Elsewhere in the DIT, the default Users container houses a domain group, DataEntryGroup. TestUser1 is a member of DataEntryGroup.

Suppose you decide that the system's default of auditing every write and every modification is too intensive. Instead, you want to set up a simple audit policy to monitor DataEntryGroup. Specifically, you want an alert to go off when group members try to modify an object's permissions or owner but fail because of insufficient access permissions. You want to apply these events to the entire domain. In other words, you want to monitor these two events for every object. To disable the default setting and create an entry, follow these nine steps.

Open Directory Management.
Right-click ims domain in the scope pane, and select Properties.
Select the Security tab.
Click Advanced, and select the Auditing tab in the Access Control Settings dialog box that appears.
Highlight the default entry, and click Remove.
Click Add, and select DataEntryGroup from the Add Users and Groups dialog box.
Click Add, OK to close the dialog box. This step opens an audit entry dialog box for the ims domain similar to the ones in Screen 2 and Screen 3, except this window doesn't have separate Object and Properties tabs.
Select Modify permissions and Modify owner in the Failed column.
Click OK to return to the Access Control Settings dialog box, and click either Apply or OK to set the changes.
If you are manually setting up an auditing entry for the first time on a server, a dialog box opens with the message: The current Audit Policy for this computer does not have auditing turned on.

Checking the Auditing Log
After you have set up the auditing policy for the domain, you need to check the auditing log. In MMC, open Computer Management and expand System Tools in the scope pane to display the Event Viewer. Expanding the Event Viewer gives you five logs to choose from; you need the Security Log. Clicking Security Log displays the audited events in the display pane, as Screen 4 shows

Suppose that when you check the Security Log, you find that DataEntryGroup members occasionally don't modify the owner of a certain object, TestOU1, in the DIT. To find out what is occurring, you can set up an audit on that container only. To set up this audit, go through the nine steps for creating an auditing entry, except substitute the TestOU1 object for the ims domain and choose to audit all successful and failed write, delete, and modify events for TestOU1 and for any objects below TestOU1 in the DIT. This audit will let you see all aspects of TestOU1 that the DataEntryGroup members are attempting to change.

Suppose that this audit reveals one particular user, TestUser1, as the culprit. Having checked TestUser1's permissions, you find nothing unusual, so you decide you need to audit TestUser1's events. To set up this audit, follow the same nine steps you took to set up the container audit, except substitute TestUser1 for DataEntryGroup and select all the check boxes in the Successful and Failed columns.

This new audit places a complete audit trail on TestUser1, letting you maintain a vigil on what that account owner is doing. Whether TestUser1's actions are unintentional (e.g., in an application, clicking a key that happens to have a rogue function call that attempts to make changes) or intentional (e.g., using System Tools to try to deliberately change an object's permissions), you can identify and solve the security problem immediately.

You might be wondering why you didn't audit all events from the outset to identify the problem. Immediately conducting a full audit might not be a good idea. (I stressed might not because it might be appropriate in certain situations.)

For companies with many users, auditing every event for every object will generate thousands of entries in a matter of minutes. Because the system must record every entry in the auditing log, auditing imposes a load on the system. Even a powerful server will likely suffer from a notable decrease in performance. In addition, you're productivity will likely suffer as you search through all those entries looking for clues

How to Enable Auditing with the Security Configuration Editor

Security Configuration Editor (SCE) in Windows NT 5.0 performs three basic functions. First, SCE lets you create security templates. Second, SCE lets you apply a template's security settings to machines. Finally, SCE performs security checks on machines by comparing a machine's existing settings with those in the template, detailing those areas in which the settings differ.

To enable auditing, you need to create a new security policy template, apply it to the machine, and reboot. Here's how to accomplish these tasks with NT 5.0 post-beta 1 (i.e., the 1773 build).

In the Microsoft Management Console (MMC), open Computer Management and expand System Tools in the scope pane to display SCE.
In the scope pane, expand these items in succession: SCE, Configuration/Inspection Templates, and X:\WINNT\Security\Templates, where X is the path drive letter of the drive on which you installed NT 5.0. Two existing SCE policy templates will appear: sample and sampledc.
Right-click sample, and select Save As. In the File name text box, give the new template a name, such as audit-on. The system will append an .inf extension to the file.
Right-click X:\WINNT\Security\Templates, and select Refresh. The scope pane will display the new template.
In the scope pane, expand these items in succession: audit-on (or whatever you named the new template), Local Policies, and Audit Policy. The audit attributes will be visible in the display pane.
Double-click Audit Object Access in the display pane to open a dialog box to modify the existing settings.
Select Audit successful attempts and Audit failed attempts. Click OK. The resulting screen will look similar to Screen 1.
Right-click the new template name in the scope pane, and click Save.
Right-click the new template name in the scope pane, and select Configure. Click OK in the dialog box that pops up.
Reboot the server.
After you have created this new security template, you can modify it to meet your needs. You can then use the Configure command to apply it to the system
  • DuckIT
  • Graduate
  • Graduate
  • User avatar
  • Posts: 155
  • Loc: London, UK

Post 3+ Months Ago

wow that is some sweet help you provided there hackeralert! Except he said NT and you gave support on Windows 2000 (NT of course did not have an AD) :lol: Maybe he meant Windows 2000 though? Does anyone still actually use NT?? :shock:

You can also try this program (not sure if it supports NT):

It turns the auditing into something readable. Not tried it myself but I hear its good! (free too for the most part)

  • kccobra
  • Novice
  • Novice
  • kccobra
  • Posts: 25

Post 3+ Months Ago

Yes you are correct, I need it for NT not 2000. Thanks though, that was a great explanation.


Post Information

  • Total Posts in this topic: 4 posts
  • Users browsing this forum: No registered users and 35 guests
  • You cannot post new topics in this forum
  • You cannot reply to topics in this forum
  • You cannot edit your posts in this forum
  • You cannot delete your posts in this forum
  • You cannot post attachments in this forum

© 1998-2017. Ozzu® is a registered trademark of Unmelted, LLC.