COM object creation fails when impersonation is done [PSC]

[Guest]

I have a web application with impersonate=â€true†in Web.config and on my own logon page I allow the user to either

- specify a userid/password for the app to impersonate when calling legacy COM objects
- or, just use the interactive user

If they choose to use the interactive option, the impersonate="true" means that the process runs under the interactiv
user (which I've confirmed works correctly). If they specify a userid/password, I impersonate that user in code via th
LogonUser/ImpersonateLoggedOnUser API's. This too works

When using the interactive option the COM object is correctly instantiated under the interactive user and can be called

BUT, if a user is specifically impersonated (even the same one as was available as interactive), object instantiation fails on "Type.GetTypeFromProgID(sObj, true)" with an “invalid class string†exception. The class string is the same one tha
succeeded previously

Note the following

- setting AspCompat=“true†on the page doing the impersonation and COM object creation as per the “ASP.Ne
MTA calling STA COM object access denied†problem doesn't alter behaviour

- doesn’t matter if the COM object is in a COM+ package under a particular userid/password or outside of COM+

- using different API's (LogonUser/DuplicateToken/WindowsIdentity.Impersonate) to perform impersonatio
doesn’t affect the problem. In all cases impersonation succeeds

- doesn’t matter if the ASPNET user is admin on the machine or is set to ‘Act as part of OS’ via Local Policy (whic
isn’t required on WinXP anyway)

- doesn’t matter if impersonation and COM object creation is attempted in Page_ events or not

Finally, changing to impersonate=“false†in Web.config allows COM object creation to succeed when impersonation i
requested (as opposed to above). It also works in interactive mode, however the user in this case stays as ASPNE
which is not much good for the purposes of this particular application

IS there any other reason that COM object creation is still failing when impersonate="true" and I try to impersonat
another userid/password in code? Are there workarounds for the situation? The options I've tried above were suggested b
other posts in this forum

Anthony

 

[Steven Cheng[MSFT]]

Hi Anthony,

From your description, you used impersonate (declaratively or
programatically ) in your asp.net web application and call a COM object.
When you set the impersonate= true and also use the LogonUser or other API
to specifially impersonate as another user, you encountered error when
calling the COM object, yes?
I still not sure the actual steps , so if anything I misunderstand, please
feel free to correct me.

As for this problem, I think you can still try the following things:
1. Try using the SYSTEM account instead of the MACHINE for the asp.net's
workerprocess in the <processModel> element in mahcine.config file to see
whether it'll work.

2. Since you mentioned that the error occure after you call API to
impersonate as a specified account and calling a COM object. Have you tried
use API to reimpersonate as the certain user which is passed form the
IIS(for the integrated windows authentication). For example, when we use a
Domain user account visit the impersonated web app and the current user
should be the domain account, then we use API to impersonate as this
account again to see whether the problem remains.

3. Since the Error message indicate that the problem is likely caused by
the permission issues when try accessing a certain registry for calling the
COM. I recommend that you use Filemon or regmon to have a monitor to
confirm this .

If you have any finding on this, please feel free to let me know. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[Steven Cheng[MSFT]]

Hi Anthony,

Have you had a chance to check out the suggestions in my last reply or have
you got any further ideas on this issue? If you have anything unclear or if
there're anything else we can help, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[Guest]

Steven

Sorry for the late reply. I've been tied up on other things

You had the right idea about the steps. The application is a test harness to test VB6 COM business objects. I allow
domain\userid-password to be entered on a Logon page and then impersonate programmatically if they are supplied
If no domain\userid-password are supplied, the interactive user is automatically made available by impersonate="true
in Web.config. This allows the business objects to be called in whatever user context the person using the test harnes
desires

As already stated, the problem arises creating COM objects after impersonating programmatically whe
impersonate="true". If impersonate="false", creating COM objects works after programmatic impersonation or whe
using the interactive user without further impersonation

Questions/observations of your points

For 1), I don't currently have a machine.config. Is this a per machine or per application file (like Web.config)? I didn't se
one in the .Net framework dir tree. I'll do more reading about this

In 2) you suggest re-impersonating as the (same) interactive user. I tried this by supplying my own domain\userid
password which was the interactive user and was being correctly handled via impersonate="true". I typed the sam
domain-serid\password on my Logon page and programmatically impersonated again and COM creation still failed

3) If it was a permissions problem I wouldn't have expected my own userid to fail when I used this to impersonate. Bu
I'll look at the utilities you mentioned

Anthony

 

[Guest]

Steven

I've found the Machine.config file and made the change you suggested (using system account)

It seems to have worked. I can now instantiate COM objects after having done programmatic impersonation

What would be the reason for this? That SYSTEM has the authority to instantiate COM objects, but ASPNET doesn't? And even though I do impersonation in code, the authorities are still inherited from these users

Also, is there a way to automate the change to Machine.config so that when my application is installed on another serve
the Machine.config is correct. Or can this be done on an application-by-application basis

It seems odd to have to change a machine-wide configuration to get this to work just for my application

Anthony

 

[Steven Cheng[MSFT]]

Hi Anthony,

Since it works when you change the processModel's account in
machine.config. We can confirm that the problem is caused by the default
machine\aspnet account which haven't the read permission to the certain COM
's registry.
Also, the processModel setting is only avaliable in machine.config and not
able to override in web.config.
As my opinion, we still need to find the certain registry which the
machine\aspnet account failed to access and grant the permission for the
machine\aspnet account so that we don't have to change the processModel's
account. Do you think so?

If you have any further question, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[Guest]

Steven

I found another way around this. When I call LogonUser (followed by ImpersonateLoggedOnUser) I should specif
LOGON32_LOGON_NETWORK rather than LOGON32_LOGON_INTERACTIVE. This allows Machine.config to stay unchanged (processModel username="machine") and Web.config to use impersonate="true"

Anthony

 

[Steven Cheng[MSFT]]

Hi Anthony,

Thanks for your followup. Well, since you mentioned that it worked well
when you use LOGON32_LOGON_NETWORK instead of LOGON32_LOGON_INTERACTIVE to
call the LogonUser api, I think this
confirm that the problem is caused by some certain permission of the COM
component's register key not set for the machine account. And when calling
LogonUser via the LOGON32_LOGON_NETWORK and LOGON32_LOGON_INTERACTIVE may
have different perform on the registry's permissions. The
LOGON32_LOGON_INTERACTIVE will let use fully use the current user's
registry permission, so that makes use possible to access the certain
regkey. Do you think so. Also, you can have a monitor to see which regkey
caused the problem and check its access permission list to confirm this.
Any way, I'm glad that you've found a proper solution on this issue. Have a
good day.Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[Guest]

Steven

I'd guess too that it's a permission thing affected by LOGON_NETWORK versus LOGON_INTERACTIVE. Although m
understanding is that LOGON_NETWORK just gives access to network resources and we don't seem to be dealing wit
network-specific resources here I think

Anyway, if I get to do a registry monitor and it shows something interesting, I'll post here

Thanks for your help

Anthony