I have an ASP.NET WebForms application. Some of my users reported that they see their username in "domain\username" format. When they close their IE and open it up back, username is shown as "username". Application shows "username" mostly. However, it shows "domain\username" every once in a while (I couldn't find the pattern).
What is the reason of this behavior?
Environment:
Windows Server 2008 R2, IIS 7
.NET Framework 4.5.2
Anonymous and Forms authentications enabled. Others disabled
Application pool idendity: “ApplicationPoolIdentity”
In application pool settings, “Enable 32-Bit Applications” is “True”
In application pool settings, “Managed Pipeline Mode” is “Integrated”
Internet Explorer 11 is used in client
Variable I use to get usernames: User.Identity.Name
SiteMinder was creating the issue. Once it's installed in your web server, it may change your application's cookies even though your application is not protected by SiteMinder.
Related
On Windows Server 2012 R2, after installing update KB4340558 (update history) / KB4338424 (installed updates) we can no longer instantiate .NET .DLLs (interop) in classic ASP in 32-bit mode using server.createobject. We receive the error 0x800A01AD "ActiveX component can't create object"
When we uninstall the update, the error disappears. Despite my best efforts, I was unable to find an alternate solution to uninstalling. We would prefer to reinstall the update and make whatever changes were necessary to Windows Server and/or the DLL's to allow the COM objects to be instantiated properly. There are no clues in the system logs, no clues in the CVE database, and no clues in the errors ASP is generating. Please help!
We were affected with multiple customers too.
I ruled out invalid strong-name signing of our assemblies, since the .NET Assemblies from the Framework itself were affected by that access-denied error too.
Finally I managed to solve the issue by configuration.
Apparently the authenticating identity of the website has now to match the identity of the app-pool. Or IUSR has no longer enough permissions.
EDIT: 19.07.2018
Warning! This change also has a side-effect:
The asp-classic event "Session_OnEnd" was no longer called and therefore resources eventually could no longer be freed.
But there is a fix for that, too!
The ASP-Config-Property "system.webServer/asp/runOnEndAnonymously" has to be "false", then the event fires again.
EDIT 2: 23.07.2018
As Dijkgraaf pointed out, Microsoft now considers this "new behaviour" a bug. So i guess my "solution" should now be considered a workaround until a new patch comes to rescue.
We run our application pool under a specific identity, to enable a network share and database access. I too thought we were stuck after reading #keydon's answer above.
However, there are three places that we must configure the identity:
The Application Pool - should use the specific identity
The Website "Connect As" - should use the "Application pool identity"
The Anonymous Authentication option, under the Authentication feature - should use "Application pool identity"
That last one was the thing that we were missing - years of considering only the first two meant that we mis-read the great advice above.
Microsoft is aware of the issue and the relevant KB is "Access Denied" errors and applications with COM activation fail after installing July 2018 Security and Quality Rollup updates for .NET Framework
This has impacted BizTalk, SharePoint, IIS with classic ASP and .NET application that uses impersonation.
Workarounds for Classic ASP are as follows
IIS Hosted Classic ASP calling CreateObject for .NET COM objects may receive an "ActiveX component can't create object" error:
If your web site uses Anonymous Authentication: Change the Web Site Anonymous Authentication credentials to use the "Application pool identity".
If your site uses Basic Authentication or Windows Authentication: Log into the application once as the application pool identity, then create an instance of the .NET COM component.
Afterwards other site users will be able to active the .NET COM component without the failure.
Alternatively, if you are using Windows Authentication and accessing the web site from the console of the Windows Server where the ASP application runs: Creating an instance of the .NET COM component also resolves error for other site users.
We support a Classic ASP site running in IIS Anonymous Authentication. The application instantiates a DLL .NET object exposed as COM visible.
After applying recent security Windows Updates and reboot OS our application crashed with following error:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'NameOfObjectInDLL'
In our case, this last advice fixed our problems.
IIS > Authentication > Anonymous Authentication - Edit > "Application pool identity"
screenshot1
This is only to confirm the solution provided by keydon, combined by the one provided by TimP. And give them thanks!!
In our case we've changed the following 3 parts (and an additional 4th for new permissions):
Web server Authentication properties: set Anonymous Authentication with "Application pool identity" instead of "Specific User".
Application Pool "Identity" property: set to "ApplicationPoolIdentity" instead of "LocalSystem".
Web Site "Connect As" for physical path: set to "Application user (pass-through authentication)" instead of "Specific User".
Add permissions for "Application Pool Identity user name" in the shared folder where the web application files are. Have a look to https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#securing-resources
Thank you!!
(I'm sorry I can't vote your solutions because I'm starter and I don't have any reputation)
I searched enough but couldn't find a solution. I have a ASP.NET Intranet app at Windows Server 2008 IIS 7.5 with windows authentication - this all work great.
I have been trying to migrate it to Windows Server 2012. I have already installed Windows Authentication role for the server and already enabled the windows authentication for the web site.
The application seems to be working fine for my account but if anybody else try to connect they get windows login popup.
I was having similar issues. I wrote up this answer:
How to enable Windows Authentication on a Windows Server 2012 IIS website using Powershell?
Short answer is:
Ensure you have Web-Windows-Auth installed
Ensure Set-WebConfigurationProperty has been set for Windows Authentication (and I turned off Anonymous Authentication too)
Ensure your Web.Config is properly setup
The biggest difference is IIS has turned this off by default, and you have to explicitly enable it to use it, even though your Web.Config is configured correctly.
We have the following web server and ASP.Net application specs:
Windows 2012 R2
IIS 8.5
ASP.Net Application using .Net 4.0
Classic managed pipeline
InProc session "UseCookies"
We have a problem when a successful login redirect to inner page which check the session keys to proceed, at that certain point the session keys are clear, where as I checked chrome developer tools I found that the asp.net cookie has no value.
I referred to other threads with the same problem but nothing helped, where all solutions been provided was to play with code where actually the same code and setup above is running fine on other servers, so my suspect is may be windows, .Net or IIS settings, where I have tested it locally on the same server using "http://localhost" and I disabled any tools like (firewall, antivirus, etc...) but it was useless.
Is there any configuration I should check?
I have two websites which are more or less identical, both running on the same server, but under different app pools. The app pools are both configured to run with "NETWORK SERVICE" credentials.
On one website - call this the development copy, I receive the infamous "validation of view state MAC failed" error. This happens when a postback occurs after the page is idle for 20 minutes. I've been informed this is because I don't specify the machine key in the web.config or the machine config file. Manually recycling the app pool reproduces the error as expected. So my question is not about how to stop the issue, but rather I want to know why the error happens in dev but not production. The only difference between the setup of the two sites is the authentication method.
In the "basic settings" section of the IIS config, the dev version of the site is set to connect using a service account, while the production version is using "application user" (pass through authentication). Under authentication settings, both pages are configured with impersonation and windows authentication.
This is the only difference I can see. My knowledge of how IIS handles authentication at the site and app pool level is fairly limited. Is there a specific reason why one setup should result in the machine key being refreshed but the other does not?
After installing .NET 3.5 SP1 you may get Validation of viewstate MAC failed exceptions when doing post backs on ASP.NET pages.
I've recently had my PC upgraded to Vista, which means it includes IIS7. The problem is that the ASP.NET website we're working on doesn't work anymore. I get an error because the application is trying to connect to the SQL Server with NT AUTHORITY/ANONYMOUS LOGON instead of my domain user, and anonymous isn't authorized. I've tried several things, but no solution yet:
- install and enable the 'IIS Metabase and IIS 6 configuration compatibility'
- enable Windows Authentication for this website
- created a different Application Pool with managed pipeline mode set to Classic
- enabled IIS6 WMI compatibility and IIS6 management console (getting desperate here)
In our web.config there's and in our machine.config there's . I've tried putting impersonate to false and entering my domain user and password in the machine.config (it used to be like this) but that didn't help either.
Are there things I'm missing? Has anyone else had a similar problem?
How does your application authenticate with SQL Server? Does it use SQL or Windows Auth? I hope you are trying to use Windows Auth. In that case, your IIS worker process should be running under that Windows user account. If not, it should at the least impersonate a Windows user account that has necessary access rights to SQL Server. If you have impersonation enabled and if you are using the right Windows user account and if SQL Server authenticates using Windows auth and if you are still unable to access SQL Server, you may be running into the classic double hop issue. In other words, you are trying to authenticate to IIS once and you are using the same crdentials to authenticate to the SQL Server over a network next(which is your second hop) and Windows does not allow that for security reasons.
I believe I have found a/the solution. At least it's working now. This is what I did:
The website is now running in a seperate application pool with Managed Pipeline mode set to classic, Load userprofile set to False and Identity set to custom and using a domain user (and password) that has access to the database.
Under 'authorization' of the website itself, I have Anonymous set to enabled and ASP.NET impersonate set to disabled.
in the web.config of the site is also set.
Credit where it's due, this site helped me.
I'm sorry to say I can't look into the issue any further. Indeed, it probably is something with the way we connected to SQL Server (Win Auth) because we've changed it now. Now we connect with username and password in the connection string and it's solved.
So I can't really say if you provided the answer, msvcyc, but I did vote on your solution. Thanks for the time and trouble.
Well, I recommend you migrate to Integrated mode if there is not too many troubles to enjoy the innovation it brings. :)
http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx