An incredible number of tests fail, despite actual values matching recommended/expected values - "Access token is empty"?

[GeldHades27355]

81% of tests fail on our tenant. That is ... impossible. Checking the plain test results, I got this most of the time: { "error": { "code": "InvalidAuthenticationToken", "message": "Access token is empty.", "innerError": { "date": "2024-04-25T10:39:12", "request-id": "yyyyyyyyyyyyy", "client-request-id": "xxxxxxxxxxxxxxxx" } } }

This, despite authentication apparently working. At least, no errors were thrown.

For context: I'm using a global admin account with phishing-resistant MFA. I granted all the requested permissions, also on behalf of the org. Obviously, something still isn't authenticating right.

Ideas?

[merill]

Can you try running Disconnect-Maester and try with a fresh connection?

[GeldHades27355]

Same result - no change. I can't even see a pattern here. For example: Most Conditional Access policies are "failed", but a few are "passed". Specifically:

• MT.1006 is "passed" --> actually true
• MT.1009 is "failed" --> actually false (we do have CA to block legacy authentication)

Unless I'm mistaken (and I might be, I'm no graph expert), all CA policies are queried using the same graph permissions and API. Why would a few succeed and most fail?

EDIT: no, they're not the same permissions it seems.

[GeldHades27355]

OK, just went to graph explorer after connect-maester and tried querying [https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations('Fido2')](url) directly. Initially got an "access denied" not enough permissions or something like that.

I manually granted permission to policy.ReadWrite.AuthenticationMethod and now I am getting a meaningful (and accurate!) result: { "@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity", "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration", "@microsoft.graph.tips": "Use $select to choose only the properties your app needs, as this can lead to performance improvements. For example: GET policies/authenticationMethodsPolicy/authenticationMethodConfigurations('')?$select=excludeTargets,state", "id": "Fido2", "state": "enabled", "isSelfServiceRegistrationAllowed": true, "isAttestationEnforced": false, "defaultPasskeyProfile": null, "excludeTargets": [], "keyRestrictions": { "isEnforced": false, "enforcementType": "block", "aaGuids": [] }, "[email protected]": "https://graph.microsoft.com/beta/$metadata#policies/authenticationMethodsPolicy/authenticationMethodConfigurations('Fido2')/microsoft.graph.fido2AuthenticationMethodConfiguration/includeTargets", "includeTargets": [ { "targetType": "group", "id": "all_users", "isRegistrationRequired": false, "allowedPasskeyProfiles": [] } ], "passkeyProfiles": [] }

[GeldHades27355]

So whatever is happening, connect-maester doesn't appear to request sufficient access when I run it - but not for all resources, just for some.

[GuidoBaijense]

@GeldHades27355 What happens if you first use Connect-MgGraph instead of Connect-Maester? I had the same issue, but with PowerShell 7 and with connect-mggraph it works much better.

[GeldHades27355]

Nope - same result. Connect-mggraph appears to connect successfully, but still no change.

For comparison: we also use https://github.com/microsoft/Microsoft365DSC, which connects fine and is able to get accurate data through the graph. Mind you, I first had to manually run https://microsoft365dsc.com/user-guide/cmdlets/Update-M365DSCAllowedGraphScopes/ from that project once, apparently to grant permissions properly.

Does that help?

[GeldHades27355]

Just for fun, I ran export-m365dscconfiguration, along with all sign-ins etc. to see whether it'll straighten access to my tenant out - but I still get the same empty access tokens.

[MWestermark]

I'm facing the same issue as @GeldHades27355. A ton of failed tests which I know should pass.

[MWestermark]

I'm facing the same issue as @GeldHades27355. A ton of failed tests which I know should pass.

I now run the same setup and assessment with PS7 (instead of default) from a 2016 server and the output was totally as expected.

[GeldHades27355]

Thanks @MWestermark - I can confirm.

Running maester on PS7 and I get exactly the results I expect. (on W11 btw) Seems something is broken with PS5.

[nikkelly]

I was able to replicate this - definitely an issue with PowerShell 5

[merill]

Thanks for the confirmation. Will re-test in PS5.

[jarboed]

When I first tried running in 5.1 a bunch of tests failed, I think primarily due to the $tenantValue assignments ending in | Out-String -NoNewLine

The NoNewLine parameter was introduced with PS6.0

[f-bader]

Good finde @jarboed - I will test a different way of conversion to avoid such dependencies

[f-bader]

Fix is incoming. Will be part of the next release