OAuth2 Microsoft Not Working
mangoo Also, had to do this to enable SMTP:
Use the Microsoft 365 admin center to enable or disable SMTP AUTH on specific mailboxes
Open the Microsoft 365 admin center and go to Users > Active users.
Select the user, and in the flyout that appears, click Mail.
In the Email apps section, click Manage email apps.
Verify the Authenticated SMTP setting: unchecked = disabled, checked = enabled.
When you're finished, click Save changes.Otherwise, was getting:
5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. Visit https://aka.ms/smtp_auth_disabled for more information. [AM5PR0502CA0017.eurprd05.prod.outlook.com]
Just following up on this after the weekend. I am no IIS guru, but I did stumble upon the "configuration search" tool in the Configuration Editor and gathered the screenshot below. This appears to show that it is using the web.config shipped with OsTicket, but my attempts to learn how to verify this have not yielded anything to this point.
Hi Kevin,
Appreciate the time you're taking here! I'm getting the issue where it appears I've successfully logged in (indeed, that's what the AAD logs say), but on the redirect with the token (.../api/auth/oauth2?code=0.AXQAR4n2dbeGy0mhH85OSahebLL3...) I end up at an nginx 404 page.
So, not an AAD issue; however, I am running osTicket in an Azure WebApp... Using the supplied web.config, App Service logs showing stuff like:
2022-10-24T17:45:28.614356442Z NOTICE: PHP message: PHP Deprecated: Return type of CachedResultSet::offsetSet($a, $b) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 1754
2022-10-24T17:45:28.642531468Z NOTICE: PHP message: PHP Deprecated: Return type of CachedResultSet::offsetUnset($a) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 1751
2022-10-24T17:45:28.642629669Z NOTICE: PHP message: PHP Deprecated: Return type of ModelInstanceManager::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2002
2022-10-24T17:45:28.642641569Z NOTICE: PHP message: PHP Deprecated: Return type of CallbackSimpleIterator::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2046
2022-10-24T17:45:28.642655270Z NOTICE: PHP message: PHP Deprecated: Return type of CallbackSimpleIterator::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2051
2022-10-24T17:45:28.642664670Z NOTICE: PHP message: PHP Deprecated: Return type of CallbackSimpleIterator::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2036
2022-10-24T17:45:28.642673270Z NOTICE: PHP message: PHP Deprecated: Return type of CallbackSimpleIterator::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2040
2022-10-24T17:45:28.642682770Z NOTICE: PHP message: PHP Deprecated: Return type of CallbackSimpleIterator::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2031
2022-10-24T17:45:28.642693670Z NOTICE: PHP message: PHP Deprecated: Return type of FlatArrayIterator::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2076
2022-10-24T17:45:28.642702970Z NOTICE: PHP message: PHP Deprecated: Return type of HashArrayIterator::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.orm.php on line 2099
2022-10-24T17:45:28.642727470Z NOTICE: PHP message: PHP Deprecated: Return type of BaseMessageStorage::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/site/wwwroot/include/class.message.php on line 186
Any thoughts on this? I'm no PHP guy, so any guidance appreciated.
Should be, yet no dice. Are you able to confirm what the URL should come back as for a working instance? I can only get it to redirect to the portal without changing how the rule is written.
The URL should be correct it's just your webserver is not rewriting the URL to match. Once it's rewritten it should have http.php in between /api/ and /auth/ so /api/http.php/auth/oauth2?blah_blah.
Cheers.
Thanks, just trying to keep myself from going down the wrong rabbit holes.
Thank you again for your patience. It ended up being the YOURLs rewrite rule I had referenced prior had priority and had a wider scope, thus matching the redirect URI. Sending that URL rewrite rule to the bottom so that the API rule is processed first did indeed solve my issue.
So, of course, Azure Web Apps running Linux/PHP don't use the web.config file, and have recently started using nginx as the webserver technology... I don't suppose anyone has the rewrite rules specified in the web.config in nginx format?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
<rewrite>
<rules>
<rule name="HTTP api" stopProcessing="true">
<match url="^(.*/)?api/(.*)$" ignoreCase="true"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile"
ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory"
ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="{R:1}api/http.php/{R:2}"/>
</rule>
<rule name="Site pages" stopProcessing="true">
<match url="^(.*/)?pages/(.*)$" ignoreCase="true"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile"
ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory"
ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="{R:1}pages/index.php/{R:2}"/>
</rule>
<rule name="Staff applications" stopProcessing="true">
<match url="^(.*/)?scp/apps/(.*)$" ignoreCase="true"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile"
ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory"
ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="{R:1}scp/apps/dispatcher.php/{R:2}"/>
</rule>
</rules>
</rewrite>
<defaultDocument>
<files>
<remove value="index.php" />
<add value="index.php" />
</files>
</defaultDocument>
</system.webServer>
</configuration>Someone posted their NGINX config in one of the threads. You'll have to search around to find it.
Cheers.
I cannot for the life of me figure out how to make my test 365 email account be able to automatically consent to add the app when prompted. Every time I am prompted to submit for consent. And when I select "return to app" after requesting consent, it starts all over when I try again.
I even tried making app consent wide open for all users, and it still sent this up for admin consent. I have granted admin consent under the app config and in Enterprise Applications.
Can someone help me get over this hump - do I need to assign some admin role to the test user?
Just thought I'd throw my findings in the ring here. I updated OsTicket yesterday and setup the Oauth plugin. We had the issue where an agent signs in, and it redirects to the homepage. I knew it wasn't a problem with the setup as it worked fine for me, and at least one other agent, just not the rest. I checked the email fields matched up and was stumped otherwise. As a last resort, I went to assign the user a password so they could login locally. They were told they had maxed out their attempts so I thought I'd solved the issue! I changed the maximum attempt fields and the user then got an "Access denied" message. I went to the user account and changed it from "Use any available backend" to "Local authentication". User could sign in. Then I thought I wonder what happens if I change it to use "Microsoft" authentication, and then it worked!. The strange thing is, everyone is setup to "Use any available backend" and as I said, it works for at least 2 of us.
We previously used the LDAP plugin and whether this had some kind of effect on things, I don't know. It was disabled before I changed the authentication over anyway. Hopefully this might help other people who are in my position!
Chief_Slack
This might help, I had that issue, you have to give Application administrator to your support email address
https://howtohelpdesk.com/how-to-setup-oauth-on-osticket-using-microsoft-365/#allow-user-Consent
- Edited
Hi kevin thank you for all the effort you puts in this forum , i have a problem with enabling IMAP or POP 
For POP see the below pull:
You can either "upgrade" to 1.17.x as described here, make the changes manually, or wait for the next release (no set date).
Cheers.
KevinTheJedi
my dear thanks for your keep nagging for my issue , but because i have to deliver a working Ticketing system to my Management , everything works fine so far but only the mail fetching still not operational .
i already have the 1.17 release installed
You are using RC4 which has bugs and is not the "stable" release of v1.17. You will need to follow my instructions in my previous post.
Cheers.
Hi Kevin,
I'm having a similar issue with this. I am getting /api/auth/oauth2 rather than /api/http.php/auth/ when clicking "Sign in with Azure"
I've followed the wiki guide for setting up oauth for agent login & gone through this thread and others to try and make sure I haven't made a mistake anywhere.
The web server is apache with rewrite enabled. I've tested that rewrite does work by temporarily adding a different rule to the .htaccess in the api folder. The rule was a rewrite from api/foobar/ to www.example.com & that did trigger.
Azure is showing the log in attempts as successes.
Thanks for any help or guidance you may be able to provide.
You'll have to create your own thread with detailed info, screenshots, and steps. /api/auth/oauth2 is the correct URL.
Cheers.