I created an ASP.NET application for an internal purpose, where the domain user accesses a simple web form, fills in the form and submits. The application impersonates the user and sends an email as the logged on domain user to our ticketing system where a ticket is generated from the user who filled out the form. Now, everything works when I test by logging onto the same server that IIS (7.5) is located and submit the form, but when I try to do the same from my desktop (opening browser and pointing to web server), it does not work. After investigating the issue, I discovered that this is likely a double-hop issue (which I confirmed when the exchange admin checked logs after a few failed attempts and found that site was trying to send email as NTAuthority/Anonymous.)
I've combed the web and found a lot of info on this issue, but all I can seem find are articles detailing the issue in relation to earlier versions of IIS (IIS 5 or 6.) I’m using 7.5 so I’m not certain of how the process for resolving this would differ. Could someone who has had this issue on IIS 7.5 post the basic step by step instructions for resolving double-hop as it relates to IIS 7.5 and sending impersonated email to an Exchange server? Something to the effect of, step one – do this, step 2 – do this, etc…
Another question that I have is the following: Many articles that I have read specify setting up a service account for delegation, and then create SPNs...However with IIS 7.5, I have the option of using application pool identities. Would application pool identities work with delegating impersonation, or would a service account be required to fix the issue?
Thanks all!
From your description, it sounds like your ASP.NET application is trying to determine the logged in user by their Windows network login credentials?
If so, all you should need to do is turn off "Enable Anonymous Access" in your IIS site and make sure that "Authenticated Access" has the "Integrated Windows Authentication" turned on. Then IIS should properly query the browser for their login info and the session should use the user's credentials. This assumes a few things about the client browser used and if something other than Internet Explorer is used, then you might also need to turn on one of the other authentication methods so that the other browsers will properly prompt the user for their network login credentials. Sorry I don't have a running IIS 7.5 server at the moment to give you the exact site properties and descriptions to look at. So if you cannot determine it from my description here, hopefully someone else might add on with that or I can try to follow up later if you need.
Related
I'm currently experiencing an issue with some users of an ASP.NET 4.8 Web API application hosted on Windows Server 2012 and IIS. The following properties are not returning that user's correct user name, and instead returning the name of a service account used for this server:
HttpContext.Current.User.Identity.Name
HttpContext.Current.Request.LogonUserIdentity.Name
I have no idea how to begin troubleshooting this - myself and most other users do not experience this issue, but for a handful of users the above does not return the correct username, returning the username of a service account used to remotely connect to the server in question. Forcing a login via a browser private window does rectify the issue, and the application correctly returns the expected username for each of the above properties.
What could be a cause for Windows Authentication not returning the correct user name and what is the best way to troubleshoot an issue like this?
edit: I was able to resolve the issue, see my answer below
After some additional research and troubleshooting, I determined that the users experiencing the issue described above had the service account in question stored in the Windows Credential Manager:
Removing the service account in question allowed them to be authenticated with the Intranet site with their normal Windows domain\username. As #pcalkins suggested, at some point the affected users had used these credentials on their machine, and Chrome, Edge, IE were using that saved credential when authenticating with the Intranet site.
Please check the following steps:
Make sure that windows authentication is enable and Anonymous Authentication is disable for the website.
Enable integrated security in Interner Explorer (Options/Advanced and checkin the "Enable Integrated Windows Authentication" option).
Add your website to Local Intranet zone and select at least "Automatic logon only in Intranet Zone" option under Options/Security Settings/Local intranet/Custom level).
Aake sure the user and application server are in the same domain.
Wondering if you can help me here, been battering away at this for days now.
i have an IIS site with windows authentication installed, which is working exactly the way it should do. This particular IIS Server houses approx 6 other sites so i have create a new Site called Helpdeskv6, with Application Pool Helpdeskv6 set to .NET 4 integrated using ApplicationPoolIndentity. We are currently working on a 2008 R2 domain, no windows firewall etc.
So i have now created a A Record that gives it a nice little name for our intranet users, the A record is called helpdesk (FQDN: helpdesk.my.domain). The IIS site is setup with bindings on standard port 80 for both helpdesk and the FQDN. but yet when i try and browse to the A record address it constantly prompts me for username and password. When i enter my details they work but i dont want users to be prompted.
i have ASP.NET Impersonation and Windows Authentiation enabled - Providers are NTLM and Negotiate. ASP Impersonation is Auth User. NTLM Authentication is ticked in my ASP Project Web Property page.
i have tried just enabling and disabling so many different settings, i have used setsnp -S HTTP/helpdesk.my.domain webserver001 and i have used setsmp -S HTTP/helpdesk webserver001 as i have read alot that apparently needs these in but nothing seems to work.
i have never used ASP Auth with a A Record before so i am at a severe loss please help, hope i supplied enough information as i do not want to have users entere their windows authentication constantly it should be auto so i am just fearfull i am missing a trick here as when i browse via netbios name it works but this is not appropriate for our environment
Forgot to close this out,
The issue was becuase the site wasnt being registered as a Intranet site and Auth details where not being transported over.
Is it possible for the browser to know the currently logged in AD user without explicitly logging in? I want the code in the server to execute with the same permissions as the user in the browser. Is that possible or do I have to require the user to explicitly log on?
Context: ASP.NET, mostly IE 7, IIS 7.
Thanks.
If you...
use Integrated Windows Authentication in IIS
in web.config where relevant
and your users and IIS server are on the same domain
...then it is possible to pass credentials through the browser. IE (being Microsoft's creation) can do this without prompting, other browsers may still insist on users inputting their credentials at the start of a new session.
OK there are a couple parts to this question so I'll take them one at a time:
First, you would like to authenticate "without explicitly logging in". This is definitely possible with Internet Explorer using Windows Integrated authentication. Please see this article (Internet Explorer May Prompt You for a Password) for more details on requirements for your environment. You will want to enable this with ASP.NET Windows Authentication mode.
Second, you want server side code to run as the client's locally logged in user. This is called Identity Impersonation, and you should read this MSDN article to show how to configure it: Using IIS Authentication with ASP.NET Impersonation
Also See: MSDN Windows Authentication Provider
We have an ASP.net app running on a pair of hosted servers. Access to the app is controlled by IIS using integrated Windows security. ASP code files are in one iis site while static content is served from another. The files sit on a UNC share \\10.x.x.1\mySites and are accessed by users running IE8 and 9.
In the last fortnight or so, the application users are finding it difficult to access the site. Now, when they request the URI they get presented with the standard login box which reappears after every single attempt at gaining access. After a half a dozen attempts the process ends with a '401 Not Authorized' error.
This is odd enough, but after getting one of our network guys to take a look at it, it turns out that the credentials the user typed into the IIS password prompt are not being transmitted to IIS - rather its the credentials (Windows login Id & password) of the current user that are.
Can anyone shed any light on what is happening?
I think IIS holds user account credentials separately in order that it can proces anon access. If this gets out of sync with the corresponding system credentials for the anonymous account, this sort of thing can happen. Have a poke around, I think there is a way to reset IIS.
I am trying to write to a file on a server (web05) from a classic asp site running on Windows 2008 serer on IIS7 (webadmin). This fails and web05 logs an anonymous logon attempt during the course of the save operation.
Webadmin's site is running on an app pool in classic mode with a domain user as the process account. The process account has rights to "Trust this user for delegation to any service (Kerberos only)". The same applies for the web05 and webadmin servers.
The site is using Windows Authentication and the idea is that when I log on the site with my domain user, the rights of my user should define what I am allowed to do in the context of the IIS site. If I turn on Basic Authentication, everything works fine.
I have also used setspn.exe to add an SPN for the URL. If I type setspn.exe -L webadmin, I get:
HTTP/webadmin.companyname.com
TERMSRV/webadmin
TERMSRV/webadmin.companypub.local
HOST/webadmin
HOST/webadmin.companypub.local
So from what I understand the SPNs are set up correctly.
If I run processmonitor on webadmin while the save operation is executed, it says that the process is indeed impersonating my domain user - but getting "Access denied" (and as I said before, web05 logs an anonymous logon attempt).
Any idea what causes this?
Kind regards,
Simon
It sounds to me like you're a little confused over impersonation. The process isn't impersonating the domain user account its simply running as that user. There is a difference.
When a request arrives into ASP it will then impersonate a user and the thread handling the request will be running under the security token of the impersonated user. Its quite possible to have the same process impersonating multiple different users in multiple threads. In most cases where the anonymous user access is enabled this user is the Guest level IUSR account. Its most likely that its under this user your code is attempting and failing to run.
However if anonymous is turned off for the resource being accessed or the IUSR account does not have access to the resource then the a 401 response is sent back, with some indication of what authentication protocols it will accept. The browser may then attempt to authenticate the connection using either the current users credentials or request some credentials from the user.
You don't specify exactly how you are attempting to save file. Its worth pointing out couple of things though.
ASP code exection which may subsequently result in an access denied will not use the above mechanism to try to resolve the user.
Once a connection is authenticated it often continues to be re-used for subsequent requests (which is counter-intuative to the knowledge the HTTP is a "connection-less" protocol).
I am trying to clean up my previous questions. This answer is not sufficient to answer the question above, but I concluded that it is better to provide some insight than none. If op disagrees, please take necessary action.
This is a way back - but I recall wanting to run kerberos authentication on this app. The problem turned out to be that I tried to do kerberos outside the firewall. The app would work fine within the domain and firewall of the server's home domain but failed whenever requests came from outside.
I did a lot of chatting with an Irish technician in Microsoft, and he taught me a little about the limitations when using Kerberos. The reason I wanted to use Kerberos was that I didn't like the thought of Basic Windows authentication being unencrypted.
Good luck with your Kerberos quest :-)
I ran into this same issue and it turned out to be a simple change to the application pool. If enable 32-bit applications is set to FALSE then I recieved a prompt to login to the machine. Setting this value to true fixed the issue.