Adobe Acrobat now using Chrome for sign-ins?

[Matthew26563715vqlk]

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!

[Stephen27154615qm7v]

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

[Matthew26563715vqlk]

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

[Test Screen Name]

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. 

[Stephen27154615qm7v]

Ahh that is a good point. 

[Matthew26563715vqlk]

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.

[Stephen27154615qm7v]

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.

[Stephen27154615qm7v]

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

[Chris21824772n20g]

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.

[Chris21824772n20g]

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.