Permission Denied error when accessing a COM object. 1

[rlawrence]

Hi,

I have deployed several web sites using a COM+ application for the back end on a Windows 2003 server. I have a protected ADMIN folder for administrative functions. My web host has set up administrative accounts to get to these administrative functions. The admin accounts for ONE web site are generating a permission denied error when requesting the admin page.

I know that this seems like an obvious permissions setting for this account, but the web host managers swear tha they have checked and rechecked the permission settings for both the web and the account. They have even deleted the web and the account and re-entered them both. We still get the same error.

The error is as follows:

Active Server Pages error '00000000'
Create object failed
?
An error occurred while creating object 'webMgr'.
Microsoft VBScript runtime error '800a0046'
Permission denied: 'webMgr'
/LM/W3SVC/1071261871/Root/global.asa, line 12

Here's the entire global.asa file:

<object RunAt=Server Scope=Session ID=webMgr ProgID="paweb.WebManager">
    REM This is the Publishers' Assistant Web Services Manager
</object>


<script Language=VBScript RunAt=Server>

    SUB Session_OnStart

    ' Tell the web manager where to find the INI file.
    Session("cHomeFolder") = Request.ServerVariables("APPL_PHYSICAL_PATH")
    IF webMgr.InitSession(Session("cHomeFolder")) then
	Session("cOwnerEmail") = webMgr.GetSessionProperty("rsOwner.oRecord.Email")
    ELSE
	Session("cOwnerEmail") = "Session was not available."
    END IF
    End Sub


    SUB Session_OnEnd

    ' Release any resources that remain within the session.
    ' Release the components from the web manager before releasing the
    ' web manager.
    webMgr.Release()
    Set webMgr = Nothing

    End Sub

</script>

As you can see from the error, the failure is coming--not when webMgr is created, but when there is a reference to the InitSession method.

This application is set up as a COM+ application and actively used on other webs. My personal account will access this page just fine. Thee are two user accounts set up for this and both generate the above error.

By the way, the anonymous user can access the web with no problem. That executes the same global.asa to create the webMgr object.

These user accounts have been given full access to the entire web. They use the same account to ftp changes to the web without a problem.

We're running out of places to look for permission settings. Any new thoughts would be greatly appreciated. This is only one of several mysteries surrounding the global.asa file and these protected administrative functions, but right now I'm focussed on this one behavior.

Thanks in advance,
Ron

 

[Sheco]

Perhaps the problem is not paweb but rather something used by paweb...

 

[rlawrence]

Hi Sheco,

Thanks for responding.

Perhaps the problem is not paweb but rather something used by paweb...

Well, if that were true, wouldn't it be a problem for other web sites depending on the same component?

Ron

 

[jeepxo]

Just a shot in the dark, but doe IUSER_<%machinename%> or IWAM_<%machinename%> have modify rights on the paweb files?

Remember that your web app uses either IUSER or IWAM (depending on Windows version) for file level access.
If the file is in Inetpub, the permissions are set for you already.
If you installed PAWeb, and by default it places it in C:\program files\blahblahblahblah, the "anonomous user" doesn't have file level permissions to those folders. if it did every hacker in the world would add something stupid like a shell command format c: /u/q to wipe out hard drives.


To build may have to be the slow laborious task of years. To destroy can simply be the thoughtless act of a single day.

 

[rlawrence]

Hi Jeepxo,

Thanks for responding. This sure is a complicated situation for a fairly simple application. The PAWeb application is installed as a COM+ application SPECIFICALLY to allow it to impersonate a trusted user that has the appropriate write access to update the database and to write temporary files, etc. So, ONLY the impersonated user through the PAWeb application has access to the database. The anonymous user is specifically DENIED write access to these areas. These things are well proven by the other web sites in operation.

Ron

 

[jeepxo]

COM+ gives you the ability to move the process away from the IIS worker process so that you can have multiple instances of it running and not crash the webserver.

You still need to give permissions to the file.
I do the same thing with one of our applications.

I also have to add IUSER and IWAM to the CREATOR/OWNER group in the COM+ application.

To build may have to be the slow laborious task of years. To destroy can simply be the thoughtless act of a single day.

 

[rlawrence]

Here's a little more info.

I just tailored the global.asa file to eliminate the call to InitSession and GetSessionProperty methods. I wanted to see if the webMgr would be created without calling any methods. The answer is inconclusive, because I still have to check at least a property of the webMgr to see if it exists. When I do I get the following error:

Active Server Pages error '00000000'
Create object failed
?
An error occurred while creating object 'webMgr'.
Microsoft VBScript runtime error '800a01ae'
Class doesn't support Automation: 'webMgr'
/admin/Default.asp, line 10

Interesting that it still fails when I attempt to access the object--after global.asa has been executed. But, it's not a permission denied error.

Here's my little test procedure:

<html>
<head>
	<title>Publishers' Assistant Web Services Administration</title>
	<link rel="stylesheet" type="text/css" href="../standard.css">
</head>
<body>
<h1>Administration</h1>
<p>
Home directory:  <% =Session("cHomeFolder")%><br/>
PAWeb Version: <% =webMgr.cVersion %> <br/>
PAWeb Build: <% =webMgr.cBuild %>
</p>
<p>&nbsp;</p>
</body>
</html>

 

[rlawrence]

Ahh! A kindred spirit!

You still need to give permissions to the file.
I do the same thing with one of our applications.

Again, I point out that this seems to be a problem ONLY with the user accounts associated with this web site. The COM+ application is set up to impersonate a completely different user, "pawebuser".

Now, which "file" are you referring to? PAWeb.DLL?

I also have to add IUSER and IWAM to the CREATOR/OWNER group in the COM+ application.

I'm not sure that this is where I would want to go. Doesn't this reduce the security that I'm trying to put in place by using COM+ to begin with? Either way, where specifically would you make this setting? Somehow, this problem seems to be related to the COM+ application.

Thanks,

Ron

 

[jeepxo]

WE use ABCPDF from websupergoo to create PDF's for printed pages in 2 of our web aps. That way i don't need to know what you have for a printer, be concerned about what your margins are set to and I'm not using a client side activeX control that needs to be installed by the user. I'm guarenteed that the printed pages look exactly the way I want.

In my case I have to give IUSER and IWAM modify rights to the ABCPDF dll in Windows\system32

In the Component services Consol root snapin
expand Component Services > Computers > My Computer > COM+ Applications
so that you see your application listed.
In my case it's ABCPDF.
Expand the specific COM+ Application > Roles > Creater/Owner > Users

Right click on Users and select NEW > User

Add IUSER and IWAM here.

Now IUSER and IWAM can create an instance of that COM+ object for use on the website.


To build may have to be the slow laborious task of years. To destroy can simply be the thoughtless act of a single day.

 

[jeepxo]

Addressing your security concern

IUSER and IWAM can create instances of the object, and use that object.
They still can't do anything else on the computer because they are restricted accounts.

Although I am giving modify rights to the file, IUSER and IWAM have no way to do anything with that dll except access the functions within the DLL because they don't have any rights to the rest of the directory that it sits in.

Think of it this way. Here's a straw in a cup. The straw is in a fixed position. The lid on the cup can't be removed. You can drink the fluid in the cup, or your can blow air or other fluid into the cup. if you fill the cup up too much, it will bubble out of the straw in your face because it has no other place to go. If you drink all of the fluid the cup is empty.

To build may have to be the slow laborious task of years. To destroy can simply be the thoughtless act of a single day.

 

[rlawrence]

O.K. This is definitely on the right track, but adding IUSR and IWAM didn't quite do it, and I have to say that I don't really understand why.

I took alook at the roles settings on our test server and indeed we have assigned Everyone to the creator/owner role. This was something we probably did to get it working and then never went back to revisit it. When I removed "Everyone" from the role, I got the same failure as above. I then added IWAM and IUSR. I still got the same failure. The web worked again when I added Everyone back to the role.

So, what is the correct way to assign users to this role?

By the way, THANK YOU, JEEPXO, for this suggestion.

Ron

 

[rlawrence]

One more entry:

While following up on JEEPXO's suggestion, I found the following excerpt in the Component Management help:

Assigning a User Account or Group to a Role

You can use the Component Services administrative tool to populate a role with user accounts or groups. The preferred way to assign a user account to a role is to assign the user account to a Microsoft® Windows® group and then assign the group to the role. Using Windows groups to populate roles makes it easier for you to manage large numbers of users. In the online help for the Computer Management administrative tool, see the topic "Local Users and Groups" for more information about creating a Windows group or assigning a user account to a Windows group.

Note To allow unauthenticated network users to run a COM+ application, the application roles must include the Anonymous user. In Windows Server 2003, by default, the Anonymous user is not included in the Everyone group.

There's a lot to learn about COM+. I hope this helps someone else.

Ron

 

[rlawrence]

You know what? Forget the Anonymous Logon user. It doesn't work either. JEEPXO has it exactly right. Add IUSR and IWAM to the creator/owner users list.

You may need to stop and restart the application to get the changes to take effect.

Ron