Maintain control of your Microsoft 365 data
Post Reply
DaStivi
Service Provider
Posts: 254
Liked: 35 times
Joined: Jun 30, 2015 9:13 am
Full Name: Stephan Lang
Location: Austria
Contact:

Case#07147127 - Using of Azure CLI against Microsoft Graph causing issues with Cond. Access

Post by DaStivi »

Hello,
VB365 is using of Azure CLI against Microsoft Graph and this can cause issues with certain Conditional Access Policys in EntraID (AzureAD)
after ah brief investigation i've identified some issues with the way how VB365 uses the Azure CLI with Microsoft Graph.
Having Conditional Access policys in place that includes all admin roles (global admin) and requireing to have hybrid-joined devices (or compliant) to secure the Admin access into Azure/Entra/M365 there is an issue that you can't use the device-login thats used upon tenant/company creation and when you use the restore wizards!

i've found allready some forums posts that also noted this but worked around somehow:
post504278.html
post462456.html

but this is not an option, i don't wan't to have M365 Admins to have weak security for login into all kind of Portals, instead i'd like to pinpoint the specific "Application" used and make it as secure as possible... this could mean that even if hybrid-joined devices or compliant devices is not an option, as this isn't supported with the device-based login method, i'd like to force MFA and propably only allow this from inside the company network (trusted network)!

the first Post also mention the MS Docs about that this specific scenario isn't supported https://learn.microsoft.com/en-us/entra ... ned-device
Require Microsoft Entra hybrid joined device
Organizations can choose to use the device identity as part of their Conditional Access policy. Organizations can require that devices are Microsoft Entra hybrid joined by using this checkbox. For more information about device identities, see What is a device identity?.

When you use the device-code OAuth flow, the required grant control for the managed device or a device state condition isn't supported. This is because the device that is performing authentication can't provide its device state to the device that is providing a code. Also, the device state in the token is locked to the device performing authentication. Use the Require multifactor authentication control instead.
microsoft recommend to exclude the "Windows Azure Service Management API" from such ah CA policy, and theoretically this would work.... MS says Azure CLI is ah subset of this API, but only when you call it against this "ressource"... according to the sign-in logs veeam calls the AzureCLI NOT against this API instead against the Graph API and this is not included in this Application.

https://learn.microsoft.com/en-us/entra ... gement-api

there is no possible way of of selecting this "Microsoft Graph" (App-id: 00000003-0000-0000-c000-000000000000)

there is ah "Graph Powershell Preview" App... propably it would be the better way to use this Graph Powershell instead of the AzureCLI?

if you hack this "Microsoft Graph" App-ID into ah cond.access Policy (you can do this by invoking ah webrequest directly to on the available apis to microsoft, you can create ah CA-policy thats even working and the VB365 device-code login is captured there! but this method has the huge downside that as soon as you view this unsupported-created policy in the web ui and hit save you'll overwrite the app-ids as they are not showed in the web portal!
https://call4cloud.nl/2020/11/the-condi ... xperiment/

trying this against the new graph API (pushing, modifing ah existing policy, or creating ah new one) Graph-API denies this process as it checks the app-id and tells me its not supported to add this First-party app ID to ah policy!

maybe there is also another way of making this login request, while i tested all the different scenarios i also tried to recreate the issues with the normal AzureCLI through Terminal App in Windows... this is also where i noted that this CLI "connects" to Azure (mgmt api) instead of the Graph API...

but i also tried using the AZ module, and this module is particual interessting as its using another "remote-signin" method, its not really the devicecode, its directly opening ah webbrowser session with ah specific redirect ("browser control") if this would not work, you could fallback to the device-login method with ah specific parameter when launching connect-azAccount

https://learn.microsoft.com/en-us/power ... entication

not entierly sure if veeam could authenticate its requets to the graph api this way, maybe this would also work? i might can test this also with the AZ command...
Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests