I have a custom MVC site that uses ADFS authentication for users to access the site.
This was working, I have since made no changes, with the only change occurring on the ADFS side with the TOKEN certificates rolling over. Unfortunately I cannot seem to find anything that indicates that this is related to my now very frustrating error.
Simply put no user can log in, thank goodness this is still under development so at least I do not have screaming users on my hands. I have a Dynamics CRM 2011 environment IFD and Claims-Based auth using this same ADFS server. I have also removed and recreated the Relying-Party Trusts, but still with no luck.
All I get is the following error on the page with the accompanying Event Log entry:
Site:
There was a problem accessing the site. Try to browse to the site again.
Event Log:
Encountered error during federation passive request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '6' seconds. Contact your administrator for details.
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.UpdateLoopDetectionCookie()
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SendSignInResponse(MSISSignInResponse response)
I have searched high and low, I have tried every suggestion I can find, including this post: ADFS v2.0 Error : MSIS7042: The same client browser session has made '6' requests in the last '1' seconds
I have configured my relying party trusts as per the following URL: http://www.cloudidentity.com/blog/2014/02/12/use-the-on-premises-organizational-authentication-option-adfs-with-asp-net-in-visual-studio-2013
I forgot to turn off custom errors, so now I get the following:
WIF10201: No valid key mapping found for securityToken: 'System.IdentityModel.Tokens.X509SecurityToken' and issuer: 'http://XXX.XXX.XXX/adfs/services/trust'.
As such I have corrected the Certificate Thumbprint, but unfortunately that doesn't seems to help the situation.
Still searching and trying solutions for this issue and will update if anything changes.
Any assistance in this regard would be greatly appreciated.
Thanks
Fixed it !! :):)
It seems there was an issue with the "issuerNameRegistry" entry in my Web.Config.
What does confuse me as to why it was working before, but never the less, here is what fixed the issue:
I had the following in my web.config, which did work previously:
<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
<authority name="http://adfs.domain.tld/adfs/services/trust">
<keys>
<add thumbprint="thumbprint"/>
</keys>
<validIssuers>
<add name="http://adfs.domain.tld/adfs/services/trust"/>
</validIssuers>
</authority>
</issuerNameRegistry>
Thanks to this answer https://stackoverflow.com/a/21289207/2985339 on this post Windows Azure intermittent Identity error when parsing webconfig
This is what the web.config now has:
<issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<trustedIssuers>
<add thumbprint="thumbprint" name="http://adfs.domain.tld/adfs/services/trust" />
</trustedIssuers>
</issuerNameRegistry>
Beats me as to why it stopped working, but if anyone else has this issue, hopefully this will help. :)
For the 7402 error, ensure that the identifier in your web.config and the endpoint in the RP both have a trailing slash and that they both match.
For the non-valid key, use the MMC plugin on the server side to get the thumbprint and then post this into something like Notepad++ and inspect it - ensure no dodgy characters etc., then remove spaces and then paste it into the web.config.
I've seen this a number of times.
Sorry to necro up an old thread but to those that up-voted the correct answer - did you add any new references to your project? Import anything etc?
Obviously ValidatingIssuerNameRegistry is not ConfigurationBasedIssuerNameRegistry so was wondering what steps were taken to add/remove any assemblies / versions etc.
Related
I am using IIS7.5, .net 4.0. I am working locally.
I have installed Application Request Routing, Web Farm Framework, WebDeploy and UrlRewrite to set up a reverse proxy. This works fine for the most part.
I have two websites:
DefaultWebSite (port 80, app pool: Default App Pool (.net 4)) and
Target (port 8085, app pool: TargetAppPool(my identity, .net 4)).
I have a rewrite rule on DefaultWebSite (created as directed on IIS.net) which redirects all localhost (port 80) traffic to localhost:8085 just as detailed in the above link. This works fine for most document types (.aspx, .xap, .htm, .ico) but a request to MyService.svc fails. It returns a 404.
To be clear:
When I paste localhost:8085/MyService.svc into a browser I get the requested WCF page.
When I paste localhost/MyService.svc into a browser I get a 404.
When I paste localhost:8085/MyIcon.ico into a browser I get the requested resource.
When I paste localhost/MyIcon.ico into a browser I get the requested resource.
.svc is the only document type that I've found that returns a 404.
I've got two pieces of info that might be of relevance.
App Pools. When I change the DefaultWebSite's app pool to TargetAppPool then the 404 becomes a 500 ("Failed to map the path '/'"). All other requests are successful when this change is made. Not sure if this relevant or not.
FREB (Failed Request Tracing) Log. I found a page (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx) which details the steps in a FREB log when a URL rewrite is more successful than mine (it fails later on). I've not been able to find out how to generate a FREB log for a successful rewrite (if that's possible) so I can only compare my FREB log to the one on that blog. I can see that their step 21 (URL_CHANGED) in my FREB log but not 22 (URL_REWRITE_END). I've not got enough experience with these logs to notice anything more significant than that (suggestions welcomed).
My main question is: does anyone know why just URLs requesting .svc resources are not being rewritten?
A secondary question is: does anyone know how to generate a FREB log for successful request (if it's even possible)?
Thanks
Update:
I have changed the architecture to try to get more info.
I have moved the Target website to a different PC on which I have installed Microsoft Network Monitor to capture the incoming traffic.
Before I changed the url-rewrite rule to point at this new website I got the correct response when I made a request to MyService.svc on the new PC. Fine.
As soon as I changed the rewrite rule to route the request to the new Target website then it responds as before (404). I have made both POST and GET requests. There is no sign of any of the requests in the Network Monitor log (all other calls -200, 404 or otherwise- appear in this log).
This leads me to think that there is something incompatible with url-rewrites and *.svc requests. I tried making a request to MyService.asmx (having created this file) and it correctly returned a page, so it is limited to *.svc. Any ideas?
The solution to this is in the config file of the Target web site.
In web.config (in the Target application) there is a section which read:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>.
I changed this to read:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />.
Credit must go to http://forums.iis.net/post/1956671.aspx for this (although s/he claims it is the proxy's config which needs to be changed, but I found it be the Target app, not the proxy server).
If you still can't get it running, make sure you don't have the WCF handlers on the website which acts as the reverse proxy.
I disabled this by adding this web.config of the reverse proxy:
<system.webServer>
...
<handlers>
<remove name="svc-ISAPI-4.0_64bit" />
<remove name="svc-ISAPI-4.0_32bit" />
<remove name="svc-Integrated-4.0" />
</handlers>
</system.webServer>
Because the rewrite appears to work for all resources except when the extension is .svc I would say this would be the area to concentrate on.
I would imagine that the rewrite rules are matching your other resources, but not your service, and because these are usually regular expressions (which are often complicated) I would say it would be worth testing any rules you find with your urls. Details of how to find the regular expressions for an UrlRewrite can be found here.
It is also probably also worth looking at any outbound rules with the same mindset.
There is already a StackOverflow post that has addressed this issue. However, it couldn't help me.
So, I have written an OpenID login implementation using DotNetOpenAuth and I keep on getting "Message signature was incorrect".
The funny thing is that this is happening from a PC I have at my home. At my work I'm not getting this error and it is working ok.
I've tried to add in the web.config
<trust level="Full" />
<httpRuntime maxQueryStringLength="20000" />
Also, I've added the null parameter while instantiating the OpenIdRelyingParty
new OpenIdRelyingParty(null)
Lastly, I've opened the 443 port in the router and PC.
The key factor is that this is not working from the PC I have at home. However, it is working from the PC I have at work. Both have the same exact code.
When you make a request to an OAuth provider, the framework generates a signature. This signature is a hash of different values, including the URL that you are requesting. The provider then does the same and performs a comparison. If the hash that the provider builds is not the same as the one you've provided via the oauth_signature query string parameter, the request is not considered valid, and you get this error.
I ran into a similar issue when my client application was signing an URL that was something along the lines of api.foo.com/oauth. The server had an URL rewriter that rewrote the URL to foo.com/api/oauth before the provider had a chance to process anything. Since the client URL and the URL that was processed by the provider were different, this caused different signatures, hence the error.
Check your computer clock. The time should be correct as well as the timezone.
If that doesn't help it, please activate logging and see if it gives you more details about why the signature is wrong.
I just switched my .asmx web service to WCF (both in .NET 3.5), and now I am getting
The authentication scheme ' NTLM' is not supported.
The only thing I've seen on google is where some w3svc/NTAuthenticationProviders setting had NTML instead of NTLM. I don't have that issue.
Okay - here is a summary of some annoying WCF issues that I encountered while migrating hopefully it helps someone.
Issue 1 - "This collection already contains an address with scheme http. There can be at most one address per scheme in this collection."
This is caused, I guess, by my web server having multiple web sites with multiple host headers. Solution found here: WCF service startup error "This collection already contains an address with scheme http".
I just added a baseAddressPrefixFilter:
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://yoururl.blahblah.com/" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
Issue 2: I got The authentication scheme ' NTLM' is not supported. error. I struggled with that for a while but eventually a reboot made that one go away (although I also did this (http://bytes.com/topic/net/answers/705912-authentication-scheme-ntml-not-supported):
# change directory to c:\inetpub\admin scripts first
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate,NTLM"
There was a space after the first comma in my config, no idea if that was causing an issue.
Issue 3: After a reboot, I got fun .404 errors.
My first guess at this was that wcf was not set up to be hosted on my server so I ran:
(http://msdn.microsoft.com/en-us/library/ms732012.aspx)
serviceModelReg.exe -i
But the real source of the 404 was caused by me trying to go to http://yoururl/somewhere.svc instead of http://yoururl.blahblah.com/somewhere.svc (i.e. my baseAddressPrefixFilter was causing my 404).
Hope this helps!
Running the ASP.NET webforms run the application works fine. When the application is idle for 4 to 5 minutes, it is giving this error:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
How can this be solved?
This free online tool: http://aspnetresources.com/tools/machineKey generates a machineKey element under the system.web element in the web.config file.
Here is an example of what it generates:
<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />
Once you see this in your web.config, the error itself suddenly makes sense.
The error you are getting says
"ensure that configuration specifies the same
validationKey and validation algorithm".
When you look at this machineKey element, suddenly you can see what it is talking about.
Modifying the pages element under the system.web element may not be necessary with this in place. This avoids the security problems associated with those attributes.
By "hard coding" this value in your web.config, the key that asp.net uses to serialize and deserialize your viewstate stays the same, no matter which server in a server farm picks it up. Your encryption becomes "portable", thus your viewstate becomes "portable".
I'm just guessing also that maybe the very same server (not in a farm) has this problem if for any reason it "forgets" the key it had, due to a reset on any level that wipes it out. That is perhaps why you see this error after an idle period and you try to use a "stale" page.
See http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
This isn't your problem but it might help someone else. Make sure you are posting back to the same page. Check the action on your form tag and look at the URL your browser is requesting using Firefox Live HTTP Headers.
I ran into this because I was posting back to a page with the same name but a different path.
Modify your web.config with this element:
<pages validateRequest="false"
enableEventValidation="false"
viewStateEncryptionMode ="Never" />
Any more info required, refer to the ASP.NET Forums topic
In my website, when a web page is idle for more than 5 minutes, then that page is not working until I refresh. The following error occurs:
Error:
Sys.WebForms.PageRequestManagerServerErrorException:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
I'm already using EnableEventValidation="false" ViewStateEncryptionMode="Never" ValidateRequest="false"
But, nothing is working for me.
Although it's an old question, I will answer anyway because it might help someone else.
So I had this problem in the past few days, and I realized that I started getting this error after I configured my cookies as HttpOnly and Require SSL:
</system.web>
<httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>
Turns out that I just forgot to configure Visual Studio to open the SSL URL of my website. So as long as it opened the regular Url, the cookies couldn't be sent, and that what caused the error.
In order to change the default Url, you simply need to figure out what is your SSL url: Click the project on solution explorer and press F4 (not Right Click -> Properties) and over there you'll see SLL URL under the the Development Server section. After that, go to the project properties page (Right Click -> Properties) and in the Web tab, put the SSL Url as the Project Url.
Make sure all the servers on the cluster are using the same encryption key.
This sometimes happens if you are doing a postback from a form which has an action pointing to a different page.