I started to bring this us in a seperate thread but was asked to split out into a new topic, so here I am!

I'm having an issue where when attempting to use oauth to allow agents to log in to OSTicket with AzureAD the user is sent back to the homepage of OS ticket without any of the indicators of being logged in as shown in the osticket documentation.

OsTicket info:

My plugin settings are as below:

Azure redirect:

The webserver is apache with rewrite enabled. I've verified this with a .htaccess file in the root & by temporarily altering the one in the api folder to redirect to the website www.example.com when /foobar/ & /api/foobar/ are put into the address bar, both worked fine.

I've tried to double check my work after following the OsTicket documentation for the plugin & the common problems I've seen posted on the forums including:

  • I've made sure the client secret is the value not the secret ID from azure.
  • First login is done by a global admin who grants permission to everyone. We have also gone into the enterprise application and clicked "grant admin consent"
  • Users are unable to grant consent themselves as we are a school & need to control access.
  • I Can see successful login attempts for user for the app in Azure logs.

If I've missed any information or more is needed please let me know.

    I am also facing the same issue.
    I have hosted Osticket on Windows IIS and using MySQL 5.5 database.
    Help to get a solution. Thanks

    Hi Kevin,

    Thanks for that, I'll give that a try and let you know either way. Forgot to add plugin info, currently on 0.6

    KevinTheJedi

    Unfortunately with the alterations suggested same problem occurs. Screenshot below just to check potential for layer 8 issue on my end.

        Lister

        What do the backend values look like for the users in the user_account table? Are you sure your attributes match the information in the users osTicket profiles?

        Cheers.

            KevinTheJedi I couldn't find user_account but I could find ost_staff.

            I'm altering the names & domain below to be fake examples but the convention used is the same.

            The user in OSticket both in web gui & database has the following:
            Firstname: John Surname: Smith email: jsmith@example.com username: jsmith

            In azure the userprincipal name would be: jsmith@example.com I did try changing the osticket username to match the UPN but I get an error from OSticket saying "username contains invalid characters."

            Firstname, last name & email fields fields in AzureAD match the firstname, lastname & email fields in OsTicket. The User Attributes mapping seams to be correct according to the graph documentation I'm reading from here: https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0

                Lister

                You should definitely have an ost_user_account table. If not then you have a deeper issue.

                Cheers.

                    KevinTheJedi

                    Apologies you are correct, did not notice the second page of tables!

                    In ost_user_account I've got one row with a username entered & the backend set to ldap.client. The account named here is set in the gui to use "Microsoft" authentication and is one of the two accounts I'm using for testing.

                    The rest are all null for the username but have backend set to ldap.client with the id & user_id fields populated for all of them.

                    We are currently using LDAP to authenticate but are trying to swap over to oauth.

                        Lister

                        ldap.client is wrong in any case. Set this User's backend to NULL and retest.

                        Cheers.

                          KevinTheJedi

                          Hi Kevin,

                          In the meantime we are still using LDAP for agent & end users to log in other than the two accounts we are using to try and get over to oauth. Thankfully agents can still log in with it and users 99% of the time use email anyway. If needed I can go through process in that link to get them access.

                          I have set the named user in "ost_user_account" to null in backend field and retested, same result. I have also changed what I believe is our second user to null (compared user_id found in another table) and same result. Its hard to be 100% sure as only 1 user in ost_user_account has a username field that isn't null.

                              Lister

                              Sign in as a completely new user that doesn’t exist in your helpdesk yet using OAuth2. Then go to the user account in the database and see what their backend is. Copy the backend value and update your user accounts backend to match and retest.

                              Cheers.

                                  For what it's worth, I was struggling with this as well and checking and re-checking every setting on my server but didn't realize it was on the Azure side. I guess I didn't copy the App secret correctly and that was causing the issue. I created a new secret and made sure it was copied exactly to the plugin instance config and it started working.

                                  KevinTheJedi

                                  Thanks for your continued help.

                                  I've created a new user in active directory & let them sync into azure. That user also goes back to the homepage after signing as a user. I've then added them as an agent through gui & tried signing in as agent through Azure, also goes back to the home screen. I cannot see this user in the ost_user_account or ost_user table.

                                  I can see in the ost_staff table after creating them the backend in that table is set to "oauth2.agent.p5i3". Copying this value to the test agents results in going back to the homepage.

                                      Lister

                                      The correct value for the ost_user_account.backend column should be similar to oauth2.agent.p5i3 but slightly different like oauth2.client.pXiX.

                                      Cheers.

                                          Lister

                                          Then you definitely have a misconfiguration or non-matching attributes or rewriting not working or something. Is Plugin ID 5 and Instance ID 3 actually the correct OAuth2 SSO instance that’s enabled for both agents and end-users?

                                          Cheers.

                                              KevinTheJedi


                                              Seams to be that the Plugin & Instance ID it created for the new user matches the tables as shown in screenshot above.
                                              I'm fairly confident on rewrite working, as I said in the first post I can get the .htaccess file in the api folder to react and redirect. If I purposefully misconfigure that file the webserver also gives a 500 error.

                                              The non matching attributes I can only go on what the defaults are - they appear to match the graph API. We are primarily on prem AD so azure is vanilla as Microsoft provided.

                                              I'll go through the configuration guide again on Monday to rule out layer 8 on my end.

                                                  Lister

                                                  Is there any way you can inspect the requests coming back to osTicket when authenticating with MS to see what attributes it's kicking back?

                                                  Cheers.