There MUST be something set for the staff user's password.
(If you have a lot of agents/staff, and you are comfortable with the database side, you can update table staff and set backend to NULL) You want that to be the default option, "-Use any available backend -". Under Manage Agent screen for each staff agent, there should be a section called "Authentication Backend" if you have the plugin installed correctly (which if it is working for the clients, you do).I was able to resolve it by doing a couple of things: I had the same issue: worked for clients, not for staff. Server: IIS 8.5 on Windows Server 2012 R2 This problem appears to be similar to #33 from 2014 ( #33) but that user's fix didn't work for us.
(We have the logging level set to DEBUG.) nor are any errors generated in the osTicket system log. I don't think it's an IIS configuration problem because client logins work fine through Kerberos. The staff still has to log in by manually typing their AD credentials into the web form at /scp/login.php. When staff logs in, we can see a Kerberos ticket generated in klist but the credentials are not passed through to the login. We can use klist to show that a Kerberos ticket is generated and there are no errors on login. When a client logs in, we verified that Kerberos is working and passes through the user's AD credentials. Both plugins work great on the client login, but auth-passthru is not working on the staff login.
#INSTALL OSTICKET ON WINDOWS SERVER 2012 INSTALL#
We just rolled out a new install of osTicket with the auth-passthru and auth-ldap plugins.
0 kommentar(er)
