Unable to renew Exchange Online PowerShell RefreshToken: Error AADSTS50078 trying to access 'SampleBECApp'
The error I'm getting is:
StatusCodeError: 400 -
"error_description":"AADSTS50078: Presented multi-factor authentication has expired due to policies configured by your administrator, you must refresh your multi-factor authentication to access 'SampleBECApp'.
Trace ID: 27735909-04ee-423f-906c-1d83eaa0bc00
Correlation ID: 250543c2-4ba2-4acc-bd25-13b7b1a97e53
Timestamp: 2020-02-02 20:48:47Z",
AADSTS50078: Presented multi-factor authentication has expired due to policies configured by your administrator, you must refresh your multi-factor authentication to access '00000002-0000-0ff1-ce00-000000000000'. Trace ID: 942769b9-1a92-4323-8762-4662b8253700 Correlation ID: 970ee2a0-48be-4541-a033-2d4cbd77769c Timestamp: 2020-02-06 18:55:56Z
What I'm trying to do: I have scheduled weekly task to renew my RefreshTokens for accessing Azure AD / Graph and ExchangeOnline PowerShell (originally created using Kelvin's script as per: https://www.microsoftpartnercommunity.com/t5/Secure-Application-Model/Exchange-Online-and-the-Secure-App-Model/m-p/15421/highlight/true#M125 ) because the RefreshTokens expire every day.
This worked well for about 30 days. Then about 2 weeks ago I started getting the first error (refererencing 'SampleBECApp').
I do the same thing for the Exch Online Refresh Token, except the headers reference Client ID = a0c73c16-a7e3-4564-9a95-2bdf47383716 (which is the well-known Client ID for ExO PowerShell). And I started getting the first error.
Thinking it was my process, I tried using PartnerCenter PowerShell's New-PartnerAccessToken cmdlet (again, using my Tenant ID and the last valid Refresh Token, and the ApplicationID = the well-known Client ID). And I got the second error.
I did some digging and reading (such as the AADSTS50076 thread). We DO have Conditional Access enabled, as we are trying Duo, and that's the only Policy - for the Duo test users. The Secuirty Defaults / Baseline Policies are not enabled. All users have MFA turned on for their accounts. The Azure AD MFA "multi-factor authentication service settings" page has "remember multi-factor authentication" enabled for 60 days, if that matters. But I find that I am prompted to re-MFA every 30 days anyway, which is about the time my script stopped working.
- So it seems like since I Consented originally, using my MFA account, and now 30 days later I'm being told my MFA has expired.
- Jasonch's comments in the other thread imply each RefreshToken exchanged for a new RefreshToken should have a new 90 day lifetime and you won't have to do MFA again.
EDIT to add: I've checked the AccessToken and they're "pwd" and "mfa" in the "amr" section. Also, while I can't renew the ExO PS RefreshToken, I can still USE it to connect to clients' ExO PS just fine, well for 60 more days...
Why can I renew the Azure AD / Graph Refresh Token but not the Exchange Online PowerShell Refresh Token?
I found this curious: if I use one of our customer/client TENANT-IDs in place of mine for in the URL to login.microsoftonline.com it works! And I can use the resulting RefreshToken to access other clients' Exch Online tenancies. It's like "my tenancy requires MFA, and it's been 30+ days since I did MFA so now I need to do MFA again because of our polices, but if I use a tenant of client to get a new RefreshToken, they policies apply - which doesn't have MFA enforced".
In fact: I have the Integration Sandbox set up as well, and it doesn't have any Policies, and it's working fine, even after 30 days.
What am I missing or what do I need to do? I want to have an unattended script that runs and renews my RefreshTokens, I don't want to have to re-do interactive MFA every 30 days, and I'd rather not use a client tenant ID if I don't have to. It works for AAD/Graph, just not Exchange Online PowerShell.
Thanks for your help!
Solved! Go to Solution.
@sansbacher : I have just talking to a colleague on this - and he mentioned something interesting - that really the setting you have set "remember MFA for 60 days" might cause this - since it will revoke the MFA token (Access token you are using to get a new refresh token).
So we would suggest that this setting is disabled. Or you can do the opposite test - set it to 1 day, maybe on friday evening, and check if the script fails until sunday - at least the impact to other users be minimal then.
And again I would like to add that shoot me an mail if this still doesn't work, the colleague I have talked to might be able to help further.
Not sure, but there are 2 things that are remarkable:
- MS Support stating that there was an extra consent needed in March/April, which is the period I consented for the last time
- We have been using different scripting to obtain the first RefreshToken, I used
$token = New-PartnerAccessToken -Module ExchangeOnline
$Exchangetoken = New-PartnerAccessToken -ApplicationId 'a0c73c16-a7e3-4564-9a95-2bdf47383716' -Scopes 'https://outlook.office365.com/.default' -Tenant 'myTenantDomain.com' -UseDeviceAuthentication
It might be that the "-UseDeviceAuthentication" flag that you used has a relation with the "remember MFA for X days" setting, because this setting is used for remembering MFA on trusted devices.
You said that you used this script because you needed to run it for access to your customers Exchange Online, but this is also possible with the "-Module ExchangeOnline" flag. The token you get is for the tenant from the user you have used in the next step to get the token. Apart from some special security-related functions you can do almost everything as delegated admin so you would not need to get a token for each customer.
Next, acquire your AccessToken and skip Basic Authentication by creating a credential object from the username and acquired accesstoken and then connect to Exchange Online with:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/?DelegatedOrg="contoso.onmicrosoft.com"&BasicAuthToOAuthConversion=true -Credential $credential -Authentication Basic -AllowRedirection
This is the way I connect and it still works fine after the first issues in the beginning of the year...
Hi @advdb1 ,
I don't think either of those constitute the problem:
-Module ExchangeOnline and -ApplicationId 'a0c73c16-a7e3-4564-9a95-2bdf47383716' are equivalent, the MS support tech confirmed that the 'a0c73...' GUID is the Well Known GUID for Exchange Online PowerShell. In fact if you look at the PartnerCenter PowerShell Module source, in Models\Authentications\PowerShellModule.cs it has:
private const string ExchangeOnlineApplicationId = "a0c73c16-a7e3-4564-9a95-2bdf47383716";
(and it also adds "https://outlook.office365.com/.default" to the scopes) The MS Tech told me that the -Module parameter was added later, as a convenience.
The MS Tech also didn't see a problem with using -UseDeviceAuthentication, which from looking at the source appears to also be the original experience to authenticate/consent, the new one being directly launching a browser window for you. But the end result is the same:
In Authenticators\DeviceCodeAuthenticator.cs and Authenticators\InteractiveUserAuthenticator.cs they both return: "An instance of "AuthenticationToken" that represents the access token generated as result of a successful authentication."
And I use the RefreshToken exactly as you describe: I use just that one Token to access all our clients/customers using Delegated Admin Permissions, creating the "Bearer AccessToken" for the $credential, and then a New-PSSession using the DelegatedOrg=customer.domain.com.
I don't know why my original Token (created before Jan 1st) stopped working in February (MS claims because they made a change on the back-end) but the new one was working since April until this month, but having disabled the "remember MFA" it is now working again - with no other changes. If it makes it to mid July then it will be over 90 days.
The only change I made was to disable "remember MFA" and it started working again. I don't know any more than that - but if I come across any other errors I will definitely report back!
Excluding this account from MFA would not achieve anything, since when accessing the end customer tenant with delegated admin credentials would require to use MFA regardless of what you are configuring (also the "remember MFA option" won't have an effect when accessing the end customers tenant).
I'm trying to seek for more help internally - could you summarize the whole solution here (or via mail) - so the full script you are using, how the token is refreshed, the version of ExO powershell modules etc.? The thread is unfortunately going on for a long time, and it is difficult to keep track on how your solution looks like exactly 🙂 I know, this is even more work, but it would help assessing where the problem might be.
Also I wonder since you regularly replace the old refresh token with the new one, how old was the new token you have been using? Usually we recommend replacing it more often - so not wait to the full extend of 90 days. So did you last time refresh the token successfully 52-60 days ago, or did the just refreshed token fail after a few days? But maybe I did understand your comment wrong...
Also, even though it seems to be tedious, please open a support ticket. You can also open a 2nd ticket to get an exception for the MFA requirement to access end customers, this may be a temporary relief: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-mandating-mfa#how-to-submit-a-request-for-technical-exception
Hi Saul and others!
I'm still waiting for my refreshtoken to expire. The token is refreshed at least 5 days a week so it should live until the secret is expired. Unfortunately I did not write down the day I created it, so I still have to guess how long the lifetime has been by now. However on May 5th my assumption was close to 2 months, so we should be at or over 3 months now.
Anyway, I created the first one with
$token = New-PartnerAccessToken -Module ExchangeOnline
and I am connecting from a .Net application using a WSManConnectionInfo object with a ShellUri ""http://schemas.microsoft.com/powershell/Microsoft.Exchange" for the connection to "https://outlook.office365.com/powershell-liveid/". With this connection I create a RunSpace. So I guess this is Exchange Online Powershell V1. Don't know if this can be done with the V2 set, but it sill works fine.
Hi @advdb1 ,
It was just 30 days this past weekend (the 9th) and all my Refresh Tokens renewed on the 10th without issue, which is great! I too will wait another 60 days and see if they continue to renew after a total of 90 days, and then put this matter to bed.
What did you end up doing? Recreating a new ExO Refresh Token from scratch, like I did?
(I've still not received approval for the CloudPartnerCommunity Yammer group, so I can't see your post)
If you hear of anything new, or if yours stops working let me know!
For @Lewis-H - yes, you can see many of the AAD errors here: https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes#aadsts-error-codes
But the error Advdb1 and I were getting (AADSTS50078) isn't listed
Hope you had a good weekend, stay well!
It's like we're living the same life...
This has never really been a problem overly for me because I actively Refresh the Exchange "Refresh" token every 28 days anyway and essentially re-consent.
Get this though, though that Refresh token works fine for 95% of the clients we are delegated for, for a few of them I still get this error:
"New-PartnerAccessToken : AADSTS50078: Presented multi-factor authentication has expired due to pop... "
Haha, the same cursed life! 😉
So you generate and manually (interactively) Consent to a new ExO Refresh Token every 28 days? Why?
It's valid for 90 days, and if you redeem it for an Access Token you get a new Refresh Token - another 90 days. So I renew mine every Sunday. My goal is to not have to manually/interactively Consent again - the whole point of Automation is to avoid manual intervention! 😀
[In December I'll have to generate a new Azure AD Native App client secret for the PartnerCenter access, which I can generate for 2 years, I'm okay with that]
I've also never had a problem with our clients, if I have Delegated Access working it works. The only time it doesn't it turns out they're a former client who has finally revoked our access.
I'm hoping all this gets pulled into some useful documentation at some point. Or maybe I should put it up somewhere. But I'm hoping MS irons out the bugs and updates all the modules and it all "just works"...
@sansbacher : With ASfP you have a dedicted service account manager (SAM) you can reach out to and open a cloud consult that will be handled with higher priority.
Btw, a response time of several weeks definitively not OK. I'm working in this team, and at least for the areas I support (Germany, Austria, Switzerland mainly - but not limited to) the SLA for an initial response of 1 day is met most of the times. It might take a bit longer to get a solution, but at least the initial response should have happened.
More info on ASfP: https://partner.microsoft.com/en-us/support/advanced-cloud-support