Scenario
User A can access all pages in MVC4 website except one. But user B can access all pages (no restriction).
What I had done so far?
Deployed website on IIS 7.5.
Enabled window authentication and disabled Anonymous authentication for hosted website on IIS.
Testing website.
Testing Results -
(1) When User B is logged on same system (development system) where the website is deployed, he can access the website without prompt dialog.
(2) But when same website is published on server (production system) with same settings, website still asks for credentials with pop up.
** Both of the development system and production system are in same domain (let's name it domain.com).
Question
Why is the same user in same domain is been asked for credentials by website?
As per my research for Window Authentication, I want to conclude following lines (also as reference for me) -
(1) Window Authentication (abbrev. WA) will always show prompt for verifying users if you had configured WA properly.
See anonymous authentication disabled and windows authentication enabled in below snapshot.
(2) Even if one set NTLM as top provider than Kerberos (in IIS), the IIS will still ask for Window credentials. Snapshot show how to do that.
(3) If you want to avoid showing prompt on browser for WA, follow steps-
(a) Open IE browser --> Internet Options --> Security tab.
(b) Add site to Local Intranet zone so that browser will send logged-in username and password to IIS.
Note - The above points universally apply to MVC and ASP.NET.
Answer to my question Why is the same user in same domain is been asked for credentials by website?
Because I had set anonymous authentication enabled along with Window authentication on development system. (Silly mistake).
Related
I am developing an ASP.NET MVC 4.5.1 application using VS 2013.
Following are the settings at the IIS 7.5
Windows Authentication Enabled (also in Web.config authentication mode is set to "Windows").
Anonymous Authentication Disabled.
Application pool is running with service account "contoso\john".
The mode is Integrated.
On my landing page (e.g. HomeController.cs) I am storing logon user information as below:
Session["LogonUserName"] = HttpContext.Request.LogonUserIdentity.Name and that's working fine, I can use the Session["LogonUserName"] from other views.
However, when redirecting from home page to a different view e.g. Customer View something weird is happening and somehow I am losing the authentication and I am not able to step into a function.
So I Disabled the Windows Authentication and Enabled the Anonymous Authentication but then on the customer view page I am getting HttpContext.Request.LogonUserIdentity.Name = "NT AUTHORITY\IUSR"
and Session["LogonUserName"] = contoso\john, which is my app pool account.
Any idea why? Could someone please help me?
Ok. The issue certainly due to be authentication (XSS problem) and the JavaScript code wasn't being trusted when running on localhost or on IP address. When given a DNS entry (site binding) the issue resolved.
I have a rails application running on nginx + unicorn and I want that users can login in with their Active Directory crendentials. I've already implemented connecting to AD server and authenticating users, but they need to enter passwords.
Is it possible to somehow get this information on this setup? I've found some topics about this problems, but they don't quite explain how to solve this problem and most of the answers are for IIS sever.
I know that it propably can work only in Internet Explorer.
Signing in automatically is handled by the web server, not your application. Since you are using nginx, there are a couple of third party modules you can use, such as spnego-http-auth-nginx-module or nginx-mod-auth-kerb. IIS has support built-in, of course.
Once you've set up the web server, your application can retrieve the user's username from the REMOTE_USER environment variable. Internet Explorer will automatically log in; Firefox and Chrome will do so if they have been configured for the domain by the system administrator, but this is off by default.
I have a mvc3 applicaiton using windows authentication. it works fine on my local pc.
<authentication mode="Windows" />
after I deploy it to the dev server. every time, i go to the site, a login popup shows up, I need to enter ID and password to access the site. on my local computer, I never see this popup login form. always automatically logged in. What do I need to change on the server side to fix this issue.
in the IIS, I disabled anonymous authentication, only enabled windows authentication. My computer and the serve are on the same domain.
You need to add the server to the local zone in internet explorer. The server needs to be added to the local intranet as it is not being automatically detected. Add the server to this list, restart IE and it will authenticate automatically.
at my company we have a number of clients and partners accessing our TFS 2010 SharePoint project portal and Team Web Access site over the Internet (https mostly but in this case http). For most of them everything works fine. For one client though, the following happens:
Authentication prompt appears when accessing either the project portal or Team Web Access
User types in username and password
The page loads half-way with text, but without CSS or images loaded.
Prompt appears again, even if "Remember password" is checked in the browser dialogue (IE8)
User tries the same procedure 10-20 times but gives up, resulting in an incomplete page load with no CSS or images.
In our attempts to remedy this we have opened ports 80, 8080, 443, 1443, 8000 but the errors still occurs for this specific client.
We thought it might be related to port 8080 causing firewall problems, so we moved Team Web Access to port 80, but the problem is still there.
Why could this be happening? The client certainly wants to know but I'm afraid I have no good answer yet.
Try change Internet Options > Advanced > Under the security section > uncheck "Enabled integrated Windows Authentication".
Try adding your Team Web Access URL to the Intranet Zone sites list. Internet Options > Security > Local Intranet > Sites > Advanced. There is a security setting that says 'Automatic logon only in Intranet zone'.
Also, take a look in Control Panel > User Accounts > Manage Windows Credentials and make sure that an incorrect password is not saved for the site.
I've created a basic MVC 3 website that's using Windows Azure's Access Control Service (ACS) to perform user authentication against an Active Directory Federated Service (ADFS) endpoint. I followed the "Add STS Reference" wizard and the site runs fine and authenticates users just perfectly in IE. However, when I use Chrome or Firefox it continually prompts for my credentials over and over again.
I found this post on technet that mentions the issue as it pertains to Firefox but there's no fix for Chrome mentioned, nor do I feel like the steps required to fix Firefox are practical in the real world (i.e. I can't expect end users to do this)
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx
Has anybody else hit this snag? What am I doing wrong?
With some help from a Microsoft Rep (Adam Conkle) over on TechNet (scroll down to the comments), I finally have an answer to this problem.
Turns out, the ADFS website that performs authentication of users (this website gets setup in IIS during the installation of ADFS v2.0) is by default configured for Integrated Windows Authentication (IWA). IWA is configured in IIS to use Extended Protection for Authentication (EPA) and therein lies the problem. Apparently, most other browsers don't support EPA yet which is why Firefox & Chrome continually prompt for credentials in a loop.
Two options...
Keep using IWA but turn off EPA in IIS for the website (described here)
Turn off IWA in favor of Forms-based Authentication (described here)
I had the same issue, sort of. I had 1 person who was being prompted in Chrome and another that was not. On a hunch, I looked at the trusted sites. The person who was being challenged had the intranet site in their list of trusted sites. I removed it and tried again. This time they were not challenged.
Thought I would put that out there in case anyone else has this issue.