ASP.NET impersonation won't change locking user

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • HugoVallejo
    New Member
    • Jan 2009
    • 3

    #1

    ASP.NET impersonation won't change locking user

    Hi everyone.
    I've created an ASP.NET web site which uses a .NET assembly to read/write operations using an odbc driver. When a connection to the odbc database is made locking files are created, when the connection is closed those files are removed.

    I tried the web site using VS2005 and it worked fine. Then I published it in IIS 5.1 (WIn XP SP2) but it didn't work. I thought because write permissions on the folder of the database. So I decided to impersonate, first I tried impersonation in the virtual directory and then programatically . In both cases I used a local administrator account. The problem is that even though the current WindowsPrincipa l shows that the administrator account is being used by the assembly, the database files are locked by ASPNET anyway. I checked this using a handle utility which shows which process and users are locking a file. Becuase of that (I guess) the application is not working. Any operation against the odbc driver fails.

    I've noticed that when I used VS2005 to test the web site, and also a windows application using the same assembly, the odbc database worker process is loadded when I call the Open method of the odbc connection. The process ends when the Close method is called. This is expected and in this case wevrything works fine. However, when I used the published web site, the worker process is loaded just an instant and then it is finished automatically without any reason . That's why after that point any statemente against the odbc driver will fail with the error "No valid application is running"

    Any ideas about why this is happening? Why the locking user on the files is not the impersonated user? why the odbc database worker process lasts just an instant after the connection is Open? Is this becuase ASP.NET does not have permission to start a process?

    Thanks! Any help would be appreciated
  • kenobewan
    Recognized Expert Specialist
    • Dec 2006
    • 4871

    #2
    Are you able to work with a newer version of IIS? This would make things easier otherwise start by checking web extensions. Are you using XP?

    Comment

    • HugoVallejo
      New Member
      • Jan 2009
      • 3

      #3
      Hi kenobewan
      Thanks for your answer.
      I am using Windows XP SP2 IIS 5.1. I've tried the web site in three different computers with the same configuration but I got the same results. I will try it on a Win Server 2003 and see how it goes.

      Anyway, why the ASPNET account is used to acquire the lock on the files if the code is running impersonation? Debuggin the code I can see that the current WindowsPrincipa l and the current Thread user are all the admin account I used to impersonate, why is ASPNET acting?

      Thanks. I'll post how it goes in the Win2003

      Comment

      • HugoVallejo
        New Member
        • Jan 2009
        • 3

        #4
        I've tried the web site in a Win Server 2003 with IIS 6

        I had some problems at the beginning with the security policy. I was getting Request for the permission of type 'System.Data.Sq lClient.SqlClie ntPermission [.....]' failed exception and then with the odbc connection. After adding the permission sets the problem was solved. However, I couldn't solved the SecurityExcepti on I was getting due to the programmatic impersonation so I removed the impersonation from code and enabled the impersonation in the virtual directory (just for testing) using a local administrator account.

        It worked! No problem at all. I guess I just need to fix the policy settings for the application in the server. However, I don't understantd why it does not work in my pc. Wha't's the difference? And again, why the seb site loades a process on behalf of the ASPNET account if impersonation is being used?

        I need to do more development on my machine, how can I fix this?

        Comment

        Working...