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.
Related
I have a diagnostic web application hosted in IIS7 that has Windows Authentication enabled and Anonymous auth disabled. This application generated some kind of a report where it includes information about what kind of authentication was used to view the site. Every time I browse to this site I get a message that I connected using Anonymous authentication which for me is unbelievable. The report works fine (tested on other machine) and the fact is that I do not get a credentials popup. How is this possible and how can I fix this?
First, i'm not knocking your diagnostic application, but it may be worth looking at the IIS logs (or indeed switching them on for your site) to see what IIS thinks is going on. If you're not familiar with IIS logs, I'd suggest writing them in Microsoft format (at least while you're sorting this problem). One of the key fields you get is the user id. If you really are hitting the pages anonymously, this id will be the id you configured to field anonymous requests. Otherwise, it will normally be the calling user's id (at least in a simple scenario).
Second, how many sites are you running? Are you sure you're going in through the expected site? Or maybe you're hitting the default site instead?
Third, bear in mind that authentication can be set at the site level but anso at the page level. Are you sure one isn't overriding the other?
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.
I use Windows Authentication with a load balanced website. The load balance is based on two IIS web servers. There is a feature in my site which allow users to relogon like Sharepoint sign-in as different user.
But I notice that while I relogon, the User.Identity in one site is changed but the other site still keep the prior account.
I suspect there are something in the cookie should be clear.
Has anyone faced this problem while playing with loading balance? Or do you know some related article which might help?
I don't know how to fix the problem. Any help will be appreciated.
by the way
I use this method to archieve the relogon it works on single server. http://www.roelvanlisdonk.nl/?p=825.
Hello guys,
I still work on this feature.
I print the User.Identity.Name in my home page. when I change the account, the User.Identity.Name output is changed correctly. but when I refresh the home page, sometimes the prior account will be displayed on the home page.
If I'm reading your comments correctly, your setup involves two web servers, each with a local user with the same name (and presumably the same password), and you're attempting to use Windows authentication in the web farm scenario.
In your situation, each computer has it's own account with a name - assume your username is "AuthorizedUser". Bear in mind that if AuthorizedUser is a local account on both machines, then these are two completely different user accounts. Each computer checks it's own user account information to verify the identity of the person, and in a non-Domain situation, Computer A has no reason to trust a user that was authenticated on Computer B.
If it were possible that computer A trusted computer B without a domain scenario - just two random computers that happen to have a user with the same name, imagine how easy it would be to hack into anyone's web server that's using Windows Authentication. All you'd have to do is guess a valid username, rather than a valid username/password combination. It's easy to see why this is a bad idea.
For Windows Authentication to work in a web farm scenario, you need to be using a Domain user (A Windows NT Domain) and that Domain User needs to have the same permissions set up on two servers. This way, there is only one AuthorizedUser, and both web servers can verify the identity against the domain. Both web servers will automatically trust that the Domain Controller has authorized the user properly and will trust the domain.
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.
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx