Adobe Acrobat now using Chrome for sign-ins?

Report · Oct 18, 2022

Hi,

We leverage single sign on through microsoft azure to the adobe suite. We have the adobe acrobat pro (32 bit) app. Previously, we had conditional access policies that require device trust. It looks from our logs like the sign in process used to use IE, which supports collecting device data to facilitate conditional access. After a recent update, users cannot log in. I noticed in our logs, that now when users attempt to sign in, it leverages chrome instead of IE on the backend. This lightweight (no extensions) version of chrome will not work with conditional access device trust policies, as without the windows accounts extension, it cannot identify the device. Not a huge deal for now, we have excluded the adobe single sign on from conditional access device trust.

However, I cannot find any release notes that indicate adobe acrobat pro switched to using chrome. This is what i see for logins now from adobe acrobat in the single sign on provider:

I did find an article about sign ins moving to internet explorer a while back:

Update your operating system to work with Adobe apps

"If you are a Windows user

Starting August 2020, only Internet Explorer version 11 and later are supported for signing in. Adobe software uses Internet Explorer during the sign-in process. If you are using an older version of Internet Explorer, you need to move to the latest one before July 14, 2021. After this date, you will no longer be able to sign in to your Adobe account, and will be redirected to this page."

Here is the concern: Is this an intentional update by adobe, which i can find no record of, or is there potential that some malicious actor in the supply chain has modified the application without Adobe knowledge? If anyone else knows of an official listing of this change/update, or is sharing our issues with conditional access, that would be great to know. Thanks!

Report · Nov 15, 2022

Im seeing this on my upgrades of Adobe Products. Was this fix other than changing MFA policys

Report · Nov 15, 2022

Not that we know of. We excluded the app from our device trust policy for now.

Report · Nov 15, 2022

This is probably Microsoft Edge, which replaces IE. It is based on the Chromium browser used in Chrome, and us often identified as being Chrome, I read.

Report · Nov 15, 2022

Ahh that is a good point.

Report · Nov 16, 2022

Great idea on it being chromium but I'm pretty sure that isn't the reason. I also use zscaler as a secure web gateway proxy and this shows as chrome on that too, and I know on zscaler it will show "edge" or "chrome" and not chromium. I'm pretty sure (95%) this is true of Azure AD too.

Report · Nov 16, 2022

Talked to Microsoft and they seem to think it something to do (and i might be wrong in saying this) a webview request. Back to Adobe.

Report · Nov 17, 2022

found this also https://helpx.adobe.com/nz/acrobat/kb/cef-based-sign-in-not-working-with-azure-ad-conditional-access...

Report · Feb 17, 2023

The third workaround mentioned in this article works for us (.CONFIG file); however, we found that if you simply delete the following reg entry, things also work:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Adobe\Adobe Acrobat\2020\WebResource]

- irandom (it's a dword value). You can rename it or delete, and at least for us, seems to resolve this issue, allowing the activation process to pass the AzurePRT token successfully (so deviceID and join type info is passed). I opened an enterprise case with Adobe on this to ask why, but wanted to share this in case it can help others.

Report · Feb 17, 2023

One other note, we're using 2020 perpetual...if you're using DC or 2017, I suspect you would look for this entry under the related version reg key.