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
Login to osTicket as an administrator user and change the registration method to the one we just added ('auto')
Testing
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'),
- Change:
if ($cfg && $cfg->isClientRegistrationEnabled())
to
if ($cfg && $cfg->getClientRegistrationMode() === 'public')
- Change:
if ($cfg && $cfg->isClientRegistrationEnabled())
to
if ($cfg && $cfg->getClientRegistrationMode() === 'public')
- Change:
if ($cfg && $cfg->isClientRegistrationEnabled())
to
if ($cfg && $cfg->getClientRegistrationMode() === 'public')
- Change:
if (!$cfg || !$cfg->isClientRegistrationEnabled())
to
if(!$cfg || $cfg->getClientRegistrationMode() !== 'public') - This is for security.
Login to osTicket as an administrator user and change the registration method to the one we just added ('auto')
Testing
- 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.
- 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. - 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. - 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. - Attempt to go to the following URLs and ensure you are redirected:
- /account.php?do=create
