Windows authentication not working properly on Chrome - google-chrome

So this is kind of odd.
My scenario:
Web server running IIS, hosting asp.net applications
SQL server
As they are on separate servers, I had to set up kerberos delegation. I have got this working.
So a user goes to asp.net application hosted on the web server, and it authenticates them to the SQL server.
On one of my web apps, when they go to it in Chrome, I get the error page with SQL authentication failed due to Anonymous user. If they go to the same app in IE, it works correctly.
Here is the really odd part - if they then go to it again in Chrome, it works!
So I guess there is some inconsistency in how Chrome authenticates.
I found someone suggesting it might be to do with the IIS negotiation providers, but as it needs kerberos delegation I have to have "Negotiate" as the first option or it fails completely.
I guess I could just tell users they have to use IE, but I would prefer to get it to work in Chrome.
Any thoughts?
(Possibly similar to Kerberos not working with Chrome but it's all on intranet zone, so don't think there's anything to whitelist)

Related

Chrome Web Serial API not working in VueJs Web app

I'm developing an enterprise web app with Vue.js, and I would like to use the Web Serial API in Chrome. On the linux machine that I'm developing on, I went to this Chrome flag chrome://flags/#enable-experimental-web-platform-features and enabled it. Then I did console.log('serial' in navigator) and it returned true, meaning that the flag is enabled. All is good so far.
So I went and did the same thing on the corporate computer I need to be using (running windows 10). I enabled the flag in Chrome, restarted it, and ran console.log('serial' in navigator) on the tab running the web app, but it returns false, which is bad because I need it to be true. But when I run that code on a different tab, it returns true. How could my web app be changing the navigator? So I can't use the Web Serial API on the one computer that needs to be using it and I don't know why.
Any help is appreciated.
UPDATED. The problem is not specific from vue js, you should make the script execute from a secure environment, either localhost or from a ssl secured domain. This security concerns are covered on this draft https://wicg.github.io/serial/#security.

How does chrome know when a server becomes available?

Try these steps:
Find or create a web server (Apache, Node.js, ...) that you can control
Find or create a resource to be served by said web server
Shutdown web server
Try to access a resource at that server's address in Chrome
Notice: ERR_CONNECTION_REFUSED page is shown
Start web server
Notice: Chrome automatically reloads the request.
I have two questions:
How does Chrome accomplish this? Is it just repetitively polling the server somehow?
How could I investigate this myself?
I've tried a few different google searches, but all I can find are support forums for chrome not connecting or pages being unavailable.

Localhost not loading in any browser

I have asked a similar question before here I sort of fixed it but im still facing a similar issue. Every time I try to load localhost, port 8095, I receive this error message in Google Chrome:
Google Chrome's connection attempt to localhost was rejected. The
website may be down, or your network may not be properly configured.
If there is a way to fix it, please tell me,
If not, please could someone inform me how to reset IIS to its original settings. Or if I can reset Windows Features so I can re-install ISS from scratch.
My website uses ASP with a connection to a SQL Server database (2012). Basic HTML pages also don't load under the URL, localhost:8095/
The servers were stopped because 2 services within administrative tools had stopped. World Wide Web Publishing Service and Web Management Service

Hosting subdomains separately with and without SSL while using a wildcard certificate

I'm having a strange problem with a separately hosted subdomain I have. I'm running an application on Engine Yard, let's call it mysite.com. I have a wildcard SSL certificate installed there which covers all the subdomains (things like api.mysite.com). We recently decided to migrate our blog to be hosted independently (right now it lives on wordpress.com). Because I can't run the blog alongside our Rails app with ease on Engine Yard, I decided to grab some cheap hosting space from Dreamhost to host our Wordpress blog there. I set up the server there to fully host our subdomain (let's call it blog.mysite.com), and updated the DNS A record on Hover (our DNS provider) to point blog.mysite.com to the Dreamhost server. So here's the issue:
If I go to blog.mysite.com via Firefox or Safari on my Mac I see the basic Wordpress install which I set up. However, if I try to view things with Chrome I get the following error:
This webpage is not available
Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out.
This happens on all Macs running Chrome I could get my hands on. I tried both clearing the cache and flushing the DNS but nothing. The weirdest part is Chrome keeps looking for https://blog.mysite.com instead of http://blog.mysite.com. There is no SSL cert installed on the subdomain for the blog on Dreamhost because it's not necessary.
Has anyone ever come across this before? And in case anyone wants to try the actual address is http://blog.frestyl.com.
sounds like you have a 301 permanent redirect that Chrome registered http://blog.frestyl.com -> https://blog.frestyl.com. Besides clearing the cache I'm not sure what else can be done.

Impersonation in IIS 7.0

I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.