Event 560 - Failure audit citing \\server\share\desktop.ini?
This one is driving me batty! I filter my file servers security log to show only FAILURE AUDITS and I get hit with 100's of event 560's reading:
Event Type: Failure Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
Date: 11/5/2009
Time: 4:29:32 PM
User: Dom\User
Computer: SERVERNAME
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: MAPPEDDRIVE:\FOLDER\FOLDER\FOLDER\desktop.ini
Handle ID: -
Operation ID: {0,389448647}
Process ID: 4
Image File Name:
Primary User Name: SERVERNAME$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: USERNAME
Client Domain: DOMAIN
Client Logon ID: (#x#,#x##C##EE#) <- "#" = that a number has been removed
Accesses: ReadAttributes
Privileges: -
Restricted Sid Count: 0
Access Mask: 0x80
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The user that the event refers to is not the owner of the file, that much I get; but why a desktop.ini file (I thought those were files that held folder display settings)? Not to mention there are 25 occurances in less then 50 sec. can anyone help me out here?
Answers
Their not accessing the parent folder, this audit is only telling you that they request ReadAttibutes to this file...and that was denied. That's how a failure audit works.
Your assuming the cart before the horse i think. I don't think the audit is lying to you, so either your assumption about your security is wrong, or the most likey answer is that since the request wasn't for the folder above, the audit didn't report on it.- Marked As Answer byJoson ZhouMSFT, ModeratorWednesday, November 11, 2009 6:44 AM
- Proposed As Answer byGunner999 Saturday, November 07, 2009 4:48 PM
All Replies
Well, here is what is happening
Its a failure to Read Attibutes of the specified Desktop.ini file. Attributes setting configurable via the attrib.exe command.
R Read-only file attribute.
A Archive file attribute.
S System file attribute.
H Hidden file attribute.
So, my first observation is this: Reading a files attibutes isn't an AUDITABLE action, and you should change your audit policy.Recommended NTFS Audit Policy
http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Recommended%20NTFS%20Audit%20Policy.aspx
If you must audit this: then to avoid the failure give the users the Allow - Read Attibbutes privledge via the Advanced button on the security tab.- Proposed As Answer byGunner999 Saturday, November 07, 2009 4:48 PM
- Gunner,
This audit policy is strictly for logging success and failure for file access by users, so how could a user be accessing a desktop.ini that is 1 level deeper then their permissions will let them go? There are no failed attempts to gain access to the parent folder. Their not accessing the parent folder, this audit is only telling you that they request ReadAttibutes to this file...and that was denied. That's how a failure audit works.
Your assuming the cart before the horse i think. I don't think the audit is lying to you, so either your assumption about your security is wrong, or the most likey answer is that since the request wasn't for the folder above, the audit didn't report on it.- Marked As Answer byJoson ZhouMSFT, ModeratorWednesday, November 11, 2009 6:44 AM
- Proposed As Answer byGunner999 Saturday, November 07, 2009 4:48 PM
