dschuett
I had the same issue, after about 30 minutes with Microsoft it now seems to work. I had to remove consents then re-add consents in the azure panel then it stopped asking for admin rights.

      B0ydie I have a case open with Microsoft as I feel that I am having the same issue as you. I did remove/re-add consent first, but it didn't work.

          dschuett

          so evidently what worked was basically removing restrictions on azure then putting them back once its logged in. it is s security risk to a point. this is what MS sent me to fix it

          1. Log in to the Azure Active Directory admin center.
          2. Go to Enterprise applications > Consent and permissions > User consent settings.
          3. Under User consent for applications, select Allow user consent for apps

          then i put it back to normal after its logged in, once it has its keys it seemed to work

              dschuett

              not the best way of doing ti and I have reported it to MS but if it works it works.
              Has anyone manged to get SMTP send via ouath working? I added it to my scope etc but when i press save I get an authentication error. I'm also getting issues with cron (not having much luck)

                Here is my response from Microsoft. It does look like this is a bug on the osTicket side because offline_access is set to consent in the response from osTicket.

                My name is Treyce and I am with the Azure Enterprise App team and I am the senior engineer for Pooja and she has requested I take a look at this case.

                While looking at the Fiddler trace we see that the application in its Auth request is prompting for consent this request is from https://app.xxxx.com/support/api/auth/oauth2 even if Azure has admin consent granted if the service that sends the request prompting for consent it will always require consent even if consent is granted. You are going to want to reach out to developers of the application so they can remove that request.

                If you go to result 205 in the Fiddler we reach https://app.xxx.com/support/scp/emails.php?id=15&do=autho&bk=oauth2:msmail:7:10 and from we get redirected from this to https://login.microsoftonline.com/1beafdf1-de07-46b2-b25d-c5bbac9a0434/oauth2/v2.0/authorize?tenant=common&accessType=offline_access&prompt=consent&state=fec795f5dd1c9826af210bea61a44349&scope=offline_access%20https%3A%2F%2Foutlook.office.com%2FMail.ReadWrite&response_type=code&redirect_uri=https%3A%2F%2Fapp.xxx.com%2Fsupport%2Fapi%2Fauth%2Foauth2&client_id=3dbecd45-407a-4fc2-a906-21f2a3ae33c8 and in this redirect you can see the application is sending the promp=consent.

                  dschuett
                  This is spot on. In my environment, the application registration is configured with all the relevant rights, admin consent is granted, and our admin consent configuration should not require this application to have admin consent performed as all the permissions have been set to allow for user consent.

                  https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
                  The prompt field is optional, and as configured within osTicket, is forcing the consent dialog at each sign on attempt. I believe that the prompt=consent item needs to be removed.

                  https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#requesting-individual-user-consent
                  If consent doesn't exist for the user, or admin consent doesn't exist, a user will be prompted for consent after successful auth. This does not require the prompt parameter to be set.

                      bbour53

                      We are not going to remove it but make it optional later in the future. We have the consent prompt to verify and make sure you are authorizing the right email. For now, you can simply remove it if you don't want/need it but we will make it optional later on.

                      Cheers.

                          KevinTheJedi
                          I am an azure security administrator advising a user on setting up your application and do not have direct access or knowledge of your product. Could you elaborate on what you mean by "you can simply remove it" so that the user can configure your application properly for this use case?

                          EDIT: Found the settings in the oauth2.php file: https://github.com/osTicket/osTicket-plugins/blob/develop/auth-oauth2/oauth2.php

                          Note that if no administrator has performed admin consent for the application in the environment and users are permitted to perform consent for third party applications, they will still receive the consent prompt and confirmation of the email address without the prompt setting explicitly set. You may be better served using the prompt=login or prompt=select_account flags if that is your goal, not prompt=consent.

                              I'm not sure if i'm going about this correctly but under the concept of removing the line we don't need I have tried following the instructions from https://github.com/osTicket/osTicket-plugins but I'm having some issues.

                              I have downloaded the repo, successfully hydrated, then modified the oauth2.php to comment out line 640. I then ran the build command and it has given me an auth-oauth2.phar. I have copied this into my includes/plugin folder and successfully activated it in osTicket however when I then go to configure the authentication the popup box containing all the IDP info is just blank.

                                4 days later

                                I am experiencing the same issue as CPC

                                I have ensured the plugin entries in the DB were cleared when I attempted removing the plugin to reinstall it.

                                  For anyone else, TAS solved it.
                                  Delete associated email from system, readd.

                                    8 days later

                                    bbour53

                                    Good Afternoon,

                                    You mention that you found the settings in the oauth2.php file (I also was able to locate within the file), but would you mind expanding on how you made the change (if you were able to)?

                                        KevinTheJedi
                                        bbour53

                                        Hi,

                                        I can confirm that setting prompt=login was the only way to make the plugin work with our Azure environment, even with discretionary user consent enabled.

                                        Currently, it seems osTicket is unable to get an oAuth2 token from Azure as long as prompt=consent is used, as in Microsoft's implementation, this option is meant to require explicit/interactive admin approval for any new token issuance (see this link's last point). So unless I'm missing something, the current version of the plugin is unusable with Azure.

                                        Setting prompt=login does fix this issue, while still enforcing user login to avoid using the wrong account. is it possible to push this change upstream in the plugin repository to avoid dealing with manual mods on future updates ?

                                              marinbernard-pep06

                                              Your statement is untrue. prompt=consent does work and will allow you to get a token. Maybe you have a different setup than most.

                                              Cheers.

                                                marinbernard-pep06
                                                Thanks, I must be missing something because I tried using the make.php to make a new phar file, but kept getting an error about an unsupported make function, despite the function being listed in /help so I kinda gave up trying to remake it.

                                                  8 days later

                                                  I can confirm that setting prompt=login was the only way to make the plugin work with our Azure environment, even with discretionary user consent enabled.

                                                  I couldn't find this option, could someone help from where I can make this change to give it a try?