AAD Publisher Verification: What You Need to Know!

What is the issue?

First of all, there are many apps out there, which do not meet the requirements. This includes large vendors, which should know better. Similar to the issue of not having a set X-AnchorMailbox header in requests as mentioned in my article EXCHANGE ONLINE MIGRATION: UNMENTIONED PITFALLS (PART 2) (there are still many vendors that have not yet implemented this!).

But it's not only 3^rd party vendors that are missing their verification: Microsoft is also not doing a good job, but as these apps are handled by Microsoft itself, they get a special treatment.

Besides the missing requirements, I want to highlight some facts, which are more related to the configuration and therefore important to you as an administrator.

Minimum permissions for classification

Microsoft mentioned this as a tip in their documentation in Manage permission classifications:

In fact, if you have not configured at least these permissions, users will receive this:

Here's an example:

I have the following permissions configured in my test tenant:

I am missing the permission email! Now I am requesting an auth code from AAD using the following PowerShell code:

As I am missing one required permission, I will see this:

After adding the missing permission to the classification, I can grant consent and can use the code for acquiring an access token.

Note: Don't get confused about the missing verification, as apps using one of the tenants configured domains can be granted consent without having them verified. But they follow the classifications!

Configure permissions explicitly!

If you configure permission like Mail.ReadWrite, do not expect that this includes Mail.Read! You really need to allow every permission, which should be allowed.

Here's an example:

As you can see in the previous screenshot, I configured to allow Mail.ReadWrite. Now I am trying to get a code requesting Mail.Read, which is in fact lower permission and you might to expect that this is included:

This result is the very same result as shown above:

To avoid this end-user experience, make sure you have added ALL permissions that you want your users to be able to grant consent for.

Conclusion

Bear in mind with these topics, when you configure and before you enable verified publisher, it depends on your setup and security concerns what you need to configure, but think about this:

Even when you configure a large number of permissions, these apps need to be verified and need to meet requirements. This might not prevent you from illicit consent, but it's still more secure than allowing users to consent to every app.

Active Directory Monitoring with ENow

Active Directory as the foundation of your network, and the structure that controls access to some of the most critical resources in your organization. ENow uncovers cracks in your Active Directory that can cause a security breach or poor end user experience. In particular, ENow enables you to: