.NET Application Authentication Causes Extreme Wonkiness
sleekmountaincat last edited by
I have a simple, database driven web application. One of the pages is protected with integrated windows authentication and NTFS rights. The application runs fine, no bugs or errors... until you access the restricted page with correct credentials. After you do this, bugs pop up everywhere: queries return no results, buttons do not run their event code, links function improperly, etc. Once you start a new session, everything goes back to normal... until you access the protected page with IWA.
Keep in mind that the syptoms you mention could come from different problems. But more information is needed. Two most common problems:
- identity impersonation - if you want the user's idenitity to be used to check for resources instead of the aspnet worker process, make sure this is enabled
- process identity - if the application is trying to access network resources, it will need to authenticate against the domain
Are you perhaps using impersonation? With impersonation access and processes (database access) will run under the connected users account rather than the IIS Process. My gut tells me that once the user connects to the secure section all subsequent accesses and database connections will run under the user account and not the IIS process. The user may or may not have NTFS access to those resources so they are probably being denied.
With impersonation off, file access is still restricted by the ACLs of the connected user but processes still run under the IIS service account. The ACL restriction is only applicable to ASP.Net associated files (.aspx, .cspx, .asmx, etc) and not to static files (.gif, .html, etc) but thats generally not an issue. This is old behavior and has been changed in .Net 2.0/Windows 2003 - In this case static files are secured.
If you don't want to build your own custom authorization module and use IWA, I would check the following.
1. Make sure everyone in the domain has read access to the web content directory (assuming everyone should have access to the base app)
2. Remove "everyone" from the secure file (hopefully in a folder), and explictly grant read access only to the specific authorized users.
3. Verify that impersonation="false" is set in the web.config
4. Verify that IWA is enabled in the Website/Virtual Directory
I would recommend putting the secure files in a separate folder because it will be much easier to manage in the long run (ie ACL inheritance).
Here is an MSDN article for ASP.Net 2.0 and Windows Authentication.
The ACL restriction is only applicable to ASP.Net associated files (.aspx, .cspx, .asmx, etc) and not to static files (.gif, .html, etc) but thats generally not an issue. This is old behavior and has been changed in .Net 2.0/Windows 2003 - In this case static files are secured.
My mistake - the behavior change applies to URL authorization and not file authorization which is what I was talking about.
I finally found the original article that spurred my comment on not using impersonation="true" for ACLs. It was recently posted on MSDN as the top 10 pitfalls to avoid for ASP.Net. The link for the article is here.
The impersonation/ACL section is near the bottom of the article.