kevinoconnor7 / osTicket-auth-cas

JASIG CAS Authentication plugin for osTicket
GNU General Public License v2.0
13 stars 8 forks source link

CAS agent error #23

Closed rcf96 closed 4 years ago

rcf96 commented 4 years ago

I am currently having a similar issue to that of #13 where when trying to login with CAS for an agent I get the error message of "Have your administrator create a local account". I tried looking through the previous issues but the fix looks like he just updated his server. I can login just fine to the client page with CAS as it is connected with Active Directory. I have tried on a couple of different accounts that are in Active Directory with the correct privileges to login to the agent page but they all receive that error. The username and email address are all the same and it should be taking the email suffix properly. Let me know if you can help with a fix for this. I am currently running osTicket version 1.14.1 on php 7.3.

kevinoconnor7 commented 4 years ago

I'll preface this by saying that I haven't personally used this plugin in a real environment in quite a few years now so my memory may be a bit foggy on exactly how things work.

If I recall correctly, the "Have your administrator create a local account" error happens when we try to lookup an agent using the e-mail address composed from the CAS user result. This tell us two things: (1) we got a valid CAS response and (2) whatever we're trying to lookup isn't matching anything present.

The major difference between client login vs agent login is that we will create accounts for clients if they don't already exist. The consequence of this though is that if things aren't configured quite right then we may end up creating accounts with bogus details. I suggest looking at the client accounts that you tested and just confirming that the e-mail address on them is composed correctly. If it is correct then that's definitely concerning and something we'll need to dig more into.

If it's not correct then there's a few things we can use to solve it based on your CAS environment:

  1. If CAS usernames are e-mail address then nothing special should need to be done.
  2. If CAS includes the e-mail address in the supplemental attributes, you can configure the plugin with that attribute name and we'll use that value.
  3. As a last resort we can allow setting a e-mail suffix value. We then use the username returned by CAS plus the e-mail suffix to compose the user's e-mail.

My best guess is that one of these settings isn't set correctly for your particular environment, and again, if that's the case we'll see the issue with some of the clients that have been auto created by plugin.

rcf96 commented 4 years ago

After some digging and work I have figured out that the email address that is being drawn and confirmed by the CAS server is the forwarding email used by college students and professors. The way our college works is we have an id and an email associated with that id which is formatted like id@domain.edu. Most if not all people attending the college have email forwarding set up to receive the emails to a more commonly used email, usually a gmail. Now when registering agents if the forwarding email is used as their email they can successfully login via CAS. If their id@domain.edu is used then we get the error message of "Have your administrator create a local account". This is not that big of an issue as we can just register agents with their forwarding email but do you know if there is way that we can configure the plugin to use their id@domain.edu email address for verification?

kevinoconnor7 commented 4 years ago

I assume that you're currently setup under option (2) that I described. If so then you'll probably want to switch to option (3).

To do that go into the plugin settings and:

  1. Empty out the value for E-mail attribute key. The plugin always prefers using this, when available, so we need to unset it since it's undesirable in your case.
  2. Populate the setting E-mail suffix with domain.edu.

This should be all you need; though I'm also assuming that the username CAS returns in the payload is the id portion of your id@domain.edu example.

rcf96 commented 4 years ago

It looks like that worked! Emptying out the value for the email attribute key and then using the email suffix allowed for users to use their id@domain.edu. Thank you for your help!