Help! Getting AADSTS530034 (unknown error!) - access blocked due to account risk - can't connect to customer tenants!

[sansbacher]

Hi folks! I've started experiencing a weird error - that is getting worse! - and the error doesn't seem to exist.

Starting Feb 3rd I started getting this error in my unattended scripts (which had been working fine until this point, and use the established Secure App Model to connect to customer tenants using Delegated Admin Privileges):

New-PartnerAccessToken : AADSTS530034: A delegated administrator was blocked from accessing the tenant due to account risk.

(Then it lists a Trace ID, Correlation ID, and Timestamp). It started with just 2 of our customers, then about 20, then 40, now over 50! Most fail getting the AzureAD and MS Graph tokens, many fail getting the Exch Online and Azure tokens (but a few fail only one or two but work for the others - not consistent).

The AADSTS530034 error does NOT even appear in Microsoft's list of possible error messages! I have searched these forums, Google, Bing, and the Partner-Center-PowerShell repo: no hits, not even one (Bing unhelpfully gives links to different errors). I suppose this page will show up now...

There's nothing common between the clients affected and not-affected. Most don't have AAD P2 - and we don't have AAD P2 - so no Risk-Based Identity Protection. No changes to Conditional Access Policies. I can't SEE anything in any of the clients, or in our tenancy, indicating some risky sign-in or condition. No "remember MFA" checkbox or anything.

This is starting to have a real impact as I can't run scripts to manage/monitor these customer tenancies. Has anyone seen this before? Have any ideas? I believe we have Advanced Support For Partners (ASfP) so that's my next avenue.

As I said, things have been working fine for ages. About 3 months ago I did change the account/UPN from my personal account to a more generic "O365Admin" account - which still has MFA, and all the correct permissions. Things have been working since. Yesterday I discovered in "O365 Cloud App Security" there was an Alert for "Unusual addition of credentials to an OAuth app" for our "Partner Center AAD App" (from when I switched from my personal account) and I marked it as okay. No difference. Everything still works fine when renewing Refresh Tokens, and it's been more than 90 days since I made the change, and some clients work 100%. Every day some that worked stop working. I can log into O365 with that admin account (I am prompted for MFA). If I check the JWT AccessToken (when it does work) I can confirm AMR contains 'mfa'.

The code I'm using is the same as I've been using since Dec 2019. I'm using the latest version of the PartnerCenter module (3.0.10). I can always connect to MY tenant to get the list of Customers (using my AzureAD Tenant ID). The problem is when I try to connect to my Customers' tenants (using their AAD Tenant ID) - for which I have Delegated Admin Privileges, and I've tried removing/re-adding them.

The following all cause the error for most clients:

$aadTok = New-PartnerAccessToken -ApplicationId $AzureADAppId -Credential $pcCreds -RefreshToken $refreshToken -Scopes "https://graph.windows.net/.default" -ServicePrincipal -Tenant $theCustomer.CustomerContextId

$graphTok = New-PartnerAccessToken -ApplicationId $AzureADAppId -Credential $pcCreds -RefreshToken $refreshToken -Scopes "https://graph.microsoft.com/.default" -ServicePrincipal -Tenant $theCustomer.CustomerContextId

$azureToken = New-PartnerAccessToken -ApplicationId $AzureADAppId -Credential $pcCreds -RefreshToken $refreshToken -Scopes 'https://management.azure.com/user_impersonation' -ServicePrincipal -Tenant $theCustomer.CustomerContextId

$exTok = New-PartnerAccessToken -Tenant $theCustomer.CustomerContextId -RefreshToken $ExchangeRefreshToken -Scopes "https://outlook.office365.com/.default" -ApplicationId "a0c73c16-a7e3-4564-9a95-2bdf47383716" 

$AzureADAppId is the ID of our AAD Partner Center Native App, $pcCreds has the Secret (which is not expired), $theCustomer.CustomerContextId is the Customer's TenantID, and of course the $RefreshToken is our big long refresh token, which is renewed weekly.

This works fine for SOME clients, but not others. If it failed for all I might believe something had expired, or I did something wrong, or someone had changed something. But it was failing for only 2, now over 50 of our customers. Adding -debug to New-PartnerAccessToken seems to imply that MSAL 4.8.1.0 MSAL.CoreCLR is getting back HTTP StatusCode 400: Bad Request.

Anyone have any ideas? Is ASfP the next best step? I'll also try posting an issue to the PS PowerShell Module repo.

Thanks for any help/ideas!

   --Saul

[JanoschUlmer]

@sansbacher : the answer is - because it was implemented now: February 2022 announcements - Partner Center | Microsoft Docs 😉

Not exactly sure myself, did not catch up with engineering on this, but I guess this is one of the many efforts surrounding GDAP release now.

[JanoschUlmer]

@sansbacher Detection of account risk sounds a bit like it could have been triggered by AzureAD Security Defaults, which incorporates AAD P2 features. 

Have you checked the tenants Risk Detections?

However, support might be a good option. Wonder if this is due to GDAP release, which happened on this day. 

I tested my scripts as well, I'm using the same approach, and have not found issues though.

[sansbacher · Accepted solution]

@JanoschUlmer - Thank you so much! You pointed me in the right direction once again!!

I checked and we don't have Security Defaults enabled (we have a few Conditional Access Policies) and none of the clients I checked had Sec Defs enabled either. Also none had any "Risk detections" listed that were relevant in any Customer Tenants.

BUT, under Risky users I found the 365 Admin account! (in OUR Tenancy) The last Risk Update was from Feb 2020 - which is so long ago I don't know why it started to become a problem now? Also, I swear that I looked there days ago when I was investigating this. I can only assume between having various tabs open to our AAD and Customer AAD's that I missed ours?

Anyway I checked off the account, and clicked "Dismiss users(s) risk" said "yes" and all was well after a few mins! See picture below.

I got there via: Azure Active Directory (OUR AAD, not Customers), Security, Risky users. I'll leave this post up in case anyone else runs into the error message.

I also updated the GitHub Issue I created for this.

Thanks again!!

   --Saul

[JanoschUlmer]

Interesting that this happens even without AAD Sec. Defaults on, thanks for updating this thread!

[sansbacher]

I'm also curious why this only started to be an issue now... the "risky behaviour" was nearly 2 years ago, and I started using this admin account 3 months ago. So why trigger something now? I can't see any logs from 2 years ago to even investigate what the problem was!

I confirmed that several scripts have successfully run through all of our Customers with no authentication problems.