You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I used the -UseDeviceCode option for getting an access token, so I executed this: Get-AADIntAccessTokenForAzureCoreManagement -UseDeviceCode -Tenant 6e3846ee-e8ca-4609-a3ab-f405cfbd02cd -SaveToCache
Help us keep your device secure
Your sign-in was successful but your admin requires the device requesting access to be managed by Company Ltd. to access this resource.
I found this very strange, because when I initiated a device authorization grant flow with curl using the very same URL and POST body as used by Get-AccessTokenUsingDeviceCode, I got the expected success message:
Microsoft Office
You have signed in to the Microsoft Office application on your device. You may now close this window.
Eventually I've modified my local copy of AADInternals to use a debugging proxy (I prefer the Charles Web Debugging Proxy) with the Invoke-RestMethod calls in the Get-AccessTokenUsingDeviceCode function. As it turned out: the only difference between my successful attempts with curl and the unsuccessful attempts with AADInternals was the User-Agent. :o
The requests from AADInternals (via Windows 10 and PowerShell 5.1) use the following User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.1682
I tested the theory and added the following option to both Invoke-RestMethod calls in Get-AccessTokenUsingDeviceCode: -UserAgent "curl/7.68.0"
With this modification my device authentication flows via Get-AADIntAccessTokenForAzureCoreManagement -UseDeviceCode -Tenant 6e3846ee-e8ca-4609-a3ab-f405cfbd02cd -SaveToCache started to work, i.e. AzureAD gave a success message after I enter the user_code!
I'm not sure what AzureAD tenant configuration is the reason for this behaviour, but the error message that AAD gives here is total BS, since I'm pretty sure that curl is not a device managed by Company Ltd.. :D
P.S.: for the purposes of this GH issue I took the tenant ID and company name from the "Quest for guest access" blog post, but of course I used other values in my own tests. :-)
P.S.2: thanks for AADInternals! It is a great toolkit for investigating AzureAD internals. :-)
The text was updated successfully, but these errors were encountered:
Thanks for letting me know this! Conditional Access "Device platform" conditions are based on User-Agents, so probably related to that. Have you tried to run it from Cloud Shell or Mac?
No.
I've tried to run AADInternals with the latest PowerShell for Linux, but it didn't work.
I've tried the (at the time) latest PowerShell for Windows 10, but it didn't work either.
Finally I've settled on the old PowerShell 5.1 (that probably came as a default with Windows 10 itself), because that was the only PS that AADInternals seemed to work with.
I tried the instructions in the https://o365blog.com/post/quest_for_guest/ blog post with a guest account in one of our tenants.
I used the
-UseDeviceCode
option for getting an access token, so I executed this:Get-AADIntAccessTokenForAzureCoreManagement -UseDeviceCode -Tenant 6e3846ee-e8ca-4609-a3ab-f405cfbd02cd -SaveToCache
I opened the "https://microsoft.com/devicelogin" URL, entered the displayed user_code and I got the following response:
I found this very strange, because when I initiated a device authorization grant flow with
curl
using the very same URL and POST body as used byGet-AccessTokenUsingDeviceCode
, I got the expected success message:Eventually I've modified my local copy of AADInternals to use a debugging proxy (I prefer the Charles Web Debugging Proxy) with the
Invoke-RestMethod
calls in theGet-AccessTokenUsingDeviceCode
function. As it turned out: the only difference between my successful attempts withcurl
and the unsuccessful attempts with AADInternals was the User-Agent. :oThe requests from AADInternals (via Windows 10 and PowerShell 5.1) use the following User-Agent:
Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.1682
I tested the theory and added the following option to both
Invoke-RestMethod
calls inGet-AccessTokenUsingDeviceCode
:-UserAgent "curl/7.68.0"
With this modification my device authentication flows via
Get-AADIntAccessTokenForAzureCoreManagement -UseDeviceCode -Tenant 6e3846ee-e8ca-4609-a3ab-f405cfbd02cd -SaveToCache
started to work, i.e. AzureAD gave a success message after I enter the user_code!I'm not sure what AzureAD tenant configuration is the reason for this behaviour, but the error message that AAD gives here is total BS, since I'm pretty sure that
curl
is not a device managed by Company Ltd.. :DP.S.: for the purposes of this GH issue I took the tenant ID and company name from the "Quest for guest access" blog post, but of course I used other values in my own tests. :-)
P.S.2: thanks for AADInternals! It is a great toolkit for investigating AzureAD internals. :-)
The text was updated successfully, but these errors were encountered: