cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
648
Views
0
Helpful
7
Replies
keithsauer507
Contributor

Latest google chrome does not transparently identify you to WSA

We're seeing reports of the latest chrome presenting a web filter pop-up authentication box where they have to type domain credentials to proceed.  (Chrome 92.0.4515.107).

Our virtual WSA uses WCCP to the ASA firewall pair and there's a CDA virtual machine that's tied into AD.

 

Any idea why were getting authentication pop-ups all of a sudden?  The system used to just know who you were.

1 ACCEPTED SOLUTION

Accepted Solutions

I noticed that random people were not showing in CDA01.  We have 4 DCs and all look healthy and up.  But further investigation with logs determined anyone who authenticated to one of our DC's just would not show up in CDA.  So I ran windows updates on it and rebooted and now I can get my user name (and see other problem users) in CDA along with some other problem users.  I logged into multiple machines and watched my IP address correctly map to my user name.

 

Prior to rebooting the one DC i just could never get my user name to show up in CDA01.

 

Maybe this was the DC issue and it just so happens the timing coincided when the latest Google Chrome v92 update was approved in our patch manager server.  There was nothing special about the DC logging so that really wasn't our focus.

View solution in original post

7 REPLIES 7
balaji.bandi
VIP Master

is this issue with Chrome only, how about IE ?

 

check some deployment tips ?

 

https://www.cisco.com/c/en/us/products/collateral/security/web-security-appliance/guide-c07-742373.html#_Toc10022542

 

 

BB

***** Rate All Helpful Responses *****

How to Ask The Community for Help

No issues with IE, Firefox or Microsoft Edge (which is chromium based).

 

Just Google Chrome.

 

 

keithsauer507
Contributor

Still happening a day later with Chrome 92.  You get a quick pop up http://webfilter with a username and password box and no other info.  Its causing a lot of calls and confusion because our people are social engineer trained and know not to just enter their credentials in pop ups they are not expecting.  If you let it go it just changes to a webpage saying This page cannot be displayed...

This Page Cannot Be Displayed

Authentication is required to access the requested web site ( webfilter ). A valid user ID and password must be entered when prompted.

If you have questions, please contact your organization's network administrator and provide the codes shown below.

 

Date: Tue, 27 Jul 2021 08:09:47 EDT
Username:
Source IP: 10.7.3.7
URL: GET http://webfilter/B0000D0000N0001N0001F0000S0000R0004/10.7.3.7/https://www.google.com/
Category: URL Filtering Bypassed
Reason: UNKNOWN
Notification: WWW_AUTH_REQUIRED

 

 

Nothings changed with our webfilter.  Should I reboot it?  Should I attempt to update it even though it works fine in Firefox, Edge and IE?  Were on async os 11.8.1.  CDA virtual appliance is showing username to IP mappings (and the other browsers work), so I don't think it was windows updates on domain controllers causing it.

Ok we shut down the WSA.  Then rebooted the CDA virtual appliance.  Ensured in mappings tab user names and IPs were in there.  I do see a lot of employees mapped.  Theres a few trouble spots though, I don't see my user name or a few other users who've complained.

 

I tried downgrading to chrome 91 and it didn't help.

 

Powered back on the web filter and I was prompted with chrome.  If I put in my ad credentials it works.  Other browsers don't ask for credentials, they just go.  But my user name is not anywhere in the cda mapping.  I can't get my user name in the CDA mapping.  Usually, we tell people to lock their screen and unlock it.  I've tried that.  Ive tried restarting.  I've tried logging off windows and logging on.  I tried logging on with my Domain Admin credentials, they don't even show up in the CDA appliance.  I can't get my name in there nor do I see a way to statically assign my name to an ip address.  All 4 DC's show up and healthy in CDA and that should be true because I have the IP to Identity mapping page refresh every 10 seconds sorted by timestamp and its catching new people logging into different resources.

Make sure it someone didn't put people in the filtered list under Mappings/Filters?


Nope only service accounts are in there.

 

Just had another weird one.... was saying cdc.gov was blocked for Health & Wellness in chrome and edge .
Firefox said PR_CONNECT_RESET_ERROR

IE said it couldnt connect securly.

 

Added it to an Allowed domains whitelist we have on all our access policies set to monitor... nothing, still blocked.

Added it to proxy bypass as both entries cdc.gov and www.cdc.gov.  It works now.

 

Thats just one example.  Most legitimate sites via chrome don't work at all.  I checked and none of our certs are expired on WSA.  The timing seems to coincide with approving Chrome 92 updates.  I went back to Chrome 91 but it didnt fix it.  Thats when I looked into CDA and while MOST people are listed in there, a few problem people just cannot show up in there no matter what.  Its not stopping Firefox except for the cdc website.... but most people use Chrome or are told to use Chrome from the vendor, which I'm greatful for getting away from Internet Explorer... but in a business environment if Google is going to release an update every week than I'd rather stick with Firefox ESR.

I noticed that random people were not showing in CDA01.  We have 4 DCs and all look healthy and up.  But further investigation with logs determined anyone who authenticated to one of our DC's just would not show up in CDA.  So I ran windows updates on it and rebooted and now I can get my user name (and see other problem users) in CDA along with some other problem users.  I logged into multiple machines and watched my IP address correctly map to my user name.

 

Prior to rebooting the one DC i just could never get my user name to show up in CDA01.

 

Maybe this was the DC issue and it just so happens the timing coincided when the latest Google Chrome v92 update was approved in our patch manager server.  There was nothing special about the DC logging so that really wasn't our focus.

View solution in original post