Client Device Not Passed Through with Azure AD Authentication

[Donovand4]

When using a Conditional Access policy to block all other devices (except for Android, iOS, Windows Phone, Windows and macOS), the policy blocks the connection with the below message because the authentication sign-in log has no device visible.

"Your sign-in was successful, but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app or location that is restricted by your admin."

It is possible to exclude the user who is initiating the request but that would allow non-supported devices from making Azure Connections using the Graph API. Which is not an option.
AB#7387

[Donovand4]

This appears to be related to the device-code OAuth Flow. Will this be remediated in the final release as it will be common for Conditional Access policies to block based on device.
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/require-managed-devices#known-behavior

[MIchaelMainer]

Can you provide the command and arguments that you are running?

[Donovand4]

Can you provide the command and arguments that you are running?

Hi Michael,
I am using connect-graph.

[nicolonsky]

@Donovand4 are you authenticating via device code (assuming a yes if you connect with the Connect-Graph cmdlet)? If you have a conditional access policy which requires a compliant or hybrid azure ad joined device this requirement can't be fulfilled. Same applies if you block the "unknown" client app platform with a conditional access policy. As a workaround, you could use client credentials, I've documented this here .

@MIchaelMainer any plans to support "regular" delegated authentication?

[Donovand4]

@Donovand4 are you authenticating via device code (assuming a yes if you connect with the Connect-Graph cmdlet)? If you have a conditional access policy which requires a compliant or hybrid azure ad joined device this requirement can't be fulfilled. Same applies if you block the "unknown" client app platform with a conditional access policy. As a workaround, you could use client credentials, I've documented this here .

@MIchaelMainer any plans to support "regular" delegated authentication?

[Donovand4]

@Donovand4 are you authenticating via device code (assuming a yes if you connect with the Connect-Graph cmdlet)? If you have a conditional access policy which requires a compliant or hybrid azure ad joined device this requirement can't be fulfilled. Same applies if you block the "unknown" client app platform with a conditional access policy. As a workaround, you could use client credentials, I've documented this here .
@MIchaelMainer any plans to support "regular" delegated authentication?

@nicolonsky , I would avoid using application permissions with a certificate that can be copied to other machines. That could put the tenant at risk, as any permissions granted to the application would be accessible when using the certificate. This would also bypass any conditional access policies created to block based on devices and I noticed that the sign-in is not registered in the sign-in logs so its not an option if you want to reduce risk.

[nicolonsky]

@Donovand4 totally agree for administrative tasks whereas for automation purposes this is the way to go. But the issue is tied to the nature of device code flow. Using OAuth On-Behalf-Of flow would resolve this.

[peombwa]

We added interactive authentication (browser pop-up) in 1.6.0 as our default authentication flow. You can use that instead to get around this issue. See #618