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.

                            Lister

                            Also, go to Admin Panel > Settings > Users > Settings and post a screenshot here.

                            Cheers.

                              Hi Kevin,

                              Below is the requested settings page.

                              I'm not sure what is sensitive and what isn't so I've played safe with redacting. If anything extra is needed let me know.




                                I think we too are facing this problem,

                                when using Azure AD for agent login we are then taken back to the home page of os ticket.

                                However the agent is actually logged in and if you re add /scp to the address bar they are logged in as normal.

                                Thanks
                                Ben

                                Lister

                                So with your settings the Users must exist in the system first before they can authenticate. So what I'm thinking is your attributes are not matching the user credentials of existing users. If you updated their backend and everything then it should be working unless the info we get back from MS does not match any existing user.

                                For Agents this is always true, they must always exist in the system before they can authenticate. As a quick test you can login as an Agent, if they get redirected to the homepage immediately navigate back to the login page by adding /scp to the domain name in the address bar and see if you see an error message in the login prompt box.

                                Do you also still have this applied?

                                Cheers.

                                    KevinTheJedi

                                    I've just logged in as an agent and then added /scp to the address bar, I get "authentication required" for the test user.

                                    To test the potential of the mismatch & restriction together blocking sign in I have also just changed "Registration Method" to "Public - anyone can register" for a short period of time and tested with a user who has not used osticket. This test was with the normal user "Sign in with azure" rather than agent. They also go back to the log in screen. I can see in azure the success message for this log in.

                                    I have applied that pull request, screenshot for the result is in post 5 of this thread.

                                    Thanks

                                        Lister

                                        Just wondering if you still had it applied as you were doing some other changes.

                                        Then I'm completely stumped without looking at your system itself and since I'm a core dev I'm unable to do so without you purchasing one of our support options.

                                        Cheers.

                                            KevinTheJedi

                                            Hi Kevin,

                                            No worries, I appreciate the help offered so far. I'll continue to test, might need to spin up a clean install & retest. We have looked at the support options previously, unfortunately as a school we have limited resources for IT on the finance front!

                                            In the meantime I'll go back to using LDAP. I may need to ask for some help on the forums again as we've recently started migrating things from LDAP to LDAPS following on from Microsofts recommendations & potential future enforcement. We've had trouble getting OSticket to accept LDAPS when two other products we use have switched over fine but I'll retest with the backend fix for ldap & ask in a separate thread if needed.

                                            Thanks

                                                Lister

                                                Hi,
                                                Please let me know if you find any resolution on topic : In Microsoft Oauth returning to homepage without user logged in. Thanks.

                                                  Write a Reply...