Refining My Azure-powered Workspace ONE Design

In recent weeks, I wrote an article about extending my 100% cloud design to Azure AD Join. I have to admit that I am continuing to learn more about how Azure AD join operates throughout the operating system. This has introduced some problematic design decisions. I wanted to take you on my journey by discussing Azure AD authentication, highlighting the problems that I have found, and how you can workaround it. This is going to be a bit of a working document that I will be updating as I learn more and I hope you will find it useful.

Azure AD Devices and Authentication

Azure AD can be quite complex when you start going down the world of authentication. Microsoft does a great job of layering transparency into their platform and making much of what they do seamless. Let’s start by discussing the difference between Azure AD Registered and Azure AD Joined.

Azure AD Registered vs. Azure AD Joined Devices

Primarily many of our devices are AAD Registered devices, but we do have AAD joined devices for all of our employees. You can see the main differences below between the models.

	Definition	Device Ownership	Provisioning	Sign-in Options	Key Capabilities
Azure AD Registered Devices	Registered with AAD without requiring org account to sign in to the device.	User or Org	Windows 10 Settings	User Credentials, Windows Hello, PIN, Biometrics	SSO to cloud resources, Sign-in with MSFT Authenticator, Conditional Access via Intune Enrollment or App Protection Policy
Azure AD Joined Devices	Joined only to AAD with an org account to sign into the device.	Org	OOBE, Autopilot, Bulk Enrollment	Org Accounts using Password, WHfB, FIDO 2.0	SSO to cloud and on-premise resources, Conditional Access through MDM enrollment and MDM compliance evaluation, self-service password reset and WHfB PIN reset on lock screen, Enterprise state roaming on devices.

My experience has been that devices that are Azure AD registered are far less problematic than Azure AD joined devices with Windows Hello for Business. Let’s discuss the issues that we run into with authentication on Azure AD joined devices.

How Authentication Works with Azure AD Join Devices

We tend to overlook how Office 365 authentication works with Azure AD joined devices. You see this screen all the time and think nothing of it. The biggest difference between Azure AD connected and Azure AD joined devices is that Azure AD join uses Azure AD to log into the machine and generates tokens by the time the device has logged in similar to Kerberos:

These accounts that are “Connected to Windows” are ACTUALLY the work account identities:

So here’s the kicker, when you log into Office 365 most of the time its leveraging cookies and making some magic happen. If you were to use SAML, it would actually be using X509/Multifactor to authenticate the device. Let’s move onto how we prepare Chrome to integrate with Azure AD.

Extending Azure AD Joined Devices to Google Chrome

Microsoft doesn’t do a great job marketing how you can extend Chromium to Azure AD, which I have learned. Let’s start with a quick PowerShell script to deploy the extension on Chrome:

$KeyPath = "HKLM:\Software\Policies\Google\Chrome\ExtensionInstallForcelist"
$KeyName = "2"
$KeyType = "String"
$KeyValue = "ggjhpefgjjfobnfoldnjipclpcfbgbhl;https://clients2.google.com/service/update2/crx"
if(!(Test-Path $KeyPath)) {
    try {
        #Create registry path
        New-Item -Path $KeyPath -ItemType RegistryKey -Force -ErrorAction Stop
    }
    catch {
        Write-Output "FAILED to create the registry path"
    }
}

#Verify if the registry key already exists
if(!((Get-ItemProperty $KeyPath).$KeyName)) {
    try {
        #Create registry key 
        New-ItemProperty -Path $KeyPath -Name $KeyName -PropertyType $KeyType -Value $KeyValue
    }
    catch {
        Write-Output "FAILED to create the registry key"
    }
    }

Essentially, the My Apps Secure Sign-in Extension you log into after its installed and it bridges your Azure identity into Chrome to deliver that seamless sign-in experience you know from Microsoft browsers:

The Problem that Azure 3rd Party IDPs Create

The most frustrating yet interesting that I have learned as of late is that using Azure as a 3rd party IDP is DRASTICALLY different than logging into Office 365. As I wrote in my other article, we setup Azure as a 3rd party IDP by creating an enterprise application and redirect our apps inside of WS1 Access to Azure to authenticate.

One of the main issues is when you click that “Connected to Windows” account it tries to use that certificate and multifactor-powered identity with SAML. You would expect this is passing your standard password context like this:

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>

However that connected identity happens in a very inconsistent fashion. If you try to use this SAML context in Chrome you get this error:

Similarly, Edge gives you an inconsistent error:

So, here’s the issue. We know that you cannot use the Password context for Chrome or Edge reliably. The ONLY work around you have is clicking on “Use another account” below. But the REAL issue is that Chrome will only work with Windows Integrated Authentication and Edge will only work with X509 authentication:

My Current Solution to Address the Azure Authentication Issues

At this juncture, my estimation is that the Chrome extension might have a bug complicating some of these issues. As you saw above, depending on the browser you use it will support different authentication methods. So I had to make a choice to punt on the Edge browser since my organization is Chrome-first. Let’s cover how I built out Azure’s IDP authentication methods. Basically, I created a password, x509, and windows integrated authentication auth method:

My Azure-Integrated authentication method is what we will deploy with the policy to fix this issue with Chrome at least at this juncture, which performs integrated authentication with this SAML context. The thing to point out is that WS1 Access is designed to send the AuthnContextClassRef attribute to Azure by design. This is a big part of the problem:

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>

My policy is created mindfully, with an AD group-scoped policy rule that uses the Azure-Integrated authentication method to address the issue:

Our Next Steps with Azure Authentication

We are still investigating a few other potential items to get more comfortable with this solution:

We are trying to run down the inconsistencies with authentication methods available between Chrome and Edge. I continue to work with Microsoft on that and hope to get clarification on that soon.
We are trying to find out if the WS1 Access team can disable the AuthnContextClassRef attribute so that is not passed back to Azure, which Microsoft has recommended to many companies with similar issues with Enterprise Apps

At this point, I’m semi-comfortable with the solution but overall Microsoft needs to improve the supportability for a normalish use case.

Finally a Fix

As I had hoped, VMware was able to provide a solution to the problem. Simply, by using this SAML context it will no longer send the AuthnContextClassRef in the SAML response:

Closing Thoughts

To my admission, this article is going to be a working document more than likely. The challenge with trying to be progressive and be an ACTUAL engineer/architect is fixing issues that you can’t Google. It’s an art form to see behavior and understand how your tech stack works to solve an issue. I live for the “challenge” and I hope you all do too!

HEADLINES:

HEADLINES:

Mobile Jon's Blog