Adobe Creative Cloud and Conditional Access Restrictions

In Azure Active Directory it is possible to create Conditional Access rules that restrict applications to only running on company owned or managed devices. Conditional Access approves or rejects the login based on that knowledge – so what happens if the app in question is running on a company (managed or compliant) machine, but the app does not pass that information through to Azure AD? Your login will be rejected is what happens!

There are two options. One is to exempt that app from the “only company machines” rule (and maybe have a different rule in place) or see if there is another way to authenticate the user on that device for that app. And this is what we found for Adobe Creative Cloud.

Adobe Creative Cloud to sign-in presents a popup inside the application. The popup is a web browser control, but not a full browser. In Azure AD this popup is identified as Chrome 105 (the latest version of Chrome at time of writing is 113). To get Chrome to pass through the device identity to Azure AD (so that managed or compliant can be evaluated) requires the installation of the Windows Accounts extension or the Microsoft 365 extension, or after Chrome 111 the CloudAPAuthEnabled option.

But as we can see above, the Azure AD sign-in logs show that it is Chrome 105 and not compliant or managed (as there is no Device ID associated with the login) so CloudAPAuthEnabled is not an option we can try. We rolled out the two above extensions via Group Policy and they were turned on in Chrome, but login was still failing – and incidentally, the Chrome sign-in was version 112 and showing a successful sign-in as the extensions where working and device identity was happening. In Azure AD the logs looked like this:

So though we have pushed out the extensions, the popup web browser control in Adobe Creative Cloud is not using these extensions. So its either not Chrome or a very cut-down version of Chrome version 105 and totally independent from the Chrome installed on the device.

Becuase this does not work is my reason for thinking that maybe the popup web browser control is not actually Chrome. Azure AD thinks it is Chrome because of the User Agent that the control uses – “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36” – but it might not actually be Chrome and the app is just using this string as a user agent.

So, what was the fix. In this case (and its specific to this application) there is a way to allow authentication to happen in the default browser on the OS and not via the web browser control popup. You need to set a registry key, and we used PowerShell scripts via Intune to do this, but any method is fine. The registry key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown

DWORD

iAcroLoginType

with a value of "5". 

The PowerShell script we used to set this via Intune was:

if((Test-Path -LiteralPath "HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown") -ne $true) { New-Item "HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown" -force -ea SilentlyContinue };
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown' -Name 'iAcroLoginType' -Value 5 -PropertyType DWord -Force -ea SilentlyContinue;

Once this setting was on the machine, restarting Adobe Creative Cloud application and choosing Sign-In opens the login screen in the system default browser. If that is Microsoft Edge then device identity is passed through as long as you are signed into the browser with your corporate identity, and if the system browser is Chrome then one of the above extensions is required, or CloudAPAuthEnabled is turned on for Chrome 111 or later.

Login is now in a seperate browser – but login works fine.

Photo by Pixabay from Pexels: https://www.pexels.com/photo/architecture-art-artwork-bench-206784/