Windows Authentication succeeds but IsAuthenticated == false - asp.net

Environment is IIS 7 integrated pipeline, ASP.NET 4.0. I have a .aspx page configured without anonymous authentication and with windows authentication:
<location path="auth/windows">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
When I request the page, a normal Windows auth (NTLM/Negotiate) challenge response happens, and ultimately the page is returned.
I have an HttpModule in which I handle the PostAuthorize event. As expected, this event is only raised once the challenge-response authentication has succeeded and access to the page has been authorized.
However, the Request.IsAuthenticated property is false; and HttpContext.Current.User.Identity reflects an unauthenticated user (.Name returns the empty string). Interestingly, Request.ServerVariables["LOGON_USER"] does return the value of the authenticated Windows user.
I'd have thought that once the user was authenticated (and authorized, for that matter), the request would reflect being authenticated; and the User / Identity for the request would have been properly set.
Any thoughts on why this is not the case?
Thanks,
Donnie

It turns out that the native handling of Windows authentication works when you have Forms authentication enabled in Web.config. But the managed part of Windows authentication - associating the authenticated Windows user with an IIdentity-derived object representing that user - only happens if Windows authentication is enabled in Web.config. Looks like I'll have to rely on the Request.ServerVariables["LOGON_USER"] value.

windows Authentication is enabled in IIS and authentication mode set to windows in my web.config file.
<authentication mode="Windows">
</authentication>
My site is asking for credentials and it's working fine. but when check using
HttpContext.User.Identity.Name
is empty string
Or
HttpContext.User.Identity.IsAuthenticated is false;
I used Request.ServerVariables["LOGON_USER"].Tostring(); to get logged in user credentials.
It worked for me, Thanks for Posting soccerdad.

Related

How can I understand and eliminate login prompts showing up on MVC site using Windows Authentication

I have an ASP.NET / MVC website using Windows Authentication.
On IIS side, it is set-up to only allow Windows Authentication.
The web.config side is configured to allow windows authentication only:
<authentication mode="Windows" />
<authorization>
<allow verbs="OPTIONS" users="*" />
<deny users="?" />
</authorization>
<identity impersonate="true" />
The issue is that sometimes (depending on users [which is weird, but it may just be random], between 1 and 50% of the time), instead of loading the page as expected, the browser (Chrome and IE behave the same) will display a login prompt instead of loging the users in a seamless way.
I have not been able to determine any way to force it one way or an other, and if the user keeps refreshing the same page, in the same browser, it will end up working (if the user got the login prompt in the first place), or showing the prompt.
EDIT:
I have activated Failed Request Tracking in IIS. I can see that all queries fail with an error code 401.2, which is expected, since Anonymous Auth is disabled.
This first response contains the accepted Authentication modes in its header:
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
For most requests, the next request is used to authenticate the user, and everything works fine.
When authentication fails, and a login prompt is shown, the next request is a 401.1, with the error message:
Indicates a particular Security ID may not be assigned as the label of an object. (0x80070513)
I have no idea about what is causing this behavior, and even less about how to solve it.
It could possibly be a duplicate SPN issue. And if it is, I believe your application is running under NTLM and not negotiate (kerberos).
Few things you can test here.
Capture fiddler trace from client. If the authentication token starts with TIRM..., its NTLM and not kerberos.
Also, please share the following info.
Is this a load balanced environment ?
Do you access the site using custom domain name or server name ?
what identity is your application pool running under.

How to get the current logon user name in asp.net?

I have a web app, in the web.config, I have following settings:
<authentication mode="Windows"/>
<identity impersonate="true" userName="domain01\user01" password="***"/>
I deployed the app to Windows 2008 (IIS 7), the Identity of the application pool is domain01\user01, and in the Authentication of the app, I have following set:
Anonymous Authentication Disabled
ASP.NET Impersonation Enabled
Basic Authentication Disabled
Digest Authentication Disabled
Forms Authentication Disabled
Windows Authentication Enabled
Now I need to get the user name who is currently logged on the machine, could be any authorized user with different domain. But no matter what I tired, I always got the impersonated user domain01\user01. I tried, HttpContext, WindowsIdentity, etc. Does anybody know how do I get the correct user name without changing my settings?
You are specifying domain01\username as the identity that you want to impersonate. That is why the current user is always that. If you remove the configured identity you will get the actual logged in user.
<identity impersonate="true" />
This is documented here:
http://msdn.microsoft.com/en-us/library/xh507fc5(v=vs.85).aspx

ASP.NET windows authentication should always ask for credentials

Problem statement :
I have implemented windows authentication on my website.
I have used following code in my web.config for authentication
<authentication mode="Windows">
</authentication>
<authorization>
<deny users="?"/>
</authorization>
Now, the problem is that when I access the website, it takes the default ( windows) credentials and tries to login.
But I need that it should prompt the user for credentials so that user can enter domain-name\id and password of separate domain for authenticate (User will have VPN access to this other domain)
You can achieve this using Digest Authentication mode in IIS. Once enabled it will prompt always for UserName/Password to the end user.
You can read more about this type authentication here:
http://technet.microsoft.com/en-us/library/cc778868(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc754104(v=ws.10).aspx
Instead of using Windows Authentication use Forms Auth and check entered login and password in Domain.
There is a nice article on MSDN: How To: Use Forms Authentication with Active Directory in Multiple Domains

proper IIS 6 configuration for forms authentication

I'm using Forms Authentication in my current ASP.NET Web Application (not MVC) and my IIS 6 server is configured with the following options:
in the [directory security tab] -> [Authentication Methods] I have:
the anonymous access Enabled
Integrated windows authentication Enabled
Do the above options prevent Forms Authentication from working properly? In other words, what is the proper IIS 6 configuration for Forms Authentication?
EDIT
I just made test with the two options above enabled and the Forms Authentication session expired and redirected me to the login page, but all the answers so far advise that [Integrated windows authentication] should be off!
Here is a check list for using ASP.NET Forms Authentication on IIS6
Configure IIS:
In IIS, Site Properties -> Directory Security -> Authentication and Access Control
Enable Anonymous Access
Disable all Authenticated access methods
Configure Forms Authentication:
Configure Forms Authentication in your site's web.config:
<authentication mode="Forms">
<forms name="MySite"
path="/"
loginUrl="~/logon.aspx"
protection="All"
timeout="30"
slidingExpiration="true" />
</authentication>
Your name and loginUrl may vary. The slidigExpiration attribute is used to keep extending the forms authentication cookie lifetime rather than just kicking the user off of the site after the timeout has expired. The timeout value is in minutes.
Configure Session Timeout:
You need to configure your session state timeout to be longer than your Forms Authentication ticket expiry. If you don't do this then an idle session can time out the session but leave the user logged in. Code that expects Session values to be present will throw exceptions because they are gone even though they are still authenticated. The timeout value is also in minutes.
<sessionState mode="InProc" timeout="40" />
Because forms authentication does not rely on IIS authentication, you should configure anonymous access for your application in IIS if you intend to use forms authentication in your ASP.NET application.
See here http://msdn.microsoft.com/en-us/library/ff647070.aspx for more information.
The anonymous access should be enabled, I don't think integrated windows authentication makes a difference but if you're not going to need it then it's best to turn it off. The important thing to remember is to make sure it's turned on in web.config:
<authentication mode="Forms" />
Here's a basic tutorial that might be useful:
Overview of Forms Authentication
Anonymous access -> checked
All other option on the security tab -> unchecked
Note, forms authentication is done by .NET - not by IIS. Also, Windows Authentication MUST be off as well.
Rather technical explanaitions by MS.

AuthenticationType Negotiate vs NTLM

I have the same code base used on 2 different sites hosted on the same server (IIS 7.5).
For some reason, when I check the Identity.AuthenticationType property on the code behind of an http handler I see NTLM for 1 site and Negotiate for the other. This is causing some problems and I need both of them to use NTLM.
Could you help me to figure out why this difference? So far I see both IIS sites are configured on the same way but of course there is at least 1 difference that I couldn't detect.
Thanks!
EDIT
I've used this link that provides instructions to remove "Negotiate" provider from IIS. It didn't work for me. I executed
appcmd.exe set config "Contoso" -section:system.webServer/security/authentication/windowsAuthentication /-"providers.[value='Negotiate']" /commit:apphost
Maybe I did something wrong, but it didn't help. I still see "Negotiate" as AuthenticationType
The problem I have is that I'm setting on web.config impersonation credentials but it's not using them. Instead of using credentials I provide, it uses the anonymous user.
And something weird is that windowsAuthentication is disabled. I thought "Negotiate" was only used by windowsAuthentication.
Negotiate will choose either Ntlm or Kerberos authentication internally.
If the site says Ntlm only Ntlm authentication would be choosen.
Please check both the site and make the authentication has same.
Windows Authentication will need to be enabled and Anonymous Authentication disabled to get the logged in user (I am assuming here that you are on authenticating on a domain and don't want to fall back to an anonymous user if the user doesn't have authorised credentials using windows auth).
In IIS7.5, to see the providers being used, click on Authentication, right-click on Windows Authentication and select providers. You will have a list of enabled providers, the order is important. Try making sure they are both the same (in your case have NTLM at the top of the list).
Sorry for the late response!
First thing to check is if there is a difference between the authentication types that are enabled for each site.
By default only anonymous is enabled.
If your version of Internet Information Server (IIS) is 7.0 take a look in the <%SystemDrive%>/Windows/System32/inetsrv/config/ApplicationHost.config file for a section like this:
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="false">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
The documentation for Windows Authentication Providers may provide more detail.
The Remove NEGOTIATE from WindowsAuthentication in IIS question provides instructions for removing Negotiate which I found helpful when I was trying to re-enable Negotiate.

Resources