ASP.NET Fixed Identity Impersonation

[ADavis]

We have a development web server (Windows 2000 Server) and a production web
server (Windows 2000 Server) both are running IIS 5.0 and have the .NET
Framework 1.1. We have asp.net fixed identity impersonation running on the
development server and it's fine. We moved the website to the production
server and we're getting the following error:

Access denied to 'D:\MCJNET\WorkOrderSystems\default.aspx', Failed to start
monitoring file changes.

did a search in Google and found this article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q317955

We followed Method 1 - didn't work.

We are reluctant to follow Method 2 because the individual web site folders
are set to inherit permission from the parent.

Any help will be appreciated.

Sincerely,

ADavis

 

[ADavis]

Also, I just wanted to add that the machine.config file is configured to use
impersonation as well on both servers (this is from our development server):

<identity impersonate="true" userName="domain\servername_ASPNET"
password="*******!"/>

 

[Dominick Baier [DevelopMentor]]

Hello ADavis,

out of curiosity - why do you use fixed identity via config??

 

[ADavis]

We have multiple websites (all with their own databases) running on the same
web server, since we were using the machine account to the connect to the
database (impersonation off in the webconfig file) we felt it might be a
security risk if the machine account were to become compromised.

I read several articles on fixed identity impersonation and encrypting the
credintals in the registry and it seemed like the solution. We could still
take advantage of connection pooling, but not have the account information in
plain text in our webconfig file (connection string).

 

[J-T]

ADavis,

WE are doing the same thing ,can I ask you couple of questions?

1)Are you using NTLM? for each website?
2) When you impersonated under a fixed account,Is it a domain account or a
local account of the webserver?

3) How your connection string to the database looks like? I mean is it using
Trusted Connection or Sql server account?


Thanks a lot

 

[ADavis]

1) Yes
2) We are using a domain account
3) Trusted connection.

 

[Dominick Baier [DevelopMentor]]

Hello ADavis,

why don't you just use IIS6 and run every application in a distinct application
pool with a custom identity??

 

[J-T]

If you are using a Trusted connection,it means that you don;t specify
username and password in your connection string then in Sql server side you
give the appropriate permissions to that domain account,right?
Thanks

 

[ADavis]

Yes, we only give exec permission to our stored procedures to the domain
account specifically created for the web application.

 

[J-T]

ADavis,

Have you ever tested this in this scenario(because we are sharing exactly
the same thing).When you use impersonation using fixed identity ,Is worker
process Identity (ASPNET in IIS 5.x and Identity of application pool in IIS
6.0) taken into account at all or not? I think when impersonating the worker
process accoutn is forced to be your impersonated user .What do you think?
My focous is cross-machine,from webserver to Database server.

Actually you wanted to get an answer for yur problem and u got trapped by
sb's else questions.Sorry about that.

Thanks

 

[ADavis]

That's okay, I'm glad I can help. It's working in our development
envirnoment, and it's passing the account information to the remote sql
server box. Our LAN team called MS and they think the problem is the
production webserver machine account (which is a domain account as well)
didn't have the ability to impersonate, so our LAN team added the account to
the local security policy. We have to schedule a downtime to cycle IIS to
see if it works, I will keep you posted. From what I've read, the client
sends it's token to IIS, which in turn passes it to the ASP.NET engine, this
is where the impersonation takes place, so instead of using the machine
account to authicate to the SQL Server we're telling it to use the windows
account created for the web application. My problem is, it isn't even
getting that far. We are getting an access denied to the web folder. Like I
said earlier, it's working in our development envirnoment, weird stuff, but
I'm learning.

 

[ADavis]

We haven't upgrade to IIS 6.0 and I don't know when that will take place. I
was under the impression that running each website in it's own pool would
degrade the performance of the server? I'll do some research on what you
suggested and pitch it to my manager. Thanks.

 

[J-T]

but I'm learning.
That's very good.So do I.

Exactly what I was going to say that sometimes developers grant some
permissions to an account and they don;t let eachother know.Everything is
fine ,but when it gose to production it is another story.I persoanlly have
found 40% of ASP.NET problems have something to do with security issue of
Worker process and I think the root of all this evil is NTLM and not having
the ability to flow the identity across the bounries.I would appreciate if
you could let me know of the outcome to bahrez_AT_nospam_yahoo.com.I'm so
interested to see what the problem was.

Thanks a million for your valuable time .

J-T

 

[Joe Kaplan \(MVP - ADSI\)]

Have you considered using Filemon to figure out exactly which file or
directory is causing the access denied? That would be a good place to
start.

My guess is that you will need to grant the required read access to the
impersonated account, but Filemon should tell you exactly what is failing.

Joe K.

 

[Dominick Baier [DevelopMentor]]

Hello ADavis,

to be honest - the whole (security) story of ASP.NET and IIS5.x is broken.

- your listener running as SYSTEM
- only one single worker process for all applications

IIS6 is much faster, more robust, more manageable - and the next buffer overflow
won't give your attacker SYSTEM rights on your server....

upgrade that web server and you will never look back.

and btw - when you are impersonating you are really in a wacky state - there
are so many exceptions where the impersonation token ISN'T used (thread switches,
e.g. when calling COM, starting processes a.s.o.) - i would suggest to use
it sparingly.

 

[ADavis]

Actually, my group didn't set up and configure ASP.NET or IIS our LAN group
is responsible for that. Once they cycled IIS, everything worked on our
production server. I checked our development server and sure enough, both
the local and domain account were in the local security policy. On the
production server, only the local account was there. Everything is working
properly. I found this on MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh20.asp.
This is what gave me the idea of using fixed identity impersonation.

 

[ADavis]

We did use Filemon and it said "BAD IMPERSONATION" we intrepreted that as
being the account created for the website, not the domain account created for
asp.net to run under. We called MS and added the domain account for asp.net
to the local security policy to impersonate and everything is fine. Thanks