It's not ideal for me to keep posting updates every day. Please follow the copious threads on here or follow our github repo for updates.
Cheers.
OAuth2 Microsoft Not Working
Someone I know pointed out that 1.17rc1 includes "modern authentication" https://github.com/osTicket/osTicket/releases/tag/v1.17-rc1. I'm not sure about the relationship of this effort to 1.17 but I'm hopeful we can either apply a fix to 1.16 or migrate to 1.17 in time.
@jerrycarlin do you have a question?
1.17-rc1 is a release candidate. It should not be used in a production environment.
I do not think that the feature o modern auth will be added to an old version as they do not usually backport features.
KevinTheJedi
I don't believe anyone was asking for daily updates. We are simply interested in learning information about this specific issue. Following "copious threads" and reading every update that has nothing to do with the update this thread is regarding Oauth, is far more work for a lot more people involved, than a 2 second message from a developer saying, "hey guys, we've got the Oauth working, go check out github."
That reply was towards someone else. I’m talking about posting daily updates on the RC/stable releases. People keep asking when we are going to release and we don’t have release dates and it’s not wise to post everyday “we are working on it”.
Cheers.
Everyone,
There is a new build labeled RC2 as well as a new build of the OAuth2 plugin. You will need RC2 AND the new build of the plugin to get all of the latest patches/fixes.
Cheers.
All, a quick guide on how to set up OAuth2 for Microsoft Users:
- Install the OAuth2 .phar plugin as you would any other plugin and be sure to Enable it. Do NOT Configure it from this screen (devs: You may want to either disallow the configuration from that screen OR allow users to select created entries under the mailboxes)
- Under E-Mails -> The E-Mail You Want To Update -> Remote Mailbox -> Authentication, change to OAuth2 - Microsoft
- Click on "Config," come up with a name (if not already populated), select "Enabled" (if not already), then hit the IdP Config tab.
- If you have not already done so, be sure to go into your Azure Active Directory setup (portal.azure.com) and Create a new "App Registration." (you might not have to do this but this is what I did and it worked). If you haven't, scroll down to see instructions (Microsoft App Registrations).
- Within Azure AD under the App Registration you created for osTicket, under the Overview tab, you'll need the following field to complete the setup:
Application (client) ID -> Client Id - Here's what you'll need to input for the following fields (if not already there):
Authorization Endpoint: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize
Token Endpoint: https://login.microsoftonline.com/organizations/oauth2/v2.0/token
Resource Details Endpoint: https://graph.microsoft.com/v1.0/me
Scopes: IMAP.AccessAsUser.All Mail.ReadWrite offline_access openid User.Read POP.AccessAsUser.All SMTP.Send - After gathering this data, you'll need the Client Secret that you captured earlier and input these into the boxes.
- Click on Submit. NOTE: If you run into issues authenticating, try using an In-Private Browser so you're not pre-logged into the account.
- After saving and if it works, when you go back into the configuration, you'll see a new tab that says "Token" with the token information.
** Microsoft App Registrations **
- Go to Azure Active Directory (aad.portal.azure.com)
- Click on App Registrations
- Select "New Registration"
- Come up with a name (e.g. osTicket) and select "Accoutns in any organizational directory (Any Azure AD directory - Multitenant)
- You can copy the Redirect URI from the OAuth2 Authorization screen if you have it open and selecting "Web" for the platform.
- Now that we have the app registered, go to API Permissions. Add the following permissions under Microsoft Graph:
- IMAP.AccessAsUser.All
- Mail.ReadWrite
- offline_access
- openid
- User.Read
- POP.AccessAsUser.All
- SMTP.Send
- After adding these permissions, click on "Grant admin consent"
- Next, go to Certificates & Secrets and click "New Client Secret"
- Come up with a name and select Expires -> 2 years (recommended)
- After you click "Add," be sure to capture the Value and save it somewhere safe as you'll need it later (KeePass, whatever you use to store confidential information)
So the good news is that the above instructions work in terms of saving successfully and generating a token. However, I'm getting an AUTHENTICATE failure. Happy to send over any logs that may help.
rblake
This happens because you generated the access token for Graph resource but Microsoft doesn't support tokens for multiple resources (Graph and Exchange in this case), see https://stackoverflow.com/a/61678485 (and my previous post about it https://forum.osticket.com/d/96893-basic-authentication-retirement-for-legacy-protocols-in-exchange-online/101)
And when using the outlook.office.com API, looks like there's still an issue with wrong attributes causing the Email Mismatch error: https://forum.osticket.com/d/96893-basic-authentication-retirement-for-legacy-protocols-in-exchange-online/70
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?
Did the setup as per rblake instructions, but also getting authentication failure when I use Graph API
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.
I dumped the actual response directly from MS.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.
- Edited
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?
You selected POP when I think you meant to select IMAP. No one really uses POP these days.
Cheers.
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.
