"Grant admin consent" on company behalf appears to work at first but audit log reveals a failure

Question

I should stress that the problem has occurred consistently over multiple attempts over a week and on two tenants. Also, there's never an appearance of a problem when actually doing it, just later when you look into it because you're wondering why no one has access to the app (except me). Then you see the audit log and realize a definite problem.

I'm global admin.

The app (called Adobe Document Cloud, which is the one on the left):
https://documentcloud.adobe.com/o365pdf/start.html

The addition of the app works, but the "Deploy to all users" step (Adobe's terminology) ultimately does not, even though it appears to work at the time, and even when allowing 48 hours. That step is the same thing as going to Azure AD, Adobe Document Cloud, Permissions and selecting "Grant admin consent" (for company). It all looks normal to me there:
https://i.imgur.com/CnE9M2y.png

And it agrees with what was asked in the consent:
https://i.imgur.com/5l4pzgI.png

The error in the audit log (happens every time):
Activity Type: Add app role assignment grant to user
Category: UserManagement
Status: failure
Status reason: Microsoft.Online.DirectoryServices.UniqueKeyPropertyException
User-Agent: EvoSTS

Answer 1

Hi @rpodric ,

I understand that you are seeing the following audit log failure after granting admin consent:

Activity Type: Add app role assignment grant to user
Category: UserManagement
Status: failure
Status reason: Microsoft.Online.DirectoryServices.UniqueKeyPropertyException
User-Agent: EvoSTS

Usually this errors comes if we try to insert the duplicate records. To avoid this, we should avoid providing consent multiple times. Usually this occurs on the application side of things, and I would recommend reaching out to the app development team to get this resolved. I had a customer previously who faced the exact same error message when consenting to a different app, and the issue was resolved by the application vendor.

Here are a few additional things to try:

Review your permission classification to confirm which applications users can consent to, based on the app's requesting permissions

Verify that all of the permissions being requested from the application fall under "admin" and require admin consent

Capture a fiddler trace when reproducing the issue.

There was also a similar issue here where a user received the exact same error you are describing where the application developer hard coded text into the application's URL requiring admin consent ('&prompt=consent'), and the end user had to remove that code at the end of the URL. The user was able to use fiddler to capture the HTTPs traffic and confirm that the app was continuously requesting admin consent.

Let me know if this helps.

Thanks,

Marilee

Answer 2

I removed it and re-tried a couple days later, but it did the same thing after the admin consent phase (deploy to all users), so that should eliminate the multiple times idea given that this was starting over.

Adobe only accepts support contact from enterprise accounts, which we aren't, so that's not possible, though it would be shocking if a major app from a major company after all these months has a fundamental problem like this. I think that's unlikely, but I've tried their forum on the off chance that someone there knows, given that I can't contact support itself.

If anyone else has deployed the app, or can now, I'm all ears.

On the third idea, users aren't consenting. I'm consenting on their behalf.

On the fourth idea, I'm not sure I understand it. The app has certain permission requirements, so regardless of what they are, if I approve them that should work.

I think the last thing pertain to what a user would see if they actually got the app and then were inappropriately seeing permission prompts. I'm not getting nearly that far. Users never get the app, that's the problem.

Thanks

Answer 3

@rpodric - Interesting feedback.

I landed here whilst also looking for a solution based on a native PDF File handling issue I face in SPO, based on permissions.

I may be able to test and verify your findings with the app deployment, however, this is only worthwhile on my end if you are able to verify the behaviour of SPO when a call is made to access the file, and in particular via which URL (there are several options in given circumstances), and the outcome with the App in place.

My challenge is quite specific in that I have a limited permissions access group, that has explicit access to specific files (View Only). These users do not have access to the library/list, and thus other files residing in the library when the limited permissions are in play. If this isn't a factor and the permissions are (Read) for example, URL redirection takes place automatically for PDF files and they are served up in a browser session, or the Adobe browser plugin.

All other things being equal, this behaviour is only seen with PDF files! MS native files, .docx, .xslx, etc. do not exhibit such behaviour with the limited permissions in play, and none of the files exhibit the unwanted behaviour with Read permissions, which clearly points to SPO's inability to handle PDF calls in specific circumstances, as a result, it failed to redirect the call to the document hard-link (Document ID URL). Instead it lands the user in the Document Library/List URL, which of course returns a "no access" redirect. SPO Tenant support L1/L2 teams have no idea and are suggesting to revert to the MS Dev Team.