We have a couple of legacy WebForm apps using FormsAuthentication that we are updating to the latest .NET version and moving from Server 2008 R2 to Server 2016.
After successfully logging in the user is correctly forwarded to the secure section of the app, both in the existing version of the app (.NET 4.5.1) and in debug (.NET 4.6.1), but when deployed on the server the user can authenticate but forwarding fails - it will sit at the login page until the session timeout pop-up appears..
Authentication is
FormsAuthentication.SetAuthCookie(vUserName.ToString, False)
In the original app redirection is
FormsAuthentication.RedirectFromLoginPage(vUserName, False)
We have also tried
Response.Redirect(FormsAuthentication.GetRedirectUrl(vUserID, False), False)
Both work in debug (IIS 7) but neither work as deployed in IIS 10
Deployment does enable Forms Authentication for that site... I'm guessing they changed something in IIS 10, but can't figure it out...
Thanks
I updated 33 NuGet packages, and it threw the toys out over ToolkitScriptManager (removed in v15.1 https://ajaxcontroltoolkit.codeplex.com/wikipage?title=ToolkitScriptManager%20Removed%20in%20v15.1%2C%20Use%20ScriptManager)
Replaced all incidents of ToolkitScriptManager with ScriptManager and it now runs on IIS 10 - Server 2016
Related
Two 100% identical Umbraco 7.5.2 webs are running on a Windows 2008R2 server with IIS 7.5 and a Windows 2012 server with IIS 8.5. Version .NET is 4.5.2.
Member login using method this.Members.Login in Umbraco SurfaceController works in all browsers - just in Firefox 64 it only works in IIS 7.5. Members.Login seems to return true but no Forms authentication cookie is set.
We tested 32bit vs 64bit, various random IIS settings - everything is set identically. No idea - we are going crazy.
Our guess it might have something to do with FF Cookie handling on POST with a 302 redirect afterwards. But here, too, browser dev tools show identical stuff.
Any idea about any applicable differences regarding Firefox/IIS 7.5-8.5/POST/redirect is highly appreciated.
UPDATE: it is a cookie issue - in some Firefoxes the ASP.NET MVC authentication cookie is not set.
The solution was stupid, but I put this here in case somebody has a similar experience.
The server was set one hour too early, and Firefox 64 doesn't allow Cookies that are set with a time like that. All other browsers do.
I have a question as to how the Visual Studio 2013 debug emulator for Web API works.
I had built a Web API project in Visual Studio 2013 to access a database on an external server. The code was built using VS2013's ASP.NET Web Application project template for a Web API application. Once built, running debug opened a browser window for localhost port 56618, which allowed access from Fiddler to test Http requests.
Once I had the project finished, I published it to a website using Web Deploy to IIS. However, whilst the page would open (now at localhost:9812), an http request would throw an Internal Server Error 500.
Perusing the IIS FailedReqLogFiles, I noticed that the reason that it was failing was that the database server was refusing access to '<Domain>\<machine-name>$'.
I added '<Domain>\<machine-name>$' as a valid login (windows authentication, as the connection string included "Integrated Security=true") on the sql instance with read and write privileges, and the problem was resolved.
The question is, why didn't the Visual Studio debug emulator have the same issue?
Because the emulator was running the website under the context of your own account (e.g. <Domain>\You). Your account had access to the database, so there was no issue.
When you published it to IIS, it started running under the context of a different account (<Domain>\Machine-Name - but there are other variants depending on how IIS is configured, and the version of IIS), which didn't have access to your database.
I have a WebApi project that wraps the Dynamics CRM Online web service and provides a REST api. I have a simple controller that gets some contacts from CRM and returns them to the caller.
Everything works fine when I run it in the local emulator. However, when I deploy the project to Azure, I can reach the home page, but the controllers all return http 500 errors. Why would this happen? And how can I troubleshoot to get more details?
UPDATE
The issue is with the absence of Microsoft.IdentityModel.dll on the Server 2012 instance running the web role in Azure. I found this by opening web role instance in RDP, installing Fiddler, and making the request from Fiddler to the local IIS server. It responded with the detailed error.
Now my issue is figuring out how to enable IdentityModel on a Windows Azure Web Role. You're supposed to be able to add it via the Server 2012 Add Roles and Features wizard, but it's totally locked down on the Web Role. You can't check any boxes that aren't already checked. Is this even possible?
The issue is giving the Web Role access to Windows Identity Foundation when it's inherently not there. Marc Schweigert provides clear steps to do this here:
http://blogs.msdn.com/b/devkeydet/archive/2013/01/27/crm-online-amp-windows-azure-configuring-single-sign-on-sso.aspx
Go to the 23:00 mark of the video and you'll see the 4 necessary steps:
Reference Microsoft.IdentityModel.dll (need WIF SDK installed)
a. Set copy local = true
Create RegisterWIFGAC.cmd in your web role project
Create Startup Task in ServiceDefinition.csdef that invokes RegisterWIFGAC.cmd
Add GacUtil to the project (used in the startup task) to put Microsoft.IdentityModel.dll in the GAC every time the web role starts).
I have an old laptop running WinXPpro and both IE8 and CoolNovo which can download an applet just fine from our Win2008 Server R2 SP1 x64 IIS 7.5.7600.16385. I have a new laptop (same hardware) with a x64 Windows7 and IE9 and CoolNovo which can't download the applet (.jar file) from the same server. I can download this .jar file directly as a url and I can download and run the applet over the internet from the .jar product provider on both laptops just fine. So it has something to do with my new laptop. If we add anonymous authentication to the web server, our app works on both too.
Using fiddler, I can see the NTLM authentication conversation on both laptops. On the old one, it works just fine:
A 401 with the WWW-Authenticat Header is present: Negotiate and one for NTLM
Then a 401 (challenge - NTLM type 2),
Followed by a 200 with the client sending the NTLM type 3 header
On the new laptop, I get the first two 401s, but no 200. It simply tries again with the 401s 2 more times.
Any ideas why the new Windows7 laptop would not be sending a 200 NTLM type3 response to the server or what the issue here might be?
Old Laptop: jre6: 1.6.0_30 checked as the user java runtime env. No System java runtime versions checked.
new Laptop: jre6: 1.6.0_31 checked as the user AND system java runtime env.
TVMIA.
I've encountered the same issue and after looking in server security log a have found two strange record just after each unsuccessful logon:
1. 4624 - successful logon. and just after that:
2. 4634 - successful logoff
Very strange... I've googled for these event codes and found this thread:
SCCM reporting not working on W2K8 R2 64-bit
And the solution to this problem is:
1. Open the IIS Manager and go to your site
2. Double click Authentication under IIS
3. Click on Windows Authentication and then choose "Providers..." under Actions
4. Add NTLM if it isn't there and move it to the top.
5. Click OK
It worked for me!
I am using a digest like (but not digest) custom authentication scheme where the authentication header field of the http request contains username:encryptedtokendata
I do not have any problems with this scheme on on Windows 7 and Azure emulator. However when I deployed my service to Azure's Windows 2008 Server SP2 my authentication header fails to make it through to my wcf service. It is null.
IIS on Windows 7 & Windows 2008 Server has both anonymous and membership authentications enabled (because i use membership for certain authentications). Every other authentication is disabled.
Any ideas what might be causing this issue for me? I searched stack-overflow and google up and down without any luck.
I would check and make sure your authentication module is getting installed in Azure and that it is listed correctly in IIS there. You should be able to remote into the instance and troubleshoot it just like you would on premise.