I have a windows 2008 R2 Server, my apps use framework 4.5
<compilation targetFramework="4.5.1">
but suddenly one of my apps stopped authenticating against my authentication app in the same server. others do, others just dont the page the page redirect well to the auth site and auth ok, but on the way back to my app the page show the error"connection reset" each time I Try, I see a warning in the event viewer
Exception type: HttpException
Exception message: Cannot redirect after HTTP headers have been sent.
If I try this app in another server or local in my computer it authenticates just fine.
So I think is a matter of WIF versions installed on the server, but I'm Not sure.
Exist any way to know What Wif Versions are installed?
Thanks
Solved,
It was due to miss information on the third app webconfig, was the certificate information was invalid, so it tried to find a certificate that didnt exist on the server.
Related
Overview:
We're trying to configure SSO for OWA on Exchange 2019 server (on-premise), using ADFS. When going to https://mail.domain.com/owa we're experiencing multiple redirects between ADFS and OWA before we get an error in ADFS, followed by an error in the Windows Event logs that says:
Encountered error during federation passive request.
Additional Data
Protocol Name:
wsfed
Relying Party:
https://mail.domain.com/owa/
Exception details:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '0' seconds. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie(WrappedHttpListenerContext context)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.ProcessCommonCookiesInLastAuthenticationStage(ProtocolContext context)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.SendSignInResponse(WSFederationContext context, MSISSignInResponse response)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Steps to reproduce:
Install Exchange Server 2019
Install ADFS and configure SSO exactly following the steps outlined on the following article (click here)
Navigate to https://mail.domain.com/owa.
Troubleshooting so far:
Confirmed that ECP and OWA External URLs match the audiences set in Powershell.
Confirmed that the user I'm attempting to sign in as is able to authenticate using FBA.
Confirmed that OWA is working as expected.
Servers + configuration:
Exchange Server 2019 15.02.0221.017 configured with a self-signed certificate
ADFS 4.0 configured with a self-signed certificate
Question(s):
Where can I go to get the OWA logs detailing why OWA is redirecting back to ADFS?
Is there anything in the above-linked article that's incorrect?
After a bit more testing we found that if we used IE11, the problem went away. The problem only existed for Chrome or Edge Chromium.
We decided to update to Exchange 2019 CU10, and there were no further issues.
I have installed the ADFS 2.0 on windows server 8, When I am going to fetch the page (FormsSignIn.aspx) which is under adfs/ls dierctory I am getting below error
There was a problem accessing the site. Try to browse to the site again.
I have checked the logs in event viewer and got the below message
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
I have checked all the possible way but not able to reslove this problem.
Please assist.
If you are wanting to utilize Forms authentication in ADFS, you do not access this page directly, rather you configure the ADFS web.config for forms authn and you claims enable your application / service provider (SP). The methods for claims enabling an application can vary depending on the version of Windows Identity Foundation (WIF) used.
I have a c#.net MVC3 application running on Windows Server 2008 R2 Datacenter.
If I deploy the application as an application under the main site (i.e. www.mysite.com/crm) it works perfectly.
If I deploy the application as a sub-domain to the main site (i.e. crm.mysite.com) it appears to work as expected, with the exception of one endpoint (crm.mysite.com/reports/view). That path returns the following authentication notice:
Authentication Required
The server http://crm.mysite.com:80 requires a username and password.
I am not aware of anything special for that endpoint and, as I mentioned, it works without issues when deployed under the main site.
What would cause this? How do I remove/prevent it?
I don't even know what code to provide to help diagnose the problem. Please let me know if you want to see parts of the code for any section related to this issue.
UPDATE:
I don't move the path to the application files for either situation and they both use the same application pool. The only difference is how a user access the files via IIS.
UPDATE2:
If I authenticate a user, I get this error:
Server Error in '/Reports' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Why would it think the resource doesn't exist when clearly it does?
If you have authentication on the main site, it won't automatically carry authentication across to the sub-domain. You would have to develop a mechanism to handle that such as SSO (single sign on).
Another potential issue is permissions for the directory/application (eg. c:\inetpub\wwwroot\crm.mysite.com)
I have an application that requires Windows authentication with fallback to Forms authentication. I built it in this way: http://msdn.microsoft.com/en-us/library/ms972958.aspx and everything works fine.
So basically I create forms authentication cookie for a domain based on the outcome of Windows authentication. The cookie is valid as long as the browser stays open. I do not have problems with that in Firefox or Chrome, not even IE8 on Windows XP machines. Unfortunately all Windows7 machines with IE8 experience the same problem: a login prompt shows up when you try to refresh the page after around 30minutes of inactivity. Even if I provide valid Windows credentials I still cannot log in to the application. Nothing helps, but closing the browser and starting it again. Then I am again logged in automatically and it will be fine as long as I stay active. After 30 minutes of inactivity - again log in prompt. After some research I found out that if I delete the auth cookie using developer tools (F12) and then refresh, I get automatically logged in without the prompt (just what you would expect from Windows authentication).
Does anyone of you have an idea what can go wrong and how can I get it to work correctly on Windows7 machines? Or maybe ideas on where to look? Is it IIS problem (I use IIS6 on Windows 2003 Server), client problem? What makes Win7 IE8 so special that it fails?
I don't know why it expires, but I managed to get rid of the problem. Somehow on IE8 on Win7 it cannot continue, because it tries to auth, but the old auth cookie is supplied. If I clean the cookies on the request and then forward to the login page, it works. It's not a solution to the problem, but at least the user gets re-authenticated...
We have a website that was recently updated from ASP.NET 2 on IIS6 to .Net 4 on IIS7.5.
When we deployed to the new Production server, we started getting http 404 errors after people logged in. I.e. users could see the default login page, but once authenticated the website would crash. As the URL had been modified to include the eurl.axd components we thought maybe it was something to do with ASP.NET v4 (as per everyone elses issues with this error). Except everyone having this issue is working with MVC whereas this website is MVP.
So we rolled the code back to the old server while I looked into it. Now I've got them to redeploy the same code to the Production server again, but had them point the test domain to it for testing purposes. The website is working just fine.
So the only difference is that when accessed via http, the website works fine. But if you assign it a https URL, then the post-authentication redirect crashes.
Any ideas?
We had the same problem when moving from 3.5 to 4.0 Framework on IIS 6. We would see this problem whenever you redirected back to the parent url ie www.somewhere.com/
By adding this into the registry of the web server it stopped the eurl.axd from being injected.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0]
"EnableExtensionlessUrls"=dword:00000000
Check over here too ASP.net 4.0 default.aspx problem on IIS6 this details the same issue as well.