Closed muzso closed 7 months ago
Here's a sample screenshot from the error message with the default AADInternals code:
(Note: I've edited the page by replacing the company name and logo before I took the screenshot :-) )
Here's a sample screenshot from the successful result where a custom (curl) user-agent is used in AADInternals:
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?
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.
v0.9.x versions should work in other PowerShell versions too.
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. :-)