I have an ASP.net web application that’s running on our intranet, it is using active directory for authentication. We recently migrated away from an old domain to a new domain. Some users are getting This Page Cannot Be Displayed error when connecting to the application.
The errors seem to persist on IE 11 but works in Chrome or Firefox. I suspect that IE is caching user credentials and trying to log users on using their stored credentials and passwords.
We have tried clearing cache and cookies with mixed results, the server has also been restarted but the problems persist.
Any thoughts on how to address this and force IE to users the use their actual credentials and not cached credentials?
Not to add confusion, but I have had some success with some users connecting using the IIS webserver IP address rather than the qualified name e.g. 10.x.x.x/appname.aspx instead of MyServerName/appname.aspx
Thanks
I suspect for those users with the problem that they have allowed IE to save their password. That is not in a cookie.
Have a look in Credential Manager on their workstations. Depending on the OS it would be: Control Panel\User Accounts\Credential Manager
Click "Web Credentials" and if there is a Web Password stored for your application, you will see the URL listed. Just delete it.
This would also explain why the IP works. Because the cached credential is tied to the URL.
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.
I have ASP.NET MVC application that uses windows authentication against remote active directory server. The computer where the app runs is connected via VPN to the AD server. The problem is that after user logs into the PC with domain user and logs into the application it needs to run even while offline as well, but it throws this error:
The trust relationship between workstation and domain failed.
From what I understood there is no cookie and the authorization works on per-request basis. Is there any way to authorize the user name/password against the locally cached credentials? The connection often drops and the application needs to keep running.
Also I can't turn on Anonymous Authentication as we want to sign in users without providing credentials.
Any suggestions appreciated.
Thank you
It was due to calling (while off the network)
User.IsInRole(role)
We have custom role management, so removing base.IsInRole on our custom WindowsPrincipal solved this issue.
After doing research I thought that it actually has to be on the network, but to keep using cached credentials you don't have to be, just do not try to fetch any user related information.
I am trying to create an authentication system that works within the limitations of my organisation's network infrastructure both when inside the local network and outside.
When inside the local network I want people to be able to access this ASP.NET Web Forms application without having to log in using their Windows login.
Externally I want people to have to log in through a custom login form.
The reason is that Windows authentication does not work outside of our local network, due to the local infrastructure.
So, I created a password protected folder by disabling anonymous authentication just for that folder, and then on every page request I check if the user is flagged as being logged in (details on how I do this are unimportant) and if they aren't I redirect to a page that does an AJAX request to a web service located inside the password protected folder to see if they are logged in on the local network. If they aren't then it redirects to the custom login form page.
Now this all sounded like a good idea at the time but in practice it does something undesirable... When an external user attempts to access and the AJAX request is made, I get a browser username and password prompt which has to be cancelled to continue.
I appreciate that this type of authentication is part of HTTP and probably can't be bypassed, even using AJAX, but any ideas how I can get this working without the username/password prompt or an alternate way of checking whether local network or external access?
I know I could check the IP address but I understand this can be faked (although that would only cause an issue to the user attempting to do this).
I also know I could have a different entry point for internal or external but I wanted to avoid this.
I couldn't find a solution for exactly what I wanted to do, so I opted to check if the user was on the local network by checking their IP address.
Although this is sent via a HTTP header and can be faked, it will only result in the user being prompted for username and password via Windows authentication.
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.
Is there a way to get the logged in user from a vb.net web application? IE, if someone logged in as "foo"/"bar" on their local machine accesses the site, I need code to get me "foo"/"bar". This is for a passthrough on our intranet, where everyone uses the same Active Directory.
Essentially, I need to harvest the username of the logged in user and check it against our ActiveDirectory instance. If that fails, I need to check for Request variables and check those (that part is fairly easy). Then if THAT fails, I need to show a login screen (I also have a handle on this).
I've already come across and discarded a couple solutions for the part I'm having trouble with:
request.serverVariables("LOGON_USER") - This only works if you have anonymous access turned off in IIS, and that must be on to use forms authentication (which I'm using).
http://www.thescarms.com/dotnet/IsInRole.aspx - This solution does not seem to work for some reason. I suspect the line AppDomain.CurrentDomain.SetPrincipalPolicy( Principal.PrincipalPolicy.WindowsPrincipal) is the issue, but the meaning of this line is buried so far I can't figure out what it's actually trying to do.
HttpRequest.LogonUserIdentity?
if you're using Forms Authentication, have you tried System.Web.HttpContext.Current.User.Identity.Name?
The web browser will not send the user's local credentials to the web server unless two things are true:
The web server asks for them (i.e. Anonymous Access is disabled, and Windows Integrated Authentication is enabled).
The web browser has been configured to send local credentials if asked (an Internet Explorer option, available in FireFox via plugin, not sure about other browsers). If the browser has not been configured to send the information and the web server asks, the user will be prompted within a pop-up login screen.