Google's chrome browser update from 84.0.4147.89 to 84.0.4147.105 has broken MSAL login (authentication) in Incognito window for our application.
To verify that there is no issue with our application, I have tried Azure AD B2C login with the starter pack in Incognito browser and I see the same behavior. Has anyone experienced the same issue?
A similar issue was posted in the past by few developers. But the solution provided doesn't help.
https://support.google.com/chrome/thread/38855209?hl=en
FYI: Login works as expected in Chrome regular browser and other browsers
Starter pack details:
https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp
Starter pack has msal 1.3.3 version. Couple of days ago, 1.3.4 version has been released and I tried that as well. I see an error during acquiretokensilent(CallApi) in incognito while I don't get the same exception in regular window
The only difference between starter pack and our application is that we call acquiretokensilent immediately after the login is successful but in the starter pack acquiretokensilent is called on a button click(CallApi)
Azure AD B2C login issue in incognito window is fixed for me by enabling cookies in the google chrome settings. Below are the steps to enable cookies.
Chrome settings -> Privacy and Security -> Cookies and other site data -> 'Allow all cookies'
Moving answer from comments
I tried the starter pack by calling the acquiretokensilent after successful login as you mentioned. I received an error
User does not have an existing session and request prompt parameter
has a value of 'None'
The reason for this issue is due to not enabling the popup in chrome incognito mode. once i enabled the popup i was successfully able to call acquiretokensilent with out any error.
You can even provide sites to have cookies for current session.
CHROME SETTINGS --> PRIVACY AND SECURITY --> COOKIES AND OTHER DATA DATA -->
Sites that can always use cookies --> add site
For aquiresilenttoken(), add https://login.microsoftonline.com/*
Or your preferred authority URL.
Related
I am evaluating W3C pay Google examples by enabling the Chrome Extension from Google's example here: https://bobpay.xyz/ (Clicking "Install web payment app" on the bottom). This installs the W3C Pay Chrome extension.
I then use their demo here:
https://paymentrequest.show/demo/
I am able to submit a payment using the "Bobpay" extension, see below:
... however when it comes time to redirect to the Bob pay "Account Selector" web application (the front end of the Payment Handler), I get the following error in Chrome's Developer tools:
"Aborting payment handler window "https://bobpay.xyz/pay" because of navigation to an insecure url "chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh/data/shared/tpc-check.html"
It's complaining that the redirection to the chrome-extension URL scheme is insecure.
I already took both Certs from bobpay.xyz and paymentrequest.show sites, and installed them to my System keychain. Then I trusted both SSL certs. This didn't help.
BTW, this works on Windows, but not on MacOS (Chrome on both).
Also: submitting a sample credit card payment outside of the Bobpay extension works fine (by using a locally stored Credit card option, and not the Bobpay extension) - returns tokenized card to be forwarded to payment processor.
This demo code also does not work on any other browsers, such as Firefox or Safari (unsupported on both).
In the Security panel of Chrome Developer tools, we can also see that the Chrome Extension for Bobpay is marked as "Unsecure":
I also installed the whole thing on Localhost, created a self signed SSL cert, added it to keychain, trusted it, and ran an https-server with that cert, but I get the same issue on https://localhost:8080/bobpay as well.
After verifying that the demo worked on another MacOS machine, I figured I introduced an issue trying to clone bobpay and deploy it on localhost under another name. The two payment handlers were somehow trampling over each other, when redirecting to the Frontend Handler page.
I ended up removing all Chrome files in ~/Library/Application Support/Google/Chrome, clearing all Chrome settings (reset to default), and re-installing Chrome. This cleaned out all extensions, cached data, and service workers under Dev Console --> Application. I am now able to proceed without errors.
We're making a Chrome extension that will be built specifically for organizations. They will specify it as a force-installed extension.
We've packed the extension with the latest crx3 format and verified that after packaging, we can install the extension in to Chrome by dragging it in to the extensions tab. It installs as expected and I've verified the extension ID is correct.
We have a test enterprise domain with a few chromebooks. We've gone through the process of specifying the custom app, but it's not showing up. I've verified the policy has updated both through the G Suite admin console and in chrome://policy on the users device. When looking at the policies, I see the extension we're force installed listed in the table on chrome://policy, but the extension itself isn't showing up in the extension list.
Is there a good way to debug why a managed extension isn't being installed from the enterprise policy?
After some trial and error, we solved the problem due to a mixup of URLs in the update XML created for versioning.
I have a download link for an app (ad hoc, only to work on a few designated devices for testing). I have configured my plist file correctly, so the app itself downloads and installs without any issues. However, I think due to it being ad hoc, it does not install the certificate needed to run the app (I currently get the untrusted developer alert, and their is no certificate in general settings for me to trust).
So I tried to add a link for the provisioning profile on the same download page. Clicking on the link in the browser brings up an alert saying that Settings wants to show me a configuration profile. I click allow and it takes me to the Profile area in General settings, but there is nothing there.
How would I go about creating a simple link to download the profile onto the device? The code I used for the link is pretty straight forward.
Profile
Can anybody help? Many thanks in advance.
So I tried to add a link for the provisioning profile on the same download page.
You are not in a right direction. No one will ever do such download profile thing.
For Ad Hoc build, you have to add your desired devices to your ad hoc provisioning profile. I assume you did not do it so you can download the app but cannot install it.
So check your developer certificate portal and remember to re-generate your provisioning profile having these devices checked. And then build the app again with the new provisioning profile.
So it turns out that the issue was when I was archiving the project from Xcode to an IPA file. I was using the default setting for the developer certificate that I should be signing my app with. It also had a dropdown list to select a second certificate (which as far as I can tell is still the same certificate). Selecting the second one seemed to sort the issue out, where as the default option for some reason did not include the certificate with my IPA file. Not sure why it worked this way, to be honest. App now installs and runs without any issues.
We are doing automation testing on a intranet application. Chrome browser does auto login when we visit the site (through NTLM login). We need to login as different users through automation test.
We were using the flag '--auth-scheme="digest"' to restrict Chrome from using NTLM.
args = ['--auth-schemes=digest']
Capybara::Selenium::Driver.new(app, browser: :chrome, args: args)
But looks like this option has been removed in Chrome v41. Related Issue
Is there any other way to achieve the same in new version of Chrome?
I found a way to restrict the AuthSchemes with help of registry. I will still look for a better way to do it.
AuthSchemes can be controlled by registry settings as per this link.
https://dev.chromium.org/administrators/policy-list-3#AuthSchemes
I created two files and running disable_chrome_ntlm_login.reg file restricts the AuthSchemes
1) disable_chrome_ntlm_login.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="basic,digest"
2) enable_chrome_ntlm_login.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="basic,digest,ntlm,negotiate"
Run "disable_chrome_ntlm_login.reg" file to disable NTLM authentication scheme before testing and "enable_chrome_ntlm_login.reg" revert the Chrome to old state.
so, have web-site configured for ADFS 2.0 authentication...
for IE - it works fine and did authentication correct
for Chrome - it reaches redirect to AD FS server... ask to authenticate but could not authenticate.
I try to requests using fiddler but it show nothing interesting - so show that we redirect to adfs for authentication but nothing more
what it could be? why it is impossible to authenticate for chrome
thanks
In the event viewer you will see an 'Audit Failure' event with "Status: 0xc000035b". You can circumvent this problem by switching off 'Extended Protection' for the adfs/ls web application.
There are several articles on the Web on this, for example the "0xc000035b error during windows integrated login" thread on Microsoft's AD FS forum. Quoting:
To turn Extended Protection off, on
the AD FS server, launch IIS Manager,
then, on the left side tree view,
access Sites -> Default Web Site ->
adfs -> ls. Once you’ve selected the
"/adfs/ls" folder, double-click the
Authentication icon, then right-click
Windows Authentication and select
Advanced Settings… On the Advanced
Settings dialog, choose Off for
Extended Protection.
This issue occurs in several situations that I know of: when using Firefox 3.5+ or Chrome, using some specific NTLM configuration for which I don't have the details at hand, and when using Fiddler (see the "AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger" TechNet article post, and the "Fiddler and Channel-Binding-Tokens" blog post which contains more technical background information).
(Note that nowhere I could find any information how to make NTLM authentication to AD FS from, e.g., Google Chrome and Firefox 3.5+ work without switching off 'Extended Protection'. I mean, Internet Explorer works with 'Extended Protection', why don't Chrome or Firefox? Or is this a Chrome/Firefox implementation bug/restriction, e.g., in their use of the Windows NTLM library?)
From Microsoft: http://technet.microsoft.com/en-us/library/hh852537.aspx
Unless and until Firefox, Google Chrome, and Safari support Extended
Protection for Authentication, the recommended option is to install
and use Internet Explorer 10 or later. If you want to use single
sign-on for Office 365 with Firefox, Google Chrome, or Safari, there
are two other solutions:
(1) Uninstall the Extended Protection patches
from your computer. (2) Change the Extended Protection setting on the
Active Directory Federation Services 2.0 server. See
“ExtendedProtectionTokenCheck” on the TechNet Set-ADFSProperties page
for details.
Switching off extended protection is not the answer. You add chrome as so adfs can recognize it and then add the site to the trusted list.
Make sure chrome is supported by adfs.
So, if you run the following commands:
$a=Get-Adfsproperties
$a.WIASupportedUserAgents
Then you add chrome to the list.
Set-ADFSProperties -WIASupportedUserAgents #("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")
Now, we will need to tell the Chrome that it should allow Windows Integrated Auth for the site.
To do this, you will need to go to the settings:
Click on Advanced
Click on Proxy settings
It should open your IE Properties. Click on Security & Select "Local Intranet" and add the Federation service name of your ADFS here.
Click close and Apply under IE Properties.
Restart Chrome and next time when you try to access the site, it won't ask you for credentials.
This was a solution presented at work to allow SSO with Chrome WITHOUT disabling Extended Protection. Cheers for MS support.