I have not dealt with classic ASP for over 13 years (and IIS and ASP.NET for a while as well) and today I had to move a classic ASP website to a new server - Windows 2012 with IIS 8.5 from Windows Server 2003 with IIS6. I copied the website directory onto one of the drives (the same drive letter as it was on the old server) and went to IIS Manager and created an application for that directory.
Locally I can access the application via http://localhost/AppAlias/Default.asp and it renders in IE but when I access it remotely via http://ServerName/AppAlias/Default.asp, it does not rende rin IE, instead I get "Internet Explorer cannot display the webpage" error. When I open the same URL in Chrome, it renders just like it does when accessed locally.
I checked IIS settings on the server for ASP applications and under Basic Settings I clicked on Test Settings. Authentication uses Pass-through and it seemed fine but authorization had a warning mark on it. The message was "Cannot verify access to path E:\Pages\Test\AppAlias" and in details I found the following:
The server is configured to use pass-through authentication with a built-in account to access the
specified physical path. However, IIS Manager cannot verify whether the built-in account has access.
Make sure that the application pool identity has Read access to the physical path. If this server is joined to a domain,
and the application pool identity is NetworkService or LocalSystem, verify that \$
has Read access to the physical path. Then test these settings again.
I gave Network Service read access but still having an issue. Can anyone help?
Related
I am in the deployment phase of two separate asp.net 4.5 web applications being put onto a server running asp.net 4.6. We use a mixture of windows 7 and windows 10. All computers are on the same domain and the server is running IIS 8.5. This intranet application is supposed to use windows authentication to either send a user with invalid credentials to a web page with an error message or give the person access to the site. The problem is that some users are getting prompted to login regardless of security group that they belong to.
I have added the domain to the company wide whitelist and set internet explorer to use automatic windows authentication on intranet websites. We have tried moving the site to a non-shared folder. We finally tried converting both of the web applications to a web site project and the security worked just fine. However, we don't want to use web site projects anymore and find this to be a temporary solution.
I have made certain that authentication has been set to windows.
When checking the IIS logs, I see the error codes 401 0 0 15 and 401 2 5 0. Maybe there is some other setting that we are overlooking when deploying? Any help would be greatly appreciated.
For your application to log in with your network's active directory, you need to configure windows authentication twice, the first one is from your application (Visual Studio) and the second one is in the IIS and you must convert the folder into an application and use the framework version correctly.
Visual Studio:
<system.web>
<authentication mode = "Windows" />
</system.web>
IIS:
Convert the folder to application by right clicking and "Convert to application", then select the application and go to the "Authentication" tab disable "Anonymous authentication" and enable "Windows authentication"
Greetings from Mexico.
I currently have an issue where doing a simple file.exists takes 4.6 seconds to return when run from a IIS hosted site. The second run takes 2.3 seconds.
As soon as I remove impersonation it runs in 0.1 seconds.
I have simply created an ASP.Net site with file.exists in the page load to replicate the issue.
The site is setup on a Windows Server 2008 Enterprise, IIS hosting a site in classic pipeline mode, .Net framework 2, Windows authentication enabled (Kernel mode disabled) and impersonation enabled (impersonate user). The application pool uses a domain account with access to the required file locations.
I have what should be 4 identical servers with 3 having this issue and one not with no differences that I can find.
The following factors were the reason for this
• User impersonation on the web service
• The web service using the UNC paths to access SharePoint sites
a. This forces the use of the ‘Web Client’ service to access the SharePoint site using the UNC path
• Default server group policy set to automatically detect proxy configuration settings
This issue then is created by the UNC path using the Web Client service to access the SharePoint site as the impersonated user – it would seem behind the scenes the default Internets settings are used for the impersonated user (no profile on the server) which then requests the proxy (as specified by the default group policy) and times out before continuing without it.
The issue is resolved by altering the default server group policy settings not to use this option –
• Automatically detect configuration settings – uncheck
• Make Proxy settings per-machine (rather than per-user) – Enabled
We're setting up an ASP.NET 4.0 website on Windows Server 2008. The site uses Integrated Windows Authentication for authentication. (It does not use ASP.NET authentication or authorization.)
In IIS, we have only Windows Authentication enabled.
When we browse to the site using localhost as the host header, the site works fine. When we browse to it using the FQDN, the site prompts for username/password but doesn't accept the validly entered credentials.
Some items to note:
IE does have Integrated Windows Authentication enabled
The site with FQDN is entered in the Intranet zone in IE
We've tried adding the site to the Trusted sites to no avail
We did change the Identity on the AppPool from ApplicationPoolIndentity to Network Service with no success
We verified that IUSR has read and execute access to the directory and files
We've set NTAuthenticationProviders to both "NTLM" and "Negotiate,NTLM"
What are we missing?
Thanks.
We were informed finally that the server is not on the same domain as we had been led to believe so it couldn't authenticate against Active Directory. (We had been testing with a local account.)
Configuration:
Windows Server 2008 R2/IIS 7.5
ASP.NET web application using Windows Integrated Authentication. Application pool identity is set to NetworkService. Targeting .NET Framework 2.0. Managed Pipeline mode = Classic.
Full permissions granted to the Temporary ASP.NET Files folder for the Users group and the Internet Guest Account
Logged into server as a test user account (let's call it testuser) which is a member of the Administrators group
User Account Control is on
Internet Enhanced Security is off
Internet Explorer is using all the default security settings and all Compatibility View settings are off
Now I do the following:
iisreset.exe
clear Temporary ASP.NET Files folder
open Internet Explorer
browse to the local ASP.NET web site => success
close Internet Explorer
iisreset.exe
open Internet Explorer
browse to the local ASP.NET web site => FAIL
So far, I have found a few things I can do to keep the site working after an iisreset.exe (each of these work individually, i.e. they do not have to be combined):
Turn off User Account Control
Log in as the Administrator
Run Internet Explorer "As Administrator..." (instead of defaulting to the testuser account)
Use Google Chrome or Mozilla Firefox instead of Internet Explorer(?!?) Those two browsers do not have to be run using the Administrator account but work perfectly well running under the user account and with User Account Control turned on.
Browse the site using an Internet Explorer instance running on an external machine
This problem does not exist on Windows Server 2003. It would appear to be related to User Account Control somehow.
It makes no difference if the user is a member of the Administrators group or not.
Using Process Monitor, it would appear that the access denied problem happens when NetworkService (w3wp.exe) is impersonating the user, but given all the permissions granted to the Temporary ASP.NET Files folder, this still does not make much sense.
The question is:
Why does this only occur with the local Internet Explorer browser, running as a non-administrator user? I would like to use the local Internet Explorer browser for testing, but having to clear the Temporary ASP.NET Files folder after an iisreset is annoying.
What makes Internet Explorer different from Chrome or Firefox (which both work) in this scenario? I could understand if this was something that affected all local browsers, but this is not the case.
I could understand if my web application was doing something special when detecting that Internet Explorer is being used as the client browser, but I do not believe that to be the case and we are talking about an assembly binding failure here - I am not trying to access some arbitrary folder.
EDIT:
The tests above were done using Internet Explorer 8. I have since tried Internet Explorer 9 on the same machine, but with the same results.
If I enable ASP.NET Impersonation for the web site, the problem goes away - but I still would like to know why it does not work for a local Internet Explorer when ASP.NET Impersonation is disabled.
EDIT 2:
What I failed to mention the first time around is that logging in is a two-step process: When accessing the application (let's call it "MyWebApp"), you are redirected to a MyWebApp/Login directory where you will be prompted for your Windows credentials before granted access to the login page residing in that Login directory.
This always works.
After entering your application credentials (in case the code in the login page does not recognize your Windows credentials), you are redirected to a page in the root folder.
The Authentication settings for MyWebApp and MyWebApp/Login are as follows:
MyWebApp MyWebApp/Login
-------- --------------
Anonymous Authentication Enabled Disabled
ASP.NET Impersonation Disabled Enabled
Basic Authentication Disabled Disabled
Digest Authentication Disabled Disabled
Forms Authentication Enabled Enabled
Windows Authentication Enabled Enabled
In both cases, I am getting the "Challenge-based and login redirect-based authentication cannot be used simultaneously" warning.
These settings date back to before I got involved with the project, but that is besides the point. Right now I am only interested in what it takes to get it right - preferably a set of settings that will work for IIS 6.0 and 7.x alike.
Setting ASP.NET Impersonation = Disabled for "MyWebApp/Login" appears to be another way of making my problem go away, but clearly there is more to be done here.
The issue is almost certainly related to Internet Explorer using Windows authentication rather than Basic Authentication (what you'd likely get with FF or Chrome). The combination of Windows authentication and ASP.NET impersonation. If you enable NTLM authentication in Firefox, you will likely see the same behavior there. Likewise, disabling Windows authentication (forcing IE to use basic) or disabling impersonation will likely cause IE to behave like Firefox.
I cannot imagine that browsers have anything to do with it, but if you experienced differences, it must be true.
For ASP.NET to be able to compile an ASPX file, 2 things are imported (as we found out today:
Write access to the ASP.NET Temporary files dir (where the compiled DLL is written)
Write access to the Windows TEMP (where csc.exe writes intermediate files like *.obj)
Which user should have acces there? Depends. In our case the Application Pool user. In your case maybe the impersonated user. Or the IUSR. To me, that part is still obscure.
This one is killing me. I have an ASP.net (2.0 Framework) app that uses integrated security. IIS is setup appropriately and works fine as a virtual directory off the default website. My OLEDB connection (Jet 4.0) works fine and connects to a database file via network share (\GIS1\GIS Server - PublicWorks_StreetSigns).
BUT, when I create an IIS "website" and point it to the exact same home directory I get an error...
Error getting data from DBF. '\GIS1\GIS Server - PublicWorks_StreetSigns' is not a valid path.
Do I have to do something different in a website versus a virtual off the default website to make this work? I've triple checked the virtual settings against the website settings and everything is the same.
Thanks in advance.
I would check the identity of the application pool servicing each website. My guess is that the default identity of the app pool doesn't have permissions to that path.