"The tenant for tenant guid ... does not exist" when using client credentials flow (daemon) to access Microsoft Graph API

Question

I want to access Microsoft Graph periodically from a console application in order to copy messages from an Outlook mailbox to a database. In order to authenticate programmatically, I had to use the Microsoft Graph's "Client Credentials Flow".

These are the steps I had to take:

1. Register an App in the Azure portal and create a Client Secret for it.

2. Add all the permissions I need and grant them access:

   

3. Have an Admin confirm those permissions by accessing it for the first time. This is done using the following URL:

   https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
   ?client_id={app id}
   &state=1234
   &redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient
   &scope=https://graph.microsoft.com/.default
   

   I received the following response:

   admin_consent: True
   tenant: ca566779-1e7b-48e8-b52b-68**********
   state: 12345
   scope**: scope: https://graph.microsoft.com/User.Read https://graph.microsoft.com/.default
   

   (The scope might explain the problem described later here: Why do I only get User.Read when I've configured 13 different permissions??)

   

4. Get an access token (with success!):

   

5. Try to read users (with success):

   

6. Try to read my own emails (without success):

   

7. Try to read somebody else's emails (the user was invited to access the app as a guest, but still, no success):

   

I don't understand why I can't read Messages but I can read Users. It seems the permissions were completely ignored (I confirmed that I don't need any permission to read the users).

UPDATE

This is my tenant name:

These are the users added to the tenant:

Important: I don't own an office 365 subscription in my Azure AD. All these emails belong to a different AD.

The previous question "The tenant for tenant guid does not exist" even though user is listed on users endpoint? is similar to mine but I believe this is not a duplicate as my problem is slightly different and the proposed solution uses OAuth1 (I am using OAuth2).

Answer 1

Microsoft Graph can only access data within the tenant you have authenticated to. This means that you cannot access a mailbox from another tenant, even if that User is a guest in the tenant you authenticated to. Allowing this would violate the fundamental principle of data isolation in AAD/O365 tenants.

It is also important to note that AAD/O365 and Outlook.com are distinct platforms. Microsoft Graph's core value prop is a common API layer across AAD and MSA, but under the covers, they are calling into distinct backends.

Beyond data isolation and these being distinct platforms, Outlook.com simply does not support Application Permissions (Client Credentials). You can only access Outlook.com using delegated permissions, and even only a limited set of scopes are supported:

Not all permissions are valid for both Microsoft accounts and work or school accounts. You can check the Microsoft Account Supported column for each permission group to determine whether a specific permission is valid for Microsoft accounts, work or school accounts, or both.

With regards to which scopes are included, I suspect the issue here is that you don't have a license for O365 in this tenant. If it allowed you to consent without a subscription, this could (in theory) lead to apps unexpectedly receiving consent when/if a subscription got added later. That said, it is hard to tell without seeing an example of an actual token you're getting back (feel free to post one of you'd like me to look into this more).

Finally, juunas is also correct with regards to /me. The /me segment is an alias for "the currently authenticated user". Since you are not authenticating a user when you use Client Credentials, /me is effectively null.

Answer 2

/me won't work with a client credentials token. What would /me refer to? There is no user involved so it cannot mean anything.

For the second problem, does this user have an Exchange Online mailbox in your tenant?

Answer 3

The accepted answer is the one that helped me out. However, I ended-up testing what I needed to test joining the : Office 365 Developer Program (free)

This program will allow you to create an Azure Active Directory with up to 25 email accounts. It also allows you to create 16 fictitious email accounts with emails inside (by clicking one single button). You can use this infrastructure for 90 days for free.