Most services have default SACLS: Everyone:Fail:All Accesses
Service Control Manager itself has a SACL.
The SACLs on SAM objects were changed in Windows Server 2003 to be less verbose.
Also, I'm working with the SAM team to see if I can deliver a tool which will adjust SACLs on the SAM.
Finally, the reason that the objects with SACLs, have SACLs, is to mitigate some threat. For instance, we noticed that no audit event was generated when a scheduled task was added, so we added instrumentation to the Scheduler service. However due to the way that jobs are created, it's possible to add job objects directly to the scheduled tasks folder, so for complete coverage we had to audit that as well.
I complained to the event viewer team about the full control access to the security key when the log is viewed or refreshed (we audit this so that we can detect tampering with the security log), however they denied that the issue existed and, after a demonstration, did not feel that it met the bar for inclusion in W2K3 (I noticed it pretty late in the product cycle). Event Viewer is getting a rewrite in Longhorn so I doubt we'll see this issue fixed in a service pack, but this event isn't very noisy so I don't think it's too onerous.
Eric
-----Original Message-----
From: loganalysis-bounces (at) lists.shmoo (dot) com [email concealed] [mailto:loganalysis-bounces (at) lists.shmoo (dot) com [email concealed]] On Behalf Of Jean-Baptiste Marchand
Sent: Monday, June 30, 2003 3:38 AM
To: loganalysis (at) lists.shmoo (dot) com [email concealed]
Subject: [logs] Re: [Windows] Privileges field in 560 events
[ Some more information, for those interested... ]
> One first thing important to know is that, once the _Audit object
> access_ category is enabled, you'll see some 560 events in the Windows
> security eventlog, even if you haven't enabled auditing on any of your
> own objects.
>
> This is because some internals objects, more precisely the LSA Policy
> objects and objects in the SAM hierarchy have, by default, a SACL.
>
> You can examine and modify the SACL on these objects using the lsaacl
> and samacl tools:
>
> http://razor.bindview.com/tools/desc/acltools1.0-readme.html
Default SACL on SAM objects are documented in MSKB #149401:
http://support.microsoft.com/?kbid=149401
However, this article only mentions Windows NT 4.0, whereas it probably also applies to Windows 2000 and Windows Server 2003.
By the way, on Windows Server 2003, there are also default SACL on the following objects:
- The C:\WINDOWS\tasks\ directory
(you can examine the content of the SACL using subinacl, part of
Windows Server 2003 Resource Kit Tools).
As a consequence, when a scheduled task is added, a 560 event is logged in the Security eventlog:
- The Security\ registry key, under the Eventlog service configuration
key, has also a default SACL (you can examine the content of the SACL
on this key using regedit):
This can be annoying, because each time the administrator refreshes the view on the Security eventlog, two events (560 and 562) are logged in the Security eventlog. To avoid this, the SACL can be modified using regedit.
Most services have default SACLS: Everyone:Fail:All Accesses
Service Control Manager itself has a SACL.
The SACLs on SAM objects were changed in Windows Server 2003 to be less verbose.
Also, I'm working with the SAM team to see if I can deliver a tool which will adjust SACLs on the SAM.
Finally, the reason that the objects with SACLs, have SACLs, is to mitigate some threat. For instance, we noticed that no audit event was generated when a scheduled task was added, so we added instrumentation to the Scheduler service. However due to the way that jobs are created, it's possible to add job objects directly to the scheduled tasks folder, so for complete coverage we had to audit that as well.
I complained to the event viewer team about the full control access to the security key when the log is viewed or refreshed (we audit this so that we can detect tampering with the security log), however they denied that the issue existed and, after a demonstration, did not feel that it met the bar for inclusion in W2K3 (I noticed it pretty late in the product cycle). Event Viewer is getting a rewrite in Longhorn so I doubt we'll see this issue fixed in a service pack, but this event isn't very noisy so I don't think it's too onerous.
Eric
-----Original Message-----
From: loganalysis-bounces (at) lists.shmoo (dot) com [email concealed] [mailto:loganalysis-bounces (at) lists.shmoo (dot) com [email concealed]] On Behalf Of Jean-Baptiste Marchand
Sent: Monday, June 30, 2003 3:38 AM
To: loganalysis (at) lists.shmoo (dot) com [email concealed]
Subject: [logs] Re: [Windows] Privileges field in 560 events
[ Some more information, for those interested... ]
* Jean-Baptiste Marchand <Jean-Baptiste.Marchand (at) hsc (dot) fr [email concealed]> [26/06/03 - 17:48]:
[...]
> One first thing important to know is that, once the _Audit object
> access_ category is enabled, you'll see some 560 events in the Windows
> security eventlog, even if you haven't enabled auditing on any of your
> own objects.
>
> This is because some internals objects, more precisely the LSA Policy
> objects and objects in the SAM hierarchy have, by default, a SACL.
>
> You can examine and modify the SACL on these objects using the lsaacl
> and samacl tools:
>
> http://razor.bindview.com/tools/desc/acltools1.0-readme.html
Default SACL on SAM objects are documented in MSKB #149401:
http://support.microsoft.com/?kbid=149401
However, this article only mentions Windows NT 4.0, whereas it probably also applies to Windows 2000 and Windows Server 2003.
By the way, on Windows Server 2003, there are also default SACL on the following objects:
- The C:\WINDOWS\tasks\ directory
(you can examine the content of the SACL using subinacl, part of
Windows Server 2003 Resource Kit Tools).
As a consequence, when a scheduled task is added, a 560 event is logged in the Security eventlog:
-----------------------------------------------------------------------
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
Date: xx/xx/2003
Time: xx:xx:xx
User: NT AUTHORITY\SYSTEM
Computer: BLAH
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: C:\WINDOWS\Tasks\At1.job
Handle ID: 3464
Operation ID: {0,171812}
Process ID: 936
Image File Name: C:\WINDOWS\system32\svchost.exe
Primary User Name: BLAH$
Primary Domain: MYDOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: -
Client Domain: -
Client Logon ID: -
Accesses: READ_CONTROL
SYNCHRONIZE
WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)
WriteEA
ReadAttributes
WriteAttributes
Privileges: -
Restricted Sid Count: 0
Access Mask: 0x120196
-----------------------------------------------------------------------
- The Security\ registry key, under the Eventlog service configuration
key, has also a default SACL (you can examine the content of the SACL
on this key using regedit):
-----------------------------------------------------------------------
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
Date: xx/xx/2003
Time: xx:xx:xx
User: BLAH\Administrator
Computer: BLAH
Description:
Object Open:
Object Server: Security
Object Type: Key
Object Name: \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\Eventlog\Security
Handle ID: 496
Operation ID: {0,141880}
Process ID: 1816
Image File Name: C:\WINDOWS\system32\mmc.exe
Primary User Name: Administrator
Primary Domain: BLAH
Primary Logon ID: (0x0,0x124B8)
Client User Name: -
Client Domain: -
Client Logon ID: -
Accesses: Set key value
Privileges: -
Restricted Sid Count: 0
Access Mask: 0x2
-----------------------------------------------------------------------
This can be annoying, because each time the administrator refreshes the view on the Security eventlog, two events (560 and 562) are logged in the Security eventlog. To avoid this, the SACL can be modified using regedit.
Jean-Baptiste Marchand
--
Jean-Baptiste.Marchand (at) hsc (dot) fr [email concealed]
Hervé Schauer Consultants
http://www.hsc.fr/
_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) lists.shmoo (dot) com [email concealed]
http://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) lists.shmoo (dot) com [email concealed]
http://lists.shmoo.com/mailman/listinfo/loganalysis
[ reply ]