Brain Blog > M365/Azure

Conditional Access policy for OneDrive SyncEngine instead of M365

Sepp Jeremiah Morris

• 3 min read
Conditional Access policy for OneDrive SyncEngine instead of M365

Most organisations block OneDrive syncing to non-corporate devices via the SharePoint admin center, using a policy based on the domain GUID. That works for domain-joined PCs, but it isn’t supported on non-domain-joined (e.g., AAD-joined) corporate or workplace-joined devices. Microsoft suggests using a Conditional Access policy that targets Microsoft 365 cloud apps to block non-corporate devices, but for many environments, this current one included, that scope is too broad and the impact too high. So here’s what I did instead: I created a Conditional Access policy that targets the (hidden) OneDrive Sync Engine rather than all Microsoft 365 cloud apps. This comes much closer to the legacy option.

Error you get when domain GUID is set
Domain GUID setting in Sharepoint admin center

However, there is an easier way commented here. This includes deploying a registry key, which is easier to deploy:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\OneDrive
 
 Create key string:
 AADJMachineDomainGuid

screenshots source

Unhiding the OneDrive SyncEngine Client

In Enterprise Apps you usually can’t see the OneDrive Sync Engine service principal. The good news: in most Microsoft tenants you can unhide it by adding it with PowerShell. This is my go-to script I grabbed a while back:

# Requires Microsoft.Graph PowerShell
# Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes 'Application.ReadWrite.All'

$appId = 'ab9b8c07-8f02-4f72-87fa-80105867a763' # Client App ID for OneDrive Sync Engine

# Check if the service principal already exists
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if (-not $sp) {
    $sp = New-MgServicePrincipal -AppId $appId
    Write-Host "Created enterprise app (service principal):" $sp.DisplayName $sp.Id
} else {
    Write-Host "Enterprise app already exists:" $sp.DisplayName $($sp.Id)
}

Now that we’ve added it, it shows up as a target in our Conditional Access policy. The exact setup will vary by organisation:

And when a user triggers a block it starts looping and locking:

💡
I haven’t tested this thoroughly yet and the block is a bit quirky. Treat it as an alternative to the reg key. That said, if it were fully supported, it’d be safer than the domain-GUID reg key, since any client with the GUID could spoof it, whereas Conditional Access is enforced server-side and isn’t dependent on a client-set value.

Both aren't amazing options, choose wisely. But for now, fun and games.

Proost,