I apologize if I completely bungle this question and description. I have a test and production asp.net application both using windows authentication. They are the same build but for some reason, on my development machine, the test application has started authenticating me as domain\user1 while the production application authenticates me as domain\user2 who I am logged in as. If I try a different machine, both the test and production applications authenticate me as domain\user2 as expected. This happens in both IE and Firefox and only on my dev machine. I've cleared my cache, checked everything I can think of to check and I'm probably missing something obvious. Any thoughts as to why Firefox and IE would be passing me as domain\user1 to the test application?
Related
I have a basic MVC project which I have published to a remote server. It loads correctly but for some reason there is a seemingly random issue regarding logging in, using the default mvc identity system.
Yesterday when I tested it on Firefox/Chrome/Edge it logged in fine on Chrome but took forever to login on Firefox and Edge and eventually timed out. Later I tried it at home on a different computer and all 3 browsers worked fine. Today I try it and Chrome has the issue but Edge and Firefox work. Today when I try it on my friends computer it works in Chrome but not Edge or Firefox.
I don't understand what could be the problem. The database is on one server, the site is hosted on another. If I run the project locally but with the connection to the remote server it works just fine on all browsers all of the time.
The server uses iis 8, I presume I must have configured something incorrectly. Can anyone shed any light on what I might be doing wrong?
Worth noting that I am using Applicationdbcontext for all of my models, one context in one database.
Also, project is running in release mode.
I have a .net web application that is hosted in IIS 8.5. The application is accessing Microsoft System Center Service Manager (SCSM) using the SCSM SDK. The site is using Windows Authentication and impersonating the user accessing the site. Therefore I have followed this guide to setup Kerberos authentication.
Kerberos is working fine and I am able to update and retrieve data from SCSM and that the authenticated user's identity is used. However, during testing, I am noticing that using Chrome (40.0.2214.115), the authentication mode used is NTLM, thus it fails to interact with SCSM.
IE (11.0.9600.17501) works fine.
The kicker: If I open up IE and connect to the application first, and then open up Chrome, it works fine in Chrome.
Most of the users are on IE, but I want to understand what is happening and correct it if I can.
What am I missing?
First: what I can really recommend is to use WireShark (or probably some other network sniffer tool) to analyze what is on the wire. This helped me more than often to trace and find weird problems with Windows, networking, WCF development, Kerberos.... It is not easy with hundreds of captured packets to spot the problem, but you can always compare against a known-good configuration.
For your specific problem, I suggest starting Chrome with
--auth-server-whitelist="*example.com"
as described at http://www.chromium.org/developers/design-documents/http-authentication.
Just to complement previous answer: indeed, Chrome requires site to be "whitelisted" and theoretically in Windows it should be picking up values from Internet Options.
For me what solved the problem was adding Registry Keys on my Windows 7 computer as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthNegotiateDelegateWhitelist"="*"
I have an application that was working on a II 6 development server that uses Windows Authentication. It is a Iron Speed application and I updated a few items and deployed it to the test server where it was previously tested. After deployment, the application doesn't work with Windows Authentication, doesn't even get the credentials login, when I used the full name devweb.etc. It displays a 403 error. However, if I use the IPaddress for it, everything works fine. If take away the windows authentication, the app shows up but of course doesn't work saying it needs a login but it does resolve the web address correctly. I have other applications on the devweb server without window authentication that work without a problem.
Does anyone have any idea of what could cause an application to act in this way?
This ended up being a firewall related issue. More specifically, the firewall switched various websites with the server name devweb to another server which worked fine. Thus, when it appeared like the server was working because devweb sites were working but my particular site on devweb wasn't working except when using the ipaddress. In fact the server was not working correctly and their was a DNS entry problem. Overall, a very frustrating comedy of errors that took too many hours of my life.
I have basic forms authentication set up and it works just fine locally against IIS express. When I deploy, the sitemap security trimming stops working (menu items are showing that shouldn't be there). If I try and go to one of the nodes that shouldn't be there with a user that does not contain the role required, they get kicked back to the the login screen. Because of that that, I know authentication is working properly.
Another developer I work with has it working just fine locally on his machine as well. The deployed web server is where it no longer works.
I don't believe there is a problem with any of the markup sine it works locally, so I'll withhold from posting the code. Every single example on the web matches up with what I have. The code also resides on a network on with no outside access.
No other posts have been found where someone ran into this issue.
Thanks in advance
After lots of experimenting, we think we narrowed it down. We are forced to use cookie-less session state on this system and that seems to be the problem. Our development machines have a major difference in that they have .net 4.5 installed on them. The production server as well as a few other developers only have .net 4.0 installed. If we allow a cookie, it works just fine. It seems that the paths are not being handled properly on the 4.0 machines in cookie-less session state which breaks the security trimming. Some more testing is needed to verify this. Unfortunately updating the production machine is not an option.
I am developing an intranet ASP.NET web application that's configured to use Integrated Windows Authentication. My web app needs to check user entitlements using LDAP to get user memberships, etc.
The issue I noticed today is that, when I run my web app using IIS, sometimes the LDAP calls fail with strange errors, such as "Unable to contact the server..." ... or "...that domain doesn't exist..." (something along those lines, anyway). However, if I run my web app using Cassini, I don't get those errors.
If IIS is the issue, why would it fail some times and other times not? What does Cassini do different that IIS is not doing?
I'm using IIS 5.1 / Windows XP / Visual Studio 2008
Why is this happening, and how can I fix it?
Probably something to do with the fact that when you're running Cassini, it's your domain account that's querying the LDAP. It is strange that it would work in IIS sometimes though, and not others. Is the server registered on the network? What system account is IIS running under?
#James Johnson: I figured it out thanks to your comment, which got me thinking about my domain account... Finally, I found this post which points out that in order to connect to LDAP one needs to set Impersonation=True in web.config. It was working intermittently this morning, I think, because I was using Firefox instead of IE, which required me to enter my domain username and password.
The other strange thing was that my app worked fine in our development and stage environments even though my web.config is the same for all of them. I suppose the guys in the hosting group have this set at the machine.config level.