Microsoft Information Protection (MIP) does not work after 24.004.202xx planned update

[defaultdf1pf37yavbh]

Microsoft Purview Information Protection support in Acrobat

The feature works perfectly in version 24.003.20180, but updating Acrobat past that version we are getting an error:

AADSTS50011: The redirect URI 'acrobat2021.oauth2://miplogin' specified in the request does not match the redirect URIs configured in the application 97bd680b-f203-4917-a342-308a3de4094a     

checking Azure > Enterprise Applications, Adobe  Acrobat (application ID 97bd680b-f203-4917-a342-308a3de4094a) is configured with reply URL 'https://msmip.acrobat.com/authorize' 

 

We did a Fiddler trace with version 24.003.20180 and 24.004.20220.  The trace shows the redirect_uri in those versions are different.

Microsoft was originally contacted regarding this issue.  However, they were unable to assist as this application is owned by Adobe - The application owner would have to update the application redirect_url

 Has anyone else using this feature experienced this?

[S. S]

Hi @defaultdf1pf37yavbh,

Hope you are doing well. Sorry for the trouble.

It looks like the browser authentication is not set up for the workflow to follow through.

Would you mind trying the same and letting us know if it works?

Please refer to the Setup requirements for browser authentication in the MIP Workflow here: Microsoft Purview Information Protection support in Acrobat

Look forward to hearing from you.

-Souvik

[defaultdf1pf37yavbh]

The system has been configured in accordance with the document provided.

Further internal testing revealed the feature works in Acrobat version 24.003.20180, but was broken in all version after.

[defaultrsshphvq4oc6]

I am having the same exact problem:

In fact, I am also seeing that when I try to consent the Adobe Reader Enterprise App in Entra ID, I get redirected to msmip.reader.com, and as far as I can tell (though, I was surprised to find out) reader.com doesn't appear to be owned by Adobe:

Also notice that NSLOOKUP resolves for the Acrobat URL that you get redirected to when doing the same for the Adobe Acrobat (not Reader) Enterprise App consent process.

This is what reader.com resolves too:

And.. Entra ID logs effectively say the same thing that original poster called out in their Fiddler trace.. which is that the installed app is presenting the incorrect information to the Enteprirse App, and that this is a developer issue:

Please help!

[defaultrsshphvq4oc6]

Hello - any update on this?

[philj25466186]

I just noticed I am having the same issue today.

[shaktikeshri]

Hi @defaultdf1pf37yavbh , @defaultrsshphvq4oc6 , @philj25466186 

Sorry for the inconvenience caused to you. We'll further investigate the issue at our end and update you at the earliest. Please upload diagnostic logs for the issue. Diagnostic logs can be taken as per https://helpx.adobe.com/in/acrobat/kb/acrobat-diagnostics.html 

You can share the log ID with us here. 

Thanks,

Shakti K 

[Pawan27574148e8ve · Accepted solution]

Hello,

This seems related to browser authentication, which was turned on for some users recently.

Please try the following steps:

1.  In Acrobat or Reader,  clear the saved account credentials and Exit Acrobat/Reader 

Preferences-->Security-->Microsoft Purview Information Protection-->Clear remembered account information

2.  Turn off browser authentication by instructions at link: https://helpx.adobe.com/in/enterprise/kb/mpip-support-acrobat.html#setup-requirements-browser-auth .   

3. For Reader we can use 

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Reader\Trunk\FeatureLockDown
• Name: bMIPExternalAuthAdmin   Value: 0

3.  As we would soon make Browser Authentication default, please share fiddler logs to investigate this further .   Refer “how to download Fiddler logs” on link.

[defaultrsshphvq4oc6]

I can confirm to anyone who runs into this that the above resolution is the path to take. I was under the impression by the initial post that indicated we should configure Browser Authentication that it needed to be "Enabled", but I can validate that marking this to "Disabled" fixed us up. Thanks!

[defaultdf1pf37yavbh]

I tried changing the setting as you described and this did not change the symptoms.

This issue has to do with O365 user logging into the "Adobe Acrobat" Enterprise Application in Azure - specifically application ID "97bd680b-f203-4917-a342-308a3de4094a"

from the above, we can see the reredirect URI in the request from the application (Adobe Desktop App) is acrobat2021.ouauth2://miplogin

and we can see from the below, the reply URL configured in the  Enterprise Application (Azure) is "https://msmip.acrobat.com/authorize"

If you follow the link provided in the error, it sends you to a Microsoft document that explains how to resolve this issue - basically, by updating the enterprise application reply URL

Error AADSTS50011 the redirect URI does not match the redirect URIs configured for the application |...

Unfortunately, the application cannot be updated by anyone but the owner, in this case Adobe.

We opened a case with Microsoft that confirmed there is nothing they can do and the issue must be resolved by Adobe.

We have had a case opened with Adobe since before Christmas and the issue hasnt been resolved.

This worked fine in version 24.003.20180.  And if I roll back our Adobe version to this version, it will work again.

This feature does not work in version 24.004.20220 and above, to include the newest release 24.005.20390

[Pawan27574148e8ve]

Hello,

We have registered both redirect-uris with Acrobat app ( "https://msmip.acrobat.com/authorize" and acrobat2021.oauth2://miplogin). 

Please share fiddler log for your issue ( Refer “how to download Fiddler logs” on link)

Also the registry for Acrobat would be slightly different:

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown
• Name: bMIPExternalAuthAdmin   Value: 0
•  

[defaultdf1pf37yavbh]

I attempted again, but it did not work.  We are in the GCC-H (government community cloud - high) environment within Office365/Azure.

Unfortunately, I cannot share the fiddler trace here in this forum, can you access the case?  

Case number is ADB-37562466-V7P0

The fiddler trace in the case is somewhat old, perhaps 2 weeks or so.  I will prepare another if this is an option.  

alternatively, I can share individual screen shots like the original ones posted - redacted of course.

I was able to look at the application in Azure commercial, and it seems like the url is the new one

however, the one from GCC-H is still the old one.

[Pawan27574148e8ve]

Thanks @defaultdf1pf37yavbh .  Let me check our setup for GCC-High cloud.

I understand that you are seeing Azure GCC-H App setting on  portal.azure.us . If that is not the case, let me know.

I believe that you should be able to use the registry in my previous comment, to go back to old redir-url.

[defaultdf1pf37yavbh]

good news.  It is now working.  Thank you!

yes, we are in GGC-H  - portal.azure.us

I updated the application to the latest (24.005.20399), and set BOTH registry keys

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\Trunk\FeatureLockDown

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown
• Name: bMIPExternalAuthAdmin   Value: 0

It may have worked before but I overlooked the fact there were two registry keys that needed to be changed.

I originally changed just "trunk" from the post on the 27th, and didn't realize your post this morning had "DC".  Anyway, with both configured, it works again.

a fiddler trace confirms that the redirect_uri is the old one configured in the Azure Enterprise Application

[philj25466186]

I’m going to check this out tomorrow. Thanks!

Get Outlook for iOS<>
CONFIDENTIALITY NOTICE: This message and the accompanying documents (if any) are intended only for the use of the individual or entity to which they are addressed and may contain information that is privileged, confidential, or exempt from disclosure under applicable law. Any interception, review, transmission, copying, dissemination, or other use, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited. It is the responsibility of the recipient to ensure that this message is virus free and no responsibility is accepted by the sender for any loss or damage arising if such a virus or defect exists. If you have received this message in error, please forward it to the sender and delete it completely from your computer system.

[Pawan27574148e8ve]

Hello @defaultdf1pf37yavbh ,

Thanks for confirming that the suggested  registry fixes the issue. 

From the screenshot shared by you on Jan 30,2025, 

This page seems to be the Admin consent page on your Azure tenant.  This consent has our old redir-uri  https://msmip.acrobat.com/authorize  that was used for in-app authentication.  For browser based authentication, we have added new redir-uri “acrobat2021.oauth2//miplogin/”  that is not updated in the admin consent above.  Can you update admin consent for your tenant to include both old and new redir uris.  You can refer the link https://learn.microsoft.com/en-us/skype-sdk/trusted-application-api/docs/tenantadminconsent to do this. The client id would be same as present: 97bd680b-f203-4917-a342-308a3de4094a 

[jim_54321]

Hi @Pawan27574148e8ve - could you elaborate on how to complete the consent?  following the article you posted, it has references to a resource, which contains information specific for Skype. I tried to omit that, but the page gives an error stating that the 'redirect uri must be an absolute value'.  any help would be appreciated

thanks!

[Pawan27574148e8ve]

Hi @jim_54321 ,

Please try the url below (it has small modification to redir-uri part):

https://login.windows.net/common/oauth2/authorize?response_type=id_token&client_id=97bd680b-f203-4917-a342-308a3de4094a&redirect_uri=acrobat2021.oauth2%3A%2F%2Fmiplogin&response_mode=form_post&nonce=a4014117-28aa-47ec-abfb-f377be1d3cf5&resource=https://noammeetings.resources.lync.com&prompt=admin_consent

Also you can find other ways to  give consent  at following link ( Refer the section Adiminstrator Consent Flow)

https://techcommunity.microsoft.com/blog/microsoft-security-blog/consent-flows-for-applications-inte...

[jim_54321]

Thanks,  I will try this.. but I am still confused why we are including 

&resource=https://noammeetings.resources.lync.com

when that specifically is for LYNC. should there be something else? or can this be omitted? 

[Pawan27574148e8ve]

Hi @jim_54321 ,

Yes we can omit  &resource=https://noammeetings.resources.lync.com

[jim_54321]

Hi @Pawan27574148e8ve 

Thanks for your help. Question: We are actually dealing with Adobe Acrobat Reader.  What would be the consent link for Adobe Acrobat Reader?

Thanks

[Pawan27574148e8ve]

Hi  @jim_54321 ,

Please try following link: 

https://login.windows.net/common/oauth2/authorize?response_type=id_token&client_id=cad2910c-3b55-461...

[philj25466186]

Do you have an admin consent link by chance for GCC High tenants?

[Muhammad_Sameer8068]

Microsoft Information Protection (MIP) failing after the 24.004.202xx update is a known issue in Acrobat. The fix: clear saved account credentials in Acrobat or Reader (via Preferences → Security), then completely exit and restart the app. This often restores proper MIP functionality.

[philj25466186]

Do you have any other thoughts or solutions? That method didn't work for us. I have 4 users who had tried opening up a document with the sensitivity label, and two of us can access no problem, however the other two users get the redirect error message. We are in the Microsoft GCC High tenant. We tried deleting the app in Entra as well, and I was able to do the admin consent with no issues, but it doesn't work for the other users.