jerer

In the outlook accounts we’ve tested the attributes are indeed correct so maybe we’ll do some rethinking and allow the attributes to be editable.

Cheers.

    jerer I deployed 1.17 RC2 in my environment. I get authentication error when I use Graph API and email mismatch error when I use outlook.office.com.

    Does this mean RC2 is still not working for M365 modern authentication?

    KevinTheJedi

    Are you sure you just don't have the attributes cached in the DB or something, I have tested this with a personal outlook.com and my work account but there is no difference.

    Personal:

    Work:

    But anyway, making the attributes configurable solves this (and isn't it needed anyway for other OAuth providers).

    Also I would still like to emphasize that in my opinion using the deprecated API with this is a bad idea. In couple months people kind of have to deal with this again. Easy future proof solution would be just making the API optional, since it just used to validate the email address which is not really needed for IMAP/POP/SMTP (I understand getting the users info is needed in other cases). Better solution would be to add support for Graph, which unfortunately requires another access token.

    Of course that can be easily worked around (for example with a mockup API), but that's not very user friendly.

      jerer

      Oh, I'm sure 😉 I dumped the actual response directly from MS.

      Cheers.

      I've followed the above instructions, however when I go to save the config, I get a 404 . The url It's going to is

      https://myurl.com/api/oath2?code= Followed by a long alphanumeric code. Is this something up with like the redirect uri?

      Also to note, if relevant, our system is not exposed on the internet, so this url is only available on premise. I don't think that matters though.

        I've managed to sucessfully create a token but when I try to enable the mailbox an error is displayed but no actual error text.

        is there a way to find out what the fault might be?

          Andy_B

          You selected POP when I think you meant to select IMAP. No one really uses POP these days.

          Cheers.

          @jerer

          Also, the default URLs we provide are just suggestions. You can change them to whatever you want at anytime and re-request a token.

          You can actually edit the attributes via the instance as you've mentioned but we will make them editable on the email config as well (coming in a later update). I just tested the attributes with the graph user URL as well and it still gives me mail as the attribute. So, maybe just a difference with account types, etc.; nothing is being cached on my end.

          Cheers.

            rblake

            Do you have to "grant admin consent" if you are adding delegated API permissions? All of the permissions I have added have stated that I do not need that option. Or did you add those permissions as Application permissions and not Delegated permissions?

              KevinTheJedi

              With Graph API the mail attribute would be correct. Unfortunately we can't use that API. I would like to know how you are getting that attribute with https://outlook.office.com/api/v2.0/me 😃

              There are couple bugs with the OAuth2 instance/email settings:

              • If you have a valid token, making changes to email/oauth2 settings doesn't trigger re-authorization.
              • Editing the attributes via the instance doesn't work at the moment, these gets overwritten back to defaults when you save email/oauth settings.

              RevAdmin You have to "grant admin consent" unless your tenant has "user consent" allowed for all applications/permissions (which you absolutely should not have for security reasons): https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent?tabs=azure-portal

              I am getting the same error AUTHENTICATE failed, I have confirmed I received the token from Azure, and can see the successful sign-in in Azure. Any solutions for this?

              I feel so stupid. I dug into the log files in Azure to figure out why the hell this account was not being added.

              I was using the client secret's ID, not the actual value. 4 years into a sysadmin role and I am embarassed lol.

              Everything is working as far as I can tell right now and I didn't even have to "grant admin consent!" I'm going to test a little bit and write some steps up since I configured my Azure OAuth app a bit differently than above.

                nerdyviking88

                I see you are using the default /common/ urls where you need to change those to the urls with your /tenant-id/ or /organizations/ in them. If you go to App Registrations (or Enterprise Applications - can’t remember off the top of my head), click on the app, and click Endpoints at the top you should see the correct endpoints to use.

                Cheers.

                  KevinTheJedi

                  Updated those to remove the 'common/ and put in our tenant ID. No change. I save, submit, it redirects to a 404.

                  EDIT:

                  I attempted to load up my url we're using as a callback endpoint, the https://url.com/api/auth/oauth2 . I get a 404. If I go into my root apache directory and open the api folder, I see no auth folder, nor oauth2. This is a fresh install, so I may be missing something or screwed something up.

                    KevinTheJedi

                    Well that definately did something. Now getting the following message:

                    array ( 'code' => 'InvalidAudience', 'message' => 'The audience claim value is invalid \'aud\'.', 'innerError' => array ( 'oAuthEventOperationId' => 'd5f3e02e-68f0-46b2-af33-6b6ec98807ce', 'oAuthEventcV' => '9u7DvOydWvDsiE6wCe89Zg.1.1', 'errorUrl' => 'https://aka.ms/autherrors#error-InvalidResource', 'requestId' => 'bcc3eef6-9dec-f05a-ec88-4eb009ef3d66', 'date' => '2022-08-03T21:23:06', ), )