Auditing object access from network

  • Thread starter Thread starter kenw
  • Start date Start date
K

kenw

I've been trying to audit object access for a few specific directories and
files. I've tried auditing read, write, and delete for Everyone, for both
success and failure.

I get nice audit log entries for local access, but when people access them
via network shares, I get no log entries at all.

Any idea what could cause this, and how I might correct it? I can't even
find any decent reference material on this topic.

/kenw
Ken Wallewein
Calgary, Alberta
(e-mail address removed)
www.kmsi.net
 
Hi Ken,

Thank you for the posting. As you indicated you are trying to audit object
access for a few specific directories and files.

Before Windows 2000 can audit access to files and folders, you must use the
Group Policy snap-in to enable the Audit Object Access setting in the Audit
policy. If you do not, you receive an error message when you set up
auditing for files and folders, and no files or folders will be audited.
After auditing is enabled in Group Policy, view the security log in Event
Viewer to review successful or failed attempts to access the audited files
and folders.

This step-by-step article provides information about how to set, view,
change, or remove auditing for a file or folder in Microsoft Windows 2000.
301640 HOW TO: Set, View, Change, or Remove Auditing for a File or Folder in
http://support.microsoft.com/?id=301640

For more information, please refer to the following knowledge base
articles.

314955 HOW TO: Audit Active Directory Objects in Windows 2000
http://support.microsoft.com/?id=314955

300549 HOW TO: Enable and Apply Security Auditing in Windows 2000
http://support.microsoft.com/?id=300549

Hope the above information and suggestion helps and answers your question.
If anything is unclear, please let me know.

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
When responding to posts, please Reply to Group via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided AS IS with no warranties, and confers no rights.
 
Hi Ken,

Thank you for the posting again. I understand your concern on the network
access.

NOTE: If your computer is connected to a network, security logging may be
restricted or disabled by a network policy.

Security auditing for workstations, member servers, and domain controllers
can be enabled remotely only by domain administrators. To do this, create
an organizational unit, add the appropriate machine accounts to the
organizational unit, and then use Active Directory Users and Computers to
create a policy to enable security auditing.

You can see the "Audit Object Access" is "Local Security Settings". If you
enable this and then try to access the shared file and folder from network,
you can find Logon/Logoff Security Event ID 538 for success.

Event ID: 538 (0x021A)
Type: Success Audit
Description: User Logoff
User Name: %1 Domain: %2
Logon ID: %3 Logon Type: %4

You can see from the User Name to see who is attempting to access the
network share.


Auditing to Detect Unauthorized Access
==================================


You can detect unauthorized access attempts in the Windows Security log,
these attempts can appear as warning or error log entries. You can also
archive these logs for later use.

To detect possible security problems by reviewing the Windows Security log:


1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Administrative Tools, and then double-click Computer
Management.

3. Expand System Tools, and then expand Event Viewer.

4. Click Security Log.

5. Inspect the logs for suspicious security events, including the following
events:

- Invalid logon attempts.

- Unsuccessful use of privileges.

- Unsuccessful attempts to access and modify .bat or .cmd files.

- Attempts to alter security privileges or the audit log.

- Attempts to shut down the server.


How to Enable Security Auditing
============================

You set up security auditing differently depending on whether the computer
is a standalone computer or a domain controller.

Standalone Servers, Member Servers, or Windows 2000 Professional

1. Click Start, click Run, type mmc /a, and then click OK.

2. On the Console menu, click "Add/Remove Snap-in", and then click Add.

3. Under "Snap-in", click Group Policy, and then click Add.

4. In the "Select Group Policy Object" box, click Local Computer, click
Finish, click Close, and then click OK.

5. In the Local Computer Policy box, click Computer Configuration, click
Windows Settings, click Security Settings, click Local Policies, and then
click Audit Policy.

6. In the details pane, click "Audit logon events".

7. Click Action, click Security, select "Unsuccessful logon attempts", and
then click OK.

Windows 2000-Based Domain Controllers

1. Click Start, point to Programs, point to Administrative Tools, and then
click "Active Directory Users and Computers"

2. In the console tree, click Domain Controllers.

3. Click Action, and then click Properties.

4. Click the Group Policy tab, click Default Domain Controllers Policy, and
then click Edit.

5. Click to expand Computer Configuration, Windows Settings, Security
Settings, Local Policies, and then Audit Policy.

6. In the details pane, click "Audit logon events".

7. On the Action menu, click Security, click to select the "Define these
policy settings" check box, click to select the "Failure" check box, and
then click OK.


For more information, please refer to this knowledge base article:

300958 HOW TO: Monitor for Unauthorized User Access in Windows 2000
http://support.microsoft.com/?id=300958

Hope the above information and suggestion helps and answers your question.
If anything is unclear, please let me know.

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
When responding to posts, please Reply to Group via your newsreader so
that others may learn and benefit from your issue.
====================================================
This posting is provided AS IS with no warranties, and confers no rights.
 
Thank you for that long, detailed posting that, again, doesn't address my
question.

PLEASE READ THIS POSTING CAREFULLY. IN THE MESSAGE BELOW, I WILL
CAPITALIZE KEY POINTS TO REDUCE CONFUSION.

This issue is on a Windows 2000 Active Directory domain controller and file
server with domain member clients accessing the target file structure via
normal network shares. It is the only such server in the domain, which
consists of the server and less than 10 workstation. All configuration was
performed while logged into the Administrator account on the domain
controller.

I want to audit file deletions in specific directories of a file server,
and I AM ABLE TO DO THAT, with limitations that are the entire point of
this thread.

THE PROBLEM, again, is that IT ONLY AUDITS DELETIONS BY LOCALLY LOGGED-IN
USERS, NOT BY USERS ACCESSING FILES VIA THE NETWORK. It almost appears
that file deletions on behalf of remote users, by system processes (e.g.,
the SMB server), are not auditable on the server where the files are
located. Is that possible?

When enabling auditing on a directory, it appears (unless I'm blind) that
one must specify a user group to audit. One cannot configure to log all
access regardless of user group. Seems screwey, but there you are.

It seems reasonable, it that case, to select the group "Everyone"; but how
can I be sure that there is not some system process that is not a member of
"Everyone"? If so, it could explain my results. And if that is the case,
what should I do? I could:
a) Set up auditing ACLs for every entity in Active Directory, to be sure I
don't miss anything?
b) Try to set up Group Policies to enable auditing of remote file access on
every client workstation? It is possible to access these file from systems
that don't implement group policies, this defeating this measure

Is it possible for some system process to delete files without being
audited at all?

NO MATTER WHO IS DELETEING THE FILES, OR HOW, I WANT TO KNOW WHO IS DOING
IT, and when.

To summarize, I CAN ALREADY AUDIT LOCAL FILE DELETIONS. I CAN'T AUDIT
NETWORK DELETIONS.

QUESTION: WHAT CAN CAUSE THAT DIFFERENCE? IS THERE ANYTHING SPECIAL ONE
MUST NORMALLY DO TO AUDIT NETWORK FILE ACCESS VERSUS LOCAL ACCESS? E.g.,
must I use a group other than "Everyone"? Is this documented anywhere?


NOTE: If your computer is connected to a network, security logging may be
restricted or disabled by a network policy.

NOTE: I clearly stated in my previous postings, more than once, that this
is a network issue. That's the whole point. What policies can disable
network access auditing and still allow local access auditing?
Security auditing for workstations, member servers, and domain controllers
can be enabled remotely only by domain administrators. To do this, create
an organizational unit, add the appropriate machine accounts to the
organizational unit, and then use Active Directory Users and Computers to
create a policy to enable security auditing.

What do you mean by "for" domain controllers? Do you mean "on" them? Are
you saying that if I want to audit access to files on a file server by a
remote networked workstation, I have to enable auditing on that remote
workstation, rather than on the file server? Where is this documented?

Please, let's dispense with the boilerplate "auditing for dummies" stuff,
OK? I've already indicated I know the basics, and have implemented them
successfully.

The problem, as I have tried unsuccessfully to make clear, is in an aspect
of the details, which no one seems to have even taken the time to notice,
let alone address. I'm getting a little frustrated here; perhaps it shows.

/kenw
Ken Wallewein
Calgary, Alberta
(e-mail address removed)
www.kmsi.net
Ken Wallewein CDP,CNE,MCSE,CCA,CCNA
K&M Systems Integration
Phone (403)274-7848
Fax (403)275-4535
(e-mail address removed)
www.kmsi.net
 
Jean-Baptiste Marchand said:
I suggest:

- replacing the EVERYONE SID by the NETWORK SID in the SACL. The SMB
server establishes a network logon session for the user accessing
remotely to a resource. Thus, the security token of the thread
accessing the file on behalf of the client contains the NETWORK SID.

- adding the SYSTEM SID, just to be verify if file deletions are
performed under the SYSTEM security context.

There should be no difference between local and remote accesses, as the
technique used by the SMB server is to impersonate the remote user and
access the local ressources as if the client were logged locally..

Ah, someone who can read!

Yes, that's what I thought, too. Good suggestions, thanks! I'll check it
out. Wonder where's there's a good reference on those SIDs...

/kenw
Ken Wallewein CDP,CNE,MCSE,CCA,CCNA
K&M Systems Integration
Phone (403)274-7848
Fax (403)275-4535
(e-mail address removed)
www.kmsi.net
 
Audit Object Access on a network share

Problems with auditing object access on shares in Windows XP within a Workgroup


1. Obligatory system setup to enable logging of events.

a) Windows Event Log service needs to be started (Administrative tools -> Services).

b) Audit policy enabled depending on what we would like to audit (Local Security Policy -> Local Policies -> Audit Policy). When No auditing is set you will not collect any logs!


PROBLEM:

System logs only Success Audits on a network share even though Access Denied has occurred and the permission (e.g. Write) is being audited on a file or folder. However, when accessing the same object using e.g. remote desktop through the Guest account, the logs contain all instances of the audited permissions if such happenings took place.

Example:

User wants to access Folder_1 shared on the network on PC_1. The folder has the share permission Read for the NETWORK group and NTFS permission Read set for the Guest account. The effect is that no other action than reading the content of the folder is permitted (in short, for more details check the articles about groups and permissions). For actions such as e.g. Delete, Write, Create access denied errors will show up. Audit object access is set on the folder to monitor successful Read access and failed Delete / Delete Subfolders and Folders. There is a subfolder within Folder_1 which we’d like to delete. We open My Network Places and see Folder_1. We open it (Success audit) and proceed to delete the subfolder, for which we get Access Denied (Failed audit). We then check the Event Viewer on PC_1 and find what -> only success audits for Read on Folder_1, no failed audit for the deletion. It will work the same with everything else except setting Deny for Read on either of these folders for Guest.

! When accessing a shared file on a network you work on the built-in Guest account !

Why there are no audits of the failed DELETE permission application?? The same is with everything else you wish to audit but Event Viewer will show only successful audits for Read no matter what you do. However, when logging on to the Guest account on PC_1 e.g. via remote desktop and trying to delete the subfolder in Folder_1 a failed audit will be recorded. WHY???

Solution:

Network shares can be audited successfully when both Read and Change shared permissions are applied. If only the Read shared permission is set on a folder the system will not log any Change-related occurrences such as Write / Delete / Create etc. only successful Read access for almost anything you want to do. Why? Because Read is the only permission the system sees on the share which can be checked, no Change permissions are set so the system is “blind” to them. It works with remote desktop as the folder is accessed not through the network per se but local file system (NTFS applies only!).

When Simple File Sharing is not on the NTFS permissions will effectively control the shared network access by giving effective set of permissions therefore there is no danger in setting Read and Change on a share if Everyone / Network / Guest have e.g. only Read NTFS set. The effective permission in this case is Read as the rule of the thumb is “Shared + NTFS = the most restrictive applies” , here Read.

This behaviour will not occur on Windows 7 but it does on Windows XP and Windows 2000 Active Directory domain controller when auditing object access on network shares.

Resources on Auditing, Sharing and permissions:

http://technet.microsoft.com/en-us/magazine/2006.01.howitworksntfs.aspx
http://www.informit.com/articles/article.aspx?p=30421&seqNum=2

Hope this case study helps someone with this puzzling problem.

Aleksander Iszczenko
MCP
 
Last edited:
Back
Top