Outlook Connection/Redirection Error

[testrun1836]

Hello, and thank you for producing such a great tool.

Upon trying to open Outlook, I am presented with a page that says "Use the following link to open this mailbox with the best performance:"
Upon clicking the link provided, the connection times out.

I have previously been able to open Outlook in prior testing of other accounts. I am also able to access the rest of the tools without issue, changing access tokens and Client IDs as required.

How should I go about accessing Outlook in browser? Or if not possible with the account I am currently testing, would a custom Graph request to dump inbox be my alternative solution?

Thank you and I look forward to hearing back.

[RedByte1337]

Hmm, that's odd, I have not encountered that scenario yet when trying to access a mailbox through the cloud/office365-based Outlook application.
The only place where I have seen a similar message like this was when trying to sign in to the OWA sign-in page of an on-prem Exchange server with the credentials of an account that has a cloud mailbox, which would then redirect you to access the mailbox in the cloud directly. But that is not the case here of course.

Could you share the link that it displays? We might be able to get more information from that based on where it is trying to redirect you to. (If the link contains company information or user details which you don't want to share, feel free to substitute them with some placeholders like [email protected], etc).

[testrun1836]

Absolutely, and thank you for getting back to me.

The link is as follows: https://mail.example.com/owa/[email protected]

Then it redirects for a long while before ultimately closing the connection.

[RedByte1337]

Alright, so it seems like Office365 is trying to redirect you to the OWA page of an on-prem exchange server. So I guess in this case, the user's mailbox would still be hosted on-prem, and would need to be accessed from there.
I don't think there is any way to access mails from an on-prem exchange server using access tokens from Entra ID.

Apparently, there used to be an option where it was possible to request mails from both on-prem and cloud mailboxes using the MsGraph API, however, it seems like that was retired somewhere last year:

• https://techcommunity.microsoft.com/t5/exchange-team-blog/the-end-of-the-rest-api-for-on-premises-mailboxes-preview/ba-p/3221219

You can always try to see if you can still request any mails with custom MsGraph API requests either way. All you would need is an access token for https://graph.microsoft.com containing the scope mail.read or mail.readwrite. And with that you can try to list the messages in the mailbox of the user with a custom request to https://graph.microsoft.com/v1.0/me/messages as described here.

[testrun1836]

I think you are right. It appears to be on-premises and RESTAPI is not enabled

When I run the custom request (with the required access token and scopes), I get the following response

 {
    "error": {
        "code": "MailboxNotEnabledForRESTAPI",
        "message": "The mailbox is either inactive, soft-deleted, or is hosted on-premise."
    }
}

What would you advise?

[RedByte1337]

I think you are out of luck then. I don't think there is any way you will be able to get direct access to the mailbox by using access/refresh tokens from Entra ID if the mailbox is hosted on-prem.

So you will have to assess what other options you have and work with that instead. E.g. Does the user use other Office365 apps you can do something with (Microsoft Teams, SharePoint, OneDrive, ...)? You can enumerate information from Entra ID using the MsGraph API or the AAD Graph API (e.g. if it is a large organization with a lot of users, you can try some password spraying against all accounts which you can extract from Entra ID. Or check if there are mobile phone numbers linked to accounts which you can target through Vishing, etc...)

Depends on the scenario you are in and the scope of your assessment ofc, although the mailbox of this user will sadly be out of reach for you here if it is hosted on-prem.

[testrun1836]

I truly appreciate this guidance.

The outlook issue where the mailbox link never connects is quite confusing, considering that I am redirected to pages like "https://mail.example.com/owa/", and that several tokens I can produce have permissions like "EAS.AccessAsUser.All", "Ews.AccessAsUser.All", and "OWA.AccessAsUser.All"

Based on this combination of factors, I can imagine the cause of the connection problem being something else, not being hosted on-prem. Do you have any ideas?

One more question if you don't mind. For MFA methods, GraphSpy provides the following error message:
"[Error] Failed to obtain Available Authentication Info."

I am using the correct resource (MicrosoftAppAccessPanel)

Thank you and I will see what I can do ;)

[RedByte1337]

The /owa endpoint is a fairly common indicator of an on-prem Exchange Server. I'm fairly certain you will not be able to access that with access tokens issued by Entra ID, even without connection issues. Regardless of that, if the https://mail.example.com/owa/ website doesn't load, it might be that the on-prem exchange server is being decommissioned and not publicly accessible from the internet anymore for example. Try to see if you can access that website outside of GraphSpy in a new (incoginito) window. If it doesn't give any response, it probably doesn't exist anymore.

To access the MFA methods, you need to make sure that you are using the v2 API version to request the token, and then I usually use the following settings:

• Scope:
  • 0000000c-0000-0000-c000-000000000000/.default openid offline_access
• Client ID:
  • d3590ed6-52b3-4102-aeff-aad2292ab01c

You should then receive an access token with the resource (audience) of exactly 0000000c-0000-0000-c000-000000000000 (so not spn:0000000c-0000-0000-c000-000000000000, as that will not work).

You usually also need MFA claims to access that information. So in GraphSpy, check out the decoded token and see which values you have under the authentication methods (amr claim). It should contain something like this:

 "amr": [
        "pwd",
        "mfa"
    ]

If you have confirmed that all of that is correct, and you still get the error message [Error] Failed to obtain Available Authentication Info., then you can try to debug it further based on the error message that will be displayed in the GraphSpy console. If you could share the stack trace that is generated in the console output from GraphSpy when you receive that error message, I will be able to give some more information :)

[testrun1836]

Interesting. When I get the access token with the exact correct audience, the decoded token does not display "mfa" under amr.

It instead displays:

"amr": [
        "pwd"
    ],

The stack trace generated is:
[get_available_authentication_info():494] ERROR: Failed to obtain AvailableAuthenticationInfo. Received status code 401

Would requesting an ngcmfa claim produce a different result?
(I know the documentation discusses ngcmfa being necessary for FIDO keys, but any mfa would be sufficient.)

On the note of the possibility that the on-prem exchange server is being decommissioned, I can with certainty that I know the website is in existence and operating.

My current theory on my inability to access is geoblocking (based on my current location, the requested device login location, and/or the user recipient location, or VPN usage.
For illustration, user recipient is in country A, the device code request was for country B, and I am (currently, but not for long) in country C.

[RedByte1337]

Interesting. When I get the access token with the exact correct audience, the decoded token does not display "mfa" under amr.

Alright, then that seems to be the issue indeed. The user used single-factor authentication with only their password during the device code auth process. The fact that this is allowed is usually already a finding, especially if the device code was generated from a different country as you mentioned and not from a trusted location.

You can force the user to use MFA during the device code authentication by requesting the ngcmfa claim indeed. This should give you an access token with the claims pwd, mfa, and ngcmfa. That should allow you to see and change the MFA methods of the user. And if you are lucky, the company allows to use FIDO authentication, and then you can register your own FIDO key if you are quick enough (within the first 10-15 minutes of obtaining the access token with the ngcmfa claim). If not, you can still use the regular MFA claim for as long as you want to interact with the other MFA methods.