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"="*"
Related
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?
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.
I have a Win2003 Server running a number of different ASP.NET websites, all using mixed mode authentication.
One of the applications is causing me issues from one laptop, I get a pile of 401's when I try to navigate to it - ending in a generic "Internet Explorer cannot display the webpage" error. From a different PC I can navigate to the application just fine and I am correctly authenticated.
I am using IE on XP and versions 6-8 had the same issue.
Once in a blue moon, I can get into the application from my laptop.
This problem also affects one or two other people too.
Note, Firefox seems to be okay with opening the application but in general Firefox is not an option.
I had similar problem some time ago. It was caused by wrong password stored in credential manager. Firefox most likely does not use it. Try check:
Open Control Panel.
Open User Accounts.
Click Manage My Network Passwords.
I have a XP Pro and Vista machine setup on a workgroup LAN, normal case
with NAT router/adsl modem. Latop is wireless.
The XP Pro laptop has IIS on it and I have written an ASP.NET app.
When I try to access the app from browser on the Vista PC I get an error
saying can't connect to site.
I have tried the following:
Can ping the XP Pro PC from Vista PC.
Turned on Web access from windows firewall.
Rebooted.
When I telnet to it I get http 400 bad request.
Any thing I am not doing please?
Malcolm
Are you debugging your project using the ASP.net development server? I believe that server does not accept external connections.
If you've allowed access through the firewall, I'd suggest looking at your IIS settings for the website. Is anonymous access allowed? What sort of authentication are you requiring if not? Is the website actually running in the url you're requesting?
Lots of different problems occur because of IIS settings. Play with each possible cause, one at a time, until you find out what it is the real cause, if you still can't find it, play with two at a time.
When you finally find the problem, REMEMBER it, because problems with IIS tend to be forgotten and then you have to go through everything AGAIN. Sadly, I know this from experience.