3

Old server is windows 2000, and the original setup guy's answer to pretty much everything was C:\ --> Everyone --> Full Control. However, there WAS a setup doc, that seemed to work up to a point.

  • Created a local admin com user
  • Created COM+ applications referencing that user and some dll's supplied with the site
  • Installed .net versions 1.0, 1.1, 2.0 (I've tried running under each version, no change in error)

Server object error 'ASP 0178 : 80070005' Server.CreateObject Access Error /Include/fnLookups.asp, line 10 The call to Server.CreateObject failed while checking permissions. Access is denied to this object.

Line 10 appears to be:

set objClient = Server.CreateObject("fooUser.CfooUser")

I trundle off to the System log and I have:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {280D5CF7-80A4-40AC-844C-FE3653F02FF1} to the user mydomain\myusername SID (mySID). This security permission can be modified using the Component Services administrative tool.

This is progress of sorts, it's picking up the COM app and my ID just fine. I added myself to the "Access Permissions" and "Launch & Activation Permissions" of the My Computer object in dcomdnfg - but my barking seems to be directed at the wrong tree.

I ran through mskb198432 as well as I could, though it seems directed at an earlier version, but no joy there, either.

Any ideas are welcome.

Edit - list of suggestions tried

  • Ruled out the x64 difference, running in x32 with the same issue.
  • ruled out file permissions
  • "give Everyone Local Launch and Activation permissions to be sure it's a COM permissions issue" - done, no joy
  • IIS5 Isolation mode enabled

Edit - Is there anything I can look into on the old windows 2k server that may lend some insight?

David Pashley
  • 23,151
  • 2
  • 41
  • 71
Kara Marfia
  • 7,892
  • 5
  • 32
  • 56
  • 1
    Your title says .NET 2.0 app, but your error messages indicate Classic ASP app (VBscript, COM objects, etc). Which one is it? Or is it some sort of mish-mash of both? – Ryan Bolger May 14 '09 at 18:55
  • Yes? ;) I honestly don't know, but if I can check anything to get you that information, I'm happy to do so. I love a puzzle, but I'm going into this one without a ton of prior knowledge to go on. – Kara Marfia May 14 '09 at 20:00
  • The original server had 1.0, 1.1, and 2.0 installed, though I'd thought 2.0 would encompass them all? I'll take a snapshot and install the other 2 to see if it helps. – Kara Marfia May 14 '09 at 20:00
  • You will need to install the 1.0 and 1.1 .NET Frameworks. .NET 2.0 does not encompass the the previous frameworks, but .NET 3.5 SP1 will also add .NET 3.0 & .NET 2.0 Frameworks. – JFV May 14 '09 at 22:51
  • Is the install for the homegrown app set specifically for 32-bit? If so, you might have some issues with the install on x64. If you still have the source, then I would switch the install package to a x64 installation. – JFV May 14 '09 at 22:53
  • Have you looked at the identity of the app pool that your apps is running in on the IIS6 box (see my answer below)? On the 2000 box you can look at if the web site is configured for anonymous access. If so, look at the anonymous access user that is configured for the site. If not, look at the group of people who have access to the site. – squillman May 20 '09 at 19:19
  • Changing to IIS5 isolation mode didn't change the issue, and gets rid of app pools - it seems like that would rule it out as my problem? Using windows authentication (which it picks up, according to the logs). Unless I'm misunderstanding you? – Kara Marfia May 20 '09 at 20:30
  • Not necessarily, it still depends on who the server is running as. If it's running under the context of an account that does not have access to create the objects then you either need to change the user IIS uses for access or grant the IIS user access via dcomcnfg – squillman May 21 '09 at 15:09

14 Answers14

5

Have you tried adding the relevant user to the local DCOM Users group?

http://technet.microsoft.com/en-us/library/cc738214(WS.10).aspx

Neobyte
  • 3,177
  • 25
  • 29
4

This error is the clue:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {280D5CF7-80A4-40AC-844C-FE3653F02FF1} to the user mydomain\myusername SID (mySID).

The COM object should not be running as you, it should be running as the IUSR_MachineName or Network Service user, the user that is running IIS. You don't want every user that accesses the site to be running the DLL as them - bad idea.

Make sure that the permission of the physical directory that your virtual directory points to have the user that is running IIS (IUSR_machinename) have the correct permissions, and the DLL that is registered in COM has the correct permissions for the IIS user.

Permissions are hard to debug in IIS, as security events are not always logged to the Security event log. The Authentication & Access Control Diagnostics 1.0 tool is a great tool for investigating permissions issues.

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1285

user3047
  • 459
  • 4
  • 8
  • I believe I ruled out permissions in the filesystem through aggressive use of "everybody" followed by a rollback of the snapshot when it didn't change the error. ;) I'll try that tool, though. It sounds like just the ticket. – Kara Marfia May 21 '09 at 18:51
  • Ah, but the IUSR_machinename is not part of the Everyone group by default. The Everyone group should not have access. The IIS process should always run in the context of the IUSR_machinename account for classic ASP. Please use the tool listed above, it will show exactly what files are accessed, by whom and why they are failing. – user3047 May 22 '09 at 13:26
2

According to the Microsoft Web Technology blog this is bug is caused by enhanced DCOM security that was introduced in SP1 or SP2 for Windows 2003.

This blog has a pretty detailed run down of this problem and how to solve it.

http://blogs.msdn.com/puneetgupta/archive/2008/01/19/server-createobject-failed-while-checking-permissions.aspx

Bruce McLeod
  • 1,738
  • 2
  • 14
  • 12
2

For completeness sake, there is a difference between running a site as ASP.Net 1.0 and ASP.Net 2.0. Although the framework is backwards compatible, I would suggest trying to run the site as a Framework 1.1 site. This may require the loading of Framework 1.1.

However the code sample suggest that this is classic ASP. Therefore the problem is related to security on the COM Object. Ensure that the DLL has been registered, and there is also a possibility that the object you gave permission to is dependent on another DLL that you haven't given access to.

Also, restart IIS and also the Component itself in component server when changing security, or any changes for that matter. It often needs to be kick started, due to memory caching and other extended reasons.

BinaryMisfit
  • 1,593
  • 2
  • 15
  • 30
  • I did NOT realize the component itself had to be restarted! Thanks for that. There were instructions in the documentation for registering the DLLs, so I believe that's covered. – Kara Marfia May 15 '09 at 12:27
1

I added myself to the "Access Permissions" and "Launch & Activation Permissions" of the My Computer object in dcomcnfg

There are 2 different security settings on My Computer - Limits and Defaults. You need to double check that you edited the Defaults, and that Limits is at least higher than your Defaults (though, IIRC, Everyone can have Local Activation).

You should also drill down to the component itself and make sure it is using the Default security. If it's Customized, then you need to edit that as well (keeping the Limits in mind).

For troubleshooting, I'd be sorely tempted to just give Everyone Local Launch and Activation permissions to be sure it's a COM permissions issue. IIRC, errors in the component startup can have misleading error messages that will keep you scratching your head for a while.

Edit: You should also make sure the GUID referenced in the event log is actually the component you think it is. Use Regedit to find the GUID, and check the AppName. It's possible that it's not the installed component, but a dependency instead.

Mark Brackett
  • 1,117
  • 6
  • 13
  • So it sounds like COM security can be tucked away as a red herring, if adding everybody to both defaults under My Computer didn't have an effect? The GUID does in fact match with the referenced App. No luck, but I appreciate the pointers very much. – Kara Marfia May 21 '09 at 17:44
  • You can only rule it out if your COM app is using the Default security. You can override the security (but never higher than the Limits) on each app, so you need to check those as well. – Mark Brackett May 22 '09 at 13:42
1

As others have said, this is an classic ASP and COM issue - seems to have nothing to do with .NET.

All I can add to what's been said is don't forget to ensure that the user has access to the COM object DLL on the file system.

Robin M
  • 453
  • 2
  • 8
  • 14
1

Try giving "Network Service" an access to the "Temp" directory (C:\WINDOWS\Temp)

I hope this helps ;-)

MarlonRibunal
  • 283
  • 1
  • 3
  • 8
1

Are you running the Application Pool as your account (mydomain\myusername)? If so, you will need to add that account to the IIS_WPG.

You might also want to add IIS_WPG to the "Distributed COM Users" group or find the actual item in the Component Services and directly grant access to IIS_WPG

Christopher_G_Lewis
  • 3,647
  • 21
  • 27
  • Does this hold true if I'm not using anonymous access at all? It seems like it wouldn't but I'll ask the question, since I'm wrong about so many things IIS. ;) I'm not sure any app pool issues count yet, I've given over to IIS5 mode for the moment. – Kara Marfia May 22 '09 at 16:47
1

ASP.Net worker process w3wp.exe by default runs under NETWORK SERVICE account on W2K3.

Check that this account has right to access and instantiate object in question.

zendar
  • 121
  • 1
  • 5
1

I was dealing with this last week. You need to ensure that the ASPNET user (yes, I know it's classic asp) has rights to "Log on as a batch job", and "Log on as a service".

From Admin Tools, Local Security Policy, open up Local Policies -> User Rights Assignment, and make sure that the aspnet user has rights to those policies.

It probably wouldn't hurt to add IWAM_ and IUSR_ as well.

chris
  • 3,933
  • 6
  • 26
  • 35
1

Like some users complained, you weren't clear if this is classic asp or asp.net. That said, going with your subject line and error message, here is my 2 cents

Is this is a .NET application

  1. Make usre ASP.NET is installed correctly.
  2. Make sure the site is configured for ASP.NET 2.0 in IIS.

It looks like your application is accesing a COM object so make sure the IIS worker process has access to that component. You can try running FILEMON and REGMON to find out exactly which component is the culprit. If the component is in the Program Files/Common folder, then make sure the correct permissions is set on that folder.

Accessing COM components in ASP.NET or even Classis ASP is usually a B.... to troubleshoot.

Saif Khan
  • 1,935
  • 2
  • 20
  • 25
1

This is a classic ASP application, not an ASP.NET app. Make sure your IIS app pool hosting that app is running in the context of the user you created. Also, make sure that app is not in any other app pools that host ASP.NET apps.

squillman
  • 37,618
  • 10
  • 90
  • 145
  • For interest sake, classic ASP did not make use of Application Pools so this should have no effect whatsoever. These settings only came into effect in .Net. – BinaryMisfit May 14 '09 at 21:35
  • 2
    Do you have a reference for that? It's got nothing to do with language, it's how IIS creates its worker processes to process the applications. I run classic ASP apps in different app pools all the time. When one goes belly up, nothing outside its pool is affected (unless it happens to bring the box totally to its knees...) http://technet.microsoft.com/en-us/magazine/2006.01.servingtheweb.aspx – squillman May 15 '09 at 02:45
  • Fortunately this is the first app I've moved to this server, though I'll be sure to keep an eye on the app pools for the other two when I add them. – Kara Marfia May 15 '09 at 12:29
  • I will get back with more information on this as I need to double check my own facts :). I replied from memory, and from the official IIS Mock material which I haven't looked at in a few months. I will verify this soon. – BinaryMisfit May 15 '09 at 15:43
0

Besides the other suggestions, I would also try running the website in IIS 5 Isolation mode in order to rule out differences between IIS 5 (Server 2000) and the more secure IIS 6 (Server 2003).

  1. Open the IIS Admin tool
  2. Right click on 'Web Sites' and select 'Properties' from the context menu.
  3. Select the 'Sevice' tab
  4. Check 'Run WWW service in IIS 5.0 isolation mode'
  5. Restart IIS
Jimmie R. Houts
  • 1,853
  • 1
  • 15
  • 12
0

You might want to run through KB 899965, it has some fairly detailed steps and seems like it might be a bit more specific to your issue.

Hope that helps!

gharper
  • 5,365
  • 4
  • 28
  • 34
  • Some of that didn't match up, I'll have to suss out whether it's because this is an XP-specific KB or because I'm missing some registry keys. – Kara Marfia May 15 '09 at 15:26