COM object creation fails when impersonation is done [PSC]

Discussion in 'ASP .Net' started by =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 4, 2004.

  1. 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
     
    =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 4, 2004
    #1
    1. Advertising

  2. 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], May 4, 2004
    #2
    1. Advertising

  3. 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
     
    Steven Cheng[MSFT], May 6, 2004
    #3
  4. 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
     
    =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 7, 2004
    #4
  5. 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
     
    =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 7, 2004
    #5
  6. 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
     
    Steven Cheng[MSFT], May 8, 2004
    #6
  7. 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
     
    =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 10, 2004
    #7
  8. 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
     
    Steven Cheng[MSFT], May 11, 2004
    #8
  9. 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
     
    =?Utf-8?B?QW50aG9ueSBNdW50ZXI=?=, May 12, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raymond Basque

    Re: ASP.NET Fails after SP4 with Impersonation

    Raymond Basque, Jun 27, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    538
  2. Bassel Tabbara [MSFT]

    RE: ASP.NET Fails after SP4 with Impersonation

    Bassel Tabbara [MSFT], Jun 27, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    517
    Michael Kennedy [UB]
    Jun 28, 2003
  3. Hidulf
    Replies:
    1
    Views:
    462
    Michael Kennedy [UB]
    Jun 30, 2003
  4. jon wayne
    Replies:
    9
    Views:
    721
    Jim Langston
    Sep 22, 2005
  5. Zhidian Du
    Replies:
    0
    Views:
    164
    Zhidian Du
    Feb 21, 2004
Loading...

Share This Page