I am using windows authentication on an intranet that has been duplicated for two different environments with different servers being accessed. I am using a domain without periods rather than IP so it should log in automatically but it prompts for a login on site 1. On site 2 it prompts for a login, but regardless of which user logs in, WindowsIdentity.GetCurrent().Name always returns my login which was the very first login rather than the current user.
Here is my configuration:
Anonymous authentication: disabled
Windows authentication: enabled
web.config:
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
<authorization>
<deny users="?" />
</authorization>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
Why is it prompting for a login and why is one instance logging in properly and the other not?
Made the mistake of setting a user when the application was created. It is working now.
I have recently published my ASP.NET Core application to my host. I am hitting a HTTP Error 500.19.
IIS 8.5 says the issue is:-
"Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'aspNetCore'"
It also highlights this key add line in my system.webServer config:-
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule"
</handlers>
I'm not really sure what to do on this. It looks as though there is a duplicate instance of this, so I have tried renaming this but it still asks to add this again?
Here is my web.config:-
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!--
Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
-->
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
</system.webServer>
<system.net>
<defaultProxy useDefaultCredentials="true" >
</defaultProxy>
</system.net>
</configuration>
The answer above didn't work for me, however DavidG's comment did solve my problem, so going to post as an answer in case it helps someone else.
For me, I was not running it as a sub-application, and a project that had been working for me no issue for over a year suddenly stopped working with this issue. Still not sure what changed. When I commented out or removed the <add name="aspNetCore".../> the error persisted, and then that line got automatically re-added.
To solve the problem, I added <remove name="aspNetCore" /> to the config file, right above the <add name="aspNetCore"... /> entry, and things started working again.
To continue running on IIS EXPRESS, go on root folder where the .sln file stays.
go to delete file from .vs\config\applicationhost.config or save
it in a temporary place if you have something there.
Close/Re Open VS Studio, run again, will work.
If you need to add something back from save applicationhost.config, just compare those two, but I don't see what you could have there.
None of the suggested solutions worked for me unfortunately. By some miracle I learned that my applicationhost.config file had been modified in an unfortunate matter, making that "Cannot add duplicate collection entry" error appear when I navigated to a specific page in my .NET Core website application.
Under the <sites> tag in applicationhost.config, I had the following:
<site name="MyWebsite" id="2">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Users\___\solutionname\MyWebsite" />
</application>
<application path="/SomePage" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Users\___\solutionname\MyWebsite" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:12345:localhost" />
</bindings>
</site>
The 500.19 HTTP error was shown to me when I navigated to the page "/SomePage". As you can see, for some reason there was a separate <application> tag for this specific page. I have no idea why.
I removed that entire <application> tag for the "/SomePage" path, and everything started working again.
I faced this issue with vs 2017 on a project that was working fine without changing the web.config. Looking at this posts I realized that it might be an IIS express issue and I solved simply deleting .vs folder and restarting vs.
I had the same problem and in my case commenting the line
<add name="aspNetCore"...
solved the issue and brought up the question "why is it working without AspNetCoreModule".
The problem in my case was that I was adding the site as a sub-application in defaultwebsite and it was located in the wwwrootfolder. I think the config was automatically picked up by the defaultwebsite and applied for all sub-application sites.
This link helped
So the solution was to move it as a separate site on another port.
In my case, the issue was caused by putting a path in the Debug Tab of my web project so that the app would open at a particular page. This causes two silent additions to the file .vs\config\applicationhost.config, similar to the one observed by eightx2.
In :
<add name="api AppPool" managedRuntimeVersion="" />
In :
<application path="/blah" applicationPool="api AppPool">
<virtualDirectory path="/" physicalPath="your-path\src\your-proj" />
</application>
where a similar entry already exists. This is the root of the problem.
The error message, unfortunately, is completely misleading.
Solution is to rename applicationhost.config, restart VS, and let it rebuild the file. This is why Ricardo's solution of deleting the entire .vs folder also works.
That error is because there is a root file in ASP.NET Core that is called ".vs\config\applicationhost.config"
Initially it has 67 keys. You can see it for yourself here, in the Configuration Editor.
This file called ".vs\config\applicationhost.config" has the default settings carried by the Web.config to be able to work, and one of them is that handler.
You can also see it here.
The problem is that that file has that handler and what you publish is going to inherit that handler.
You have two solutions, comment on the line of your published web.config or delete that handler from the ".vs\config\applicationhost.config"
I just had this one, it turns out I had changed the App Url in Debug settings for the website Properties, in order to load a specific page (wrong but happened).
In IIS it automatically created a new application under the test domain called About (in this case).
Removing the rogue IIS application under the domain solves the issue as it doesn't attempt to reload the same web.config when navigating to the page.
I commented the below statement
<verbs allowUnlisted="true">
And its works
If you're running your site in IIS, check if your Application Pool has a "duplicate" Application attached.
I had this same problem debugging my site in IIS. While troubleshooting I found that the Application Pool for my site showed 2 applications connected to it. I checked each of my sites to make sure I hadn't accidentally assigned one of them to the same app pool but they were all correct. So I deleted my site in IIS and checked the app pool which then showed 0 applications. I recreated the site in IIS, attached it to the application pool which then showed only the 1 application. Restarted the site and it worked correctly.
Not sure how that phantom application got attached to my app pool but that's what was causing the duplicate aspNetCore key in my case.
I have a parent web application with multiple child applications.
This is what worked for me:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments="<pathToDll>" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>
</location>
</configuration>
Basically, wrap the system.webServer element of the parent website with the location element and set inheritInChildApplications: <location path="." inheritInChildApplications="false">.
Then the child websites can stay the same and you do not need to add <remove name="aspNetCore" /> to each child website's web.config.
Note that this is in the project file:
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
And it gets changed to this during publish:
<aspNetCore processPath="dotnet" arguments="<pathToDll>" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
I have an asp.net mvc project. I installed imageresizing nuget packages. It's working in local.
When I published to my hosting then it's not working.
I set IIS situation integrated and classic but still didn't work.
I couldn't solve, can you help please? Thanks.
The following definitions are exist in web.config
<resizer>
<plugins>
<add name="MvcRoutingShim" />
<add name="DiskCache" />
<add name="SimpleFilters" />
<add name="PrettyGifs" />
</plugins>
</resizer>
<modules runAllManagedModulesForAllRequests="true">
<add name="ImageResizingModule" type="ImageResizer.InterceptModule" />
</modules>
The self-diagnostics page at /resizer.debug explains the configuration issues present on your hosting environment
Image resizer diagnostic sheet 24.11.2014 22:15:04
2 Issues detected:
(Critical): Grant the website SecurityPermission to call UrlAuthorizationModule.CheckUrlAccessForPrincipal
Without this permission, it may be possible for users to bypass UrlAuthorization rules you have defined for your website, and access images that would otherwise be protected. If you do not use UrlAuthorization rules, this should not be a concern. You may also re-implement your security rules by handling the Config.Current.Pipeline.AuthorizeImage event.
DiskCache(ConfigurationError): Not working: Your NTFS Security permissions are preventing the application from writing to the disk cache
Please give user read and write access to directory "D:\inetpub\adafirin.com\www\imagecache" to correct the problem. You can access NTFS security settings by right-clicking the aformentioned folder and choosing Properties, then Security.
I'm trying to add Azure Authentication to an existing website with Visual Studio 2013. It looks like this used to be a bit easier in 2012 but seems the recommended path for 2013 is to set this up when creating the project.
I created a new project with AAD (which works) to compare to the changes being made to the project I need to add authentication to. I copied the authentication classes and config settings but it still seems like there is something wrong in web.config:
For AppSettings I have:
<add key="ida:FederationMetadataLocation" value="https://login.windows.net/_____/FederationMetadata/2007-06/FederationMetadata.xml" />
<add key="ida:Realm" value="https://AADPath/Application" />
<add key="ida:AudienceUri" value="https://AADPath/Application" />
For System.identityModel I have:
<system.identityModel>
<identityConfiguration>
<issuerNameRegistry type="RegistryClassPath, ProjectName" />
<audienceUris>
<add value="https://AADPath/Application"/>
</audienceUris>
<securityTokenHandlers>
For system.identityModel.services I have:
<federationConfiguration>
<cookieHandler requireSsl="true" />
<wsFederation passiveRedirectEnabled="true"
issuer="https://login.windows.net/AADPath/wsfed"
realm="https://AADPath/Application"
requireHttps="true" />
When I run the site, I'm redirected to the login page as I expect but after logging in I'm presented with the WIF10201: No valid key mapping found for securityToken error.
It was not the configuration but rather I didn't copy the data from the embedded database to the existing project. All seems to be working now.
I am using System.IdentityModel to authenticate users in an ASP.NET MVC4 web application using forms auth with a claims principal. (code based on this article: http://brockallen.com/2013/01/26/replacing-forms-authentication-with-wifs-session-authentication-module-sam-to-enable-claims-aware-identity/)
My ClaimsBasedAuthenticationService class issues the SAM cookie from the SessionSecurityToken, and all has been well...except that I just now noticed that it is not creating the session cookies as HTTPOnly or requiring them to require SSL. When I debug the code, I can see those properties on the CookieHandler object are set correctly in the debugger, but the final session cookie that is created simply doesn't have the HTTPOnly and Secure flags marked.
I have the web.config lines to set these to true explicitly as such:
<system.web>
<httpCookies httpOnlyCookies="true" requireSSL="true" />
<authentication mode="Forms">
<forms ... requireSSL="true" />
</authentication>
...
</system.web>
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="true" hideFromScript="true" />
</federationConfiguration>
</system.identityModel.services>
Can someone tell me if there's something else I am missing in order for my FedAuth cookies to be hidden from script (HTTPOnly) and require SSL?
I am using the same implementation and do not see your issue using Fiddler2. However maybe the issue is related to your debugging tool? In IE10 debugging tools the secure and http only flags are only displayed when the cookies are first received. If you check using Chrome debugging tools you should see the flags displayed correctly on all requests.
Did you get this working? I've been using basically the same code and it's all fine.
I can't see that the following suggestions have anything to do with anything, but the only things I can suggest, are to set the cookie lifetime
<cookieHandler hideFromScript="true" requireSsl="true" persistentSessionLifetime="30" />
<forms loginUrl="/Whereever" timeout="30" requireSSL="true" />
and
<system.webServer>
<modules>
<add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
</modules>
</system.webServer>