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

IIS, SSO and normal-login, no Public Registration with Automatic User Creation on Login

edited July 2015 in Mods and Customizations
My setup is Windows Server 2012 R2 with IIS 8.5 which hosts the osTicket install and my authentication back-end is a Microsoft Active Directory accessed via LDAP using the "LDAP Authentication and Lookup" plugin. SSO on osTicket is also enabled through the "HTTP Passthru Authentication" plugin. The IIS site hosting the osTicket installation should have "Anonymous Authentication" enabled and "Windows Authentication" enabled and configured (Providers, Kernel-mode protection etc. needs to be configured as per your own situation). You should have setup at least this far, if you don't know how to get this far this guide is not for you.

The goal in my use-case was to support both normal authentication (Through osTicket login form, or as far as IIS is concerned, "Anonymous Authentication") but also support Windows Authentication for clients which support it. Those logging in using either method should be authenticated against the authentication backend (AD via LDAP) and if an osTicket user account does not exist for that backend user, automatically create it.

IIS cannot support both Anonymous Authentication and Windows Authentication in the same request, so we have to do some permission and redirection trickery. osTicket also still doesn't have a mode which is essentially private (no public registration) but still honours account creation requests from the authentication backend, so we will have to implement that too (easier than you think).

Concept: Force Windows Authentication
Essentially, we create a file (In my example, a PHP script) which just redirects the user back to the home page. We change the supported authentication methods on this redirection file to just support Windows Authentication, disabling Anonymous Authentication. It's important that this redirection script is in the root of the osTicket installation. What this will do is it will force the client to do Windows Authentication over Anonymous Authentication than redirect them back to the osTicket installation as normal and the client will still continue to use Windows Authentication for all additional requests (except SCP).

The only problem is anyone that you wish to force Windows Authentication on will need to go through this entry point (the redirection script) or else Windows Authentication won't work and you'll just be presented with the osTicket login form as normal (Seeing as it'll use IIS "Anonymous Authentication") but, at least for my situation, I had control over said clients and simply pushed our bookmarks/favourites which pointing at the correct entry point. Other clients, ones without Windows Authentication, would simply use the website as normal and not use or see that entry point at all. I've been told this technique is not honoured on all browsers that support Windows Authentication and IIS configuration regarding authentication that differs from default can also impact it, you'll have to do your own testing.

Concept: Automatic User Creation
We create a new Registration Method
(I say new but there are already preliminary traces of such a method already existing)
and then adjust some checks for the public user registration links and
access to them.

Step 1: Create Redirection File
There are many different ways to do this but the principle remains the same. Create the script and ensure it redirects your Windows Authenticated users to where you want to go (Eg: home, open ticket etc.)
An example:
<?php
$url = 'https://examplesupport.local/';
?>
<html>
<head>
    <title>Redirecting...</title>
    <meta http-equiv="refresh" content="0;url='<?php echo $url; ?>'" />
</head>
<body>
    <p><a href="<?php echo $url; ?>">Redirecting...</a></p>
</body>
</html>


Step 2: Change supported Authentication methods on Redirection File
We go to Content View in IIS Manager under the IIS Site that has our osTicket installation and select this redirection script,
going back to Feature View and disabling "Anonymous Authentication",
leaving only "Windows Authentication" enabled.

Step 3: Change PHP code
  • include/staff/settings-access.inc.php
    • Add "auto" to 'client_registration' options.
      'auto' => __('Auto — Only backend can register users'),
  • include/client/accesslink.inc.php
    • Change:
      if ($cfg && $cfg->isClientRegistrationEnabled())
      to
      if ($cfg && $cfg->getClientRegistrationMode() === 'public')
  • include/client/login.inc.php
    • Change:
      if ($cfg && $cfg->isClientRegistrationEnabled())
      to
      if ($cfg && $cfg->getClientRegistrationMode() === 'public')
  • include/client/view.inc.php
    • Change:
      if ($cfg && $cfg->isClientRegistrationEnabled())
      to
      if ($cfg && $cfg->getClientRegistrationMode() === 'public')
  • account.php
    • Change:
      if (!$cfg || !$cfg->isClientRegistrationEnabled())
      to
      if(!$cfg || $cfg->getClientRegistrationMode() !== 'public')
    • This is for security.
Step 4: Change Registration Method
Login to osTicket as an administrator user and change the registration method to the one we just added ('auto')

Testing
  1. Go to the root of osTicket (normal location) with a browser that is not configured for Windows Authentication and try logging in (using a user which does not already exist in osTicket) using the normal osTicket form.
  2. Go to the root of osTicket (normal location) with a browser that is not
    configured for Windows Authentication and try logging in (using a user
    which already exists in osTicket) using the normal osTicket
    form.
  3. Go to the Windows Authentication entry point (that redirection script) with a browser that supports Windows
    Authentication (using a user which does not already exist in osTicket) and go to the open ticket form, you should not be asked to login.
  4. Go to the Windows Authentication entry point (that redirection script) with a browser that supports Windows
    Authentication (using a user
    which already exists in osTicket) and go to the open ticket form, you should not be asked to login.
  5. Attempt to go to the following URLs and ensure you are redirected:
    • /account.php?do=create
I could never get SSO working with SCP, sorry. I'm not using this in a production setup so far, only with test users.

Comments

  • Interesting guide :)

    We do this a bit different by using public registration and redirecting end user when they try to access the end user account creation / registration page in combination with a little script prior to osTicket end user portal is being opened to authenticate end users using SSO (ldap + http auth plugins)
  • edited July 2015

    For 1.9.11:

    Step 3: Change PHP code
    • include/staff/settings-access.inc.php
      • Add "auto" to 'client_registration' options.
        'auto' => __('Auto — Only backend can register users'),
    • include/client/accesslink.inc.php
      • Change:
        if ($cfg->isClientRegistrationEnabled()) {
        to
        if ($cfg && $cfg->getClientRegistrationMode() === 'public')
    • include/client/login.inc.php
      • Change:
        if ($cfg && $cfg->isClientRegistrationEnabled())
        to
        if ($cfg && $cfg->getClientRegistrationMode() === 'public')
    • include/client/view.inc.php
      • Change:
        if ($thisclient && $thisclient->isGuest()
            && $cfg->isClientRegistrationEnabled())

        to
        if ($thisclient && $thisclient->isGuest()
            && $cfg->getClientRegistrationMode() === 'public')
    • account.php
      • Change:
        if (!$cfg || !$cfg->isClientRegistrationEnabled())
        to
        if(!$cfg || $cfg->getClientRegistrationMode() !== 'public')
      • This is for security.
  • Anyone reading this, please add your support behind ticket #2274 and ticket #1944 so we won't have to do most (Excluding IIS SSO) of the above any more.
  • i have seen some progress on this. Any news?
  • For 1.9.13:

    There appears to be no changes in instructions from 1.9.11
  • 1.9.13 has not been released at this time.
  • @Staj No it has not. 
    There has been no announcement here on the forums by the devs.
    There has been no package added to osticket.com/downloads.
    Settings up a tag for the release does not a release make.
  • Then to clarify, I mean the 1.9.13 tag as presented.
  • Sorry just for clarity this allows for an AD user to login which then auto creates their profile....correct me if I am wrong but doesn't that in some respects defeat the purpose of SSO?

    Wouldn't the more appropriate checks be to do the following:

    Read/ compare/store the logged in authenticated user and test it against AD

    IF user exists then check to see if that user exists in OSticket if yes then proceed and authenticate
    else
    If the user exists in AD and is not a user in OSticket yet then create user and rediretc back to main login page
    else
    if user does not exist in AD then direct user to main login screen


    To me this allows for true SSO auth but would not prevent a shop form having OSticket local logins as well if required.
  • edited April 28
    It's been two years and osTicket still doesn't support this functionality properly.
Sign In or Register to comment.