When using device code authentication for PowerShell modules with conditional access you might receive prompts like: “Access has been blocked by Conditional Access policies. The access policy does not allow token issuance” or “AADSTS50097: Device authentication is required”. But what’s the reason for this error and is there a solution available?
Examples from the field
Device code flow is quite a convenient way to sign-in for an app within the web browser - at least if it works. If not you have to consider other options and that’s probably the reason why you’re reading this blog article.
Az PowerShell
Running the Az PowerShell module on PowerShell 7 uses device code flow to authenticate against your Azure tenant and might fail:
| |
The sign-in to Azure is tied to the “Microsoft Azure Management” app that you can select within Conditional Access.
Microsoft Graph PowerShell
The same applies for the new Microsoft.Graph PowerShell modules - but here we receive a more detailed error message:
| |
The sign-in to the new Microsoft Graph Modules is tied to the “Microsoft Graph PowerShell (Preview)” app and some more apps I couldn’t determine.
Possible cause
You will experience issues with device code flow if one or more conditions apply to your conditional access configuration:
- Unknown client app is blocked
- Device-based conditional access rule in place
- Require compliant device
- Require hybrid Azure AD joined device
If we have a closer look on the OAuth 2.0 device code flow and possible usage you will notice that the sign-in with the device code flow could be completed on another device like a smartphone or a computer than the device which initially initiated the sign-in / authorization process:
Original image is from Microsoft
So it’s by design that the device code flow cannot satisfy any device-based conditional access rules. Furthermore, device code flow falls into the “Unknown” client application section. The Azure AD identity platform simply doesn’t know if you’re signin-in for an app on your smart TV, IOT device or within PowerShell and about the device state.
Possible solutions
Of course workarounds exist to modify the Conditional Access configuration. But I wouldn’t recommend this because this affects your security posture - if you take the risk you could exclude the “Microsoft Azure Management” from your Conditional Access policy which blocks unknown clients / requires device state and still protect the sign-in with MFA.
A better approach is to use another OAuth 2.0 and OpenID connect flow like the delegated flow where you sign-in directly within the app. But that’s not always possible and limited by the support of the PowerShell module (Az modules currently do not support this).
Another workaround is to use an app registration (service principal) with client credentials like a certificate. Although this also comes with drawbacks in the area of security and maintainability based on the permissions you assign to the app.
To summarize you have the following options for the Az PowerShell module:
- Device Based Conditional Access and/or unknown client platforms blocked settings in place
- If you’re on PowerShell 7 -> Use a service principal
- If you’re on PowerShell 5.1 -> Sign-in should work as expected
Final words
So finger’s crossed that Microsoft will implement this one within their PowerShell modules and not only relies on options for device code flow and unattended access with app registrations (client credentials grant).
If you haven’t checked out I can recommend you the Microsoft Identity Platform overview for OAuth 2.0 and OpenID Connect flows:
OAuth 2.0 and OpenID Connect protocols on Microsoft identity platform