"Permission denied" error while calling WSH's LogEvent method

[Yitzhak]

I am having "Permission denied" error while calling
LogEvent method of WScript.Shell component.
Basically, ASP page calls Windows Script Host Shell
component to log events to the OS Application Event log.

My environment:
Windows Server 2003, IIS 6, WSH, Classic ASP, Vbscript

Below is the code and the error:
Code:
**********************************
call LogEvent(0, "some text")

Function LogEvent(intEventType, strEventMessage)
Set objWshShell = Server.CreateObject("WScript.Shell")
call objWshShell.LogEvent(intEventType, strEventMessage)
Set objWshShell = Nothing
End Function
**********************************


Error:
**********************************
Microsoft VBScript runtime error '800a0046'
Permission denied
**********************************

I made the change below based on 301309 KB article to no
avail.

"...Set the following Registry key to 0 instead of 1, and
then restart your computer for the changes to take effect.
HKLM\System\CurrentControlSet\Services\EventLog\Application
Name: RestrictGuestAccess
Type: REG_DWORD"

I guess Windows Server 2003 configuration is a reason for
the error. Everything worked fine on Win2K server with IIS
5.0

 

[Foo Man Chew]

Use regedt32, navigate to the same place, right-click the EventLog node,
select Permissions... and make sure IUSR_(your_machine_name) has explicit
access.

 

[Jonathan B.]

After a call into Microsoft's PSS, this issue was identified as a bug
and a KB article should be out soon to address this. (After it goes
through the KB group, this will be said to be a feature I'm sure.)

While I was able to write to the event log when logged in as the IUSR
acct via a VBS script, I was not able to write to the event log via
ASP using virtually the same exact script. So, if MS later claims
that this is not a bug, that would be bogus IMO. Anyway, I did as
suggested in this article and it worked. I suggest to Microsoft to
make these security setting available in the Event Viewer in their
next service pack.

The work-around was actually published in an article by Michael Howard
last June:

"Development Impacts of Security Changes in Windows Server 2003"
http://msdn.microsoft.com/library/en-us/dncode/html/secure06122003.asp


Here is the section of interest in that article:

-------------------------------------------------------------
Tighter ACLs on Event Logs

We also tightened up the ACLs on the event logs to restrict what
accounts can read and write to the logs. Better still, the security of
each log is configured locally through the values in the following
registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog

For example, the Application log Security Descriptor is configured
through the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

And the System log Security Descriptor is configured through the
following:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD

The Security Descriptor for each log is specified by using Security
Descriptor Definition Language (SDDL) syntax. The following is an
example from the Application event log:

O:BAG:SYDD;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)
(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)

This string means:

Entry Meaning
O:BA Object owner is Built-in Admin (BA).
G:SY Primary group is System (SY).
D: This is a DACL, rather than an audit entry or SACL.
(D;;0xf0007;;;AN) Deny Anonymous (AN) all access.
(D;;0xf0007;;;BG) Deny Built-in Guests (BG) all access.
(A;;0xf0005;;;SY) Allow System Read and Clear, including DELETE,
READ_CONTROL, WRITE_DAC, and WRITE_OWNER (indicated by the 0xf0000).
(A;;0x7;;;BA) Allow Built-in Admin READ, WRITE and CLEAR.
(A;;0x7;;;SO) Allow Server Operators READ, WRITE and CLEAR.
(A;;0x3;;;IU) Allow Interactive Users READ and WRITE.
(A;;0x3;;;SU) Allow Service accounts READ and WRITE.
(A;;0x3;;;S-1-5-3) Allow Batch accounts (S-1-5-3) READ and WRITE.

The specific event log access mask bits are:

0x0001 ELF_LOGFILE_READ Permission to read log files.
0x0002 ELF_LOGFILE_WRITE Permission to write log files.
0x0004 ELF_LOGFILE_CLEAR Permission to clear log files.

The only time you should see a failure in your application when
writing to the event log is because of an ACL issue. Please do not
relax the ACL too much. Add your own ACE to the SDDL string and then
restart the Event Log service. For example, if your process runs under
an account MyAccount, that has the SID
S-1-5-21-853885456-2109860151-3743179773-1190, and you want the
process to write to the Application log, simply add this string to the
SDDL string in the registry:

(A;;0x2;;; S-1-5-21-853885456-2109860151-3743179773-1190)
-------------------------------------------------------------


NOTE: You will need to get the SID of the IUSR account to apply this
work-around ... I used this script which I scraped from another usenet
posting:



[GetUserSID.vbs]
-------------------------------------------------------------
Dim ArgObj, strComputer, Account

Set ArgObj = WScript.Arguments

If ArgObj.Count < 1 or ArgObj.Count >2 Then
DisplayHelpMessage
WScript.Quit (GENERAL_FAILURE)
End If

Select Case ArgObj.Count
Case 1
strComputer = "."
Account = argObj(0)
Case 2
strComputer = argObj(0)
Account = argObj(1)
End Select


On Error Resume Next

Dim objWMIService, colItems, objItem
Set objWMIService = GetObject("winmgmts:\\" & strComputer &
"\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Account
where Name = '" & Account & "'" )
For Each objItem in colItems
Wscript.Echo
Wscript.Echo " Account: " & objItem.Caption
Wscript.Echo " SID: " & objItem.SID
Wscript.Echo "Description: " & objItem.Description
Wscript.Echo
Next

' ----------------------------------------

Sub DisplayHelpMessage()
WScript.Echo "INVALID ARGUMENTS" & vbCrLf
WScript.Echo "Purpose: to obtain SID from the account name"
WScript.Echo " Usage: " & UCase(WScript.ScriptName) & "
[computer_name] account_name" & vbCrLf
End Sub