Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Single Sign-On (SSO) issues / bug / question

Hi, I spent some time configuring SSO on our server and ran into some issues I wanted to share.

Here's my config:
  • OS: Debian 7.5-amd64
  • osTicket Version: v1.9.1 (0e29c8d)
  • Server Software: Apache/2.2.22 (Debian)
  • PHP Version: 5.4.4-14+deb7u10
  • MySQL Version: 10.0.11 (MariaDB)
Plugins configured and activated:
  • LDAP Authentication and Lookup (v0.5) (works fine. Logging in with AD username/pass works fine for users and staff)
  • HTTP Passthru Authentication (v0.2) - tested with latest build from Jared and built from sources
SSO configured on the OS with Kerberos/Samba/Winbind. I used the guide from Michael (Chefkeks) found here.

I registered a domain user in osTicket with LDAP as authentication method. Logging in with domain username/pass works fine.
After activating SSO in apache things go wrong:

* Access control settings - Registration method: private (=what I want)
    - apache log shows windows user (=ok)
    - logging into osTicket shows user welcome page (=ok)
    - clicking sign in link shows: Access Denied. Contact your help desk administrator to have an account registered for you
    => passthru works but username not recognized

* Access control settings - Registration method changed to public
    -  clicking sign in link now works, but what happens is that a second useraccount is created with the same user_id but different username and backend. Not the right behaviour:

ost_user_account:
id    user_id    status    timezone_id    dst    lang    username    passwd    backend
7    50    9    15        1    NULL    NULL        NULL    ldap.client    <= existed
25    50    1    15        1    NULL    samaccountname    NULL    NULL        <= added by public user registration

Deleting the user in the scp only removes the first user_id, which breaks things if you want to add the user again later on.
If username 'NULL' is updated to the samaccountname, all works fine.

Thanks guys!
J.


Comments

  • So I tried some more trying to get SSO also to work for staff users without luck. LDAP auth for staff works just fine and passthru for staff is enabled. I'm lost. Hopefully someone can point me in the right direction.
    The browser passes the AD user to the webserver (checked in apache log) but login fails when clicking 'Log In' with empty user/pass on the /scp page. (Invalid Login message). I'm not sure if I'm supposed to login this way, suggestions are welcome.

    Thank you!
    J.
  • I've pointed out this thread to the devs.
  • edited June 2014
    So I tried some more trying to get SSO also to work for staff users without luck. LDAP auth for staff works just fine and passthru for staff is enabled. I'm lost. Hopefully someone can point me in the right direction. The browser passes the AD user to the webserver (checked in apache log) but login fails when clicking 'Log In' with empty user/pass on the /scp page. (Invalid Login message). I'm not sure if I'm supposed to login this way, suggestions are welcome. Thank you! J.

    Read thru several times, but at the moment I only wonder, why you have to click "Log In" on /scp ?
    In my setup (which I can't look right now since I'm already at home and watching FIFA Soccer Worldcup Opening Game :D - so maybe I'm a bit distraced... ) if I enter /scp I /other staff will be signed in automatically. There is no need to anything else like click "Log In" or so. Nearly the same on the client side - I just enter the side and after that I can click anything I like (Create Ticket, Ticket Status or Log In) and voila the user is signed in.

    Wait... there are 2 cases I need to login to Apache SSO and/or the osticket staff login.
    1. When I start the browser as local user (NOT a domain user) I need to enter my SSO/AD Login. (not so interesting for this topic I think) 2. When I login to Apache / SSO with a AD windows user that is not a staff user. Then I need to enter my credentials again on the /scp (Maybe interesting)

    Some additional info about my setup: Registration Method: Public and Registration Required: YES / ENABLED
    But for now I do not a idea like "That's the error / the source of the issue". Maybe tomorrow when I am at work and look thru our setup I have some idea what you can try ;)
  • Hi @Chefkeks,

    Many thanks for your input. I found out that going directly to login.php or tickets.php logs me in straight away. :-) I would expect the passthru plugin to redirect me automatically, but it doesn't. So SSO is working for my clients which is awesome! I do hope the devs can fix the double user registration in some future release.

    I'd like to know though how you got SSO working for staff. I traced the db transactions today and the user id is passed through by apache. There is 1 difference. When manually logging in there's one more lookup:
    SELECT backend FROM ost_staff WHERE backend IS NOT NULL  AND (username='testuser' OR email='testuser'), which doesn't occur when using SSO.

    Thanks & enjoy your weekend!
  • I'd like to know though how you got SSO working for staff. I traced the db transactions today and the user id is passed through by apache. There is 1 difference. When manually logging in there's one more lookup: SELECT backend FROM ost_staff WHERE backend IS NOT NULL  AND (username='testuser' OR email='testuser'), which doesn't occur when using SSO. Thanks & enjoy your weekend!

    @jerre Unfortunately I did not find the time today to look again at my setup, but next week, I think I will find the time when I'm done with a dirty osticket database hack :D :D :D
    Currently a colleague and I developing an external solution (script) to fill specific database fields with values from AD, so that you inside osticket you see the Office, Mobilephone and anything else you like attached as additional info to the user. :D ... Since we are admins and NOT developers we decided to go that way and after that we will try to do it as a osticket plugin... :D
    Have a nice weekend too, Michael
  • @jerre, where did the first user record come from? It shows a backend of `ldap.client`; however the username is blank.
  • Hi @jared@osticket.com, thanks for the follow-up. The user was autoregistered when opening a ticket by mail. (Mapi autofetched), then registered as ldap user by a staff member.
    The user is able to log on with his domain credentials using the ldap plugin.
    I also tested with a manually created ldap user making use of ldap lookup.
  • So when the user was registered by the staff member, did you enter the user's SAM account name into the `username` box?
  • Yes, In the 'lookup and create user' form, the samaccountname was entered, the other fields are automatically populated by the ldap plugin
  • this happened to me as well. Any fix at the moment.
  • Not to my knowledge, but haven't tried the latest version yet.

    My workaround is to edit the user_account table manually (replacing NULL with the samaccountname) each time a new user is added. It works in small and static environments.

    Maybe @jared has more info.

Sign In or Register to comment.