You can edit the text displayed in your user portal from the Settings page. Just choose the organization and then you can click the fields in the user portal section to edit them.

• Page Title: This appears at the very top of the portal. Use this to identify your company and the fact that this is indeed a ticketing system.
• Form Title: This is the text that will appear just above the ticket form. Use this to title the actual ticket form.
• Form Message: This text appears just below the form title. Use it to indicate that these fields constitute a ticket and will lead to the end-user getting their problem addressed and solved.
• Success Title: This is the message your end users will see after the ticket has been successfully submitted. You can use this text to be sarcastic and congratulate them for correctly clicking a submit button, or be professional and let them know that their ticket has been received and that they should expect help shortly. Your call.
• Displayed Email: There’s a little box in the user portal that lets your users know that they can also send an email to the address listed here. Most of the time, you’ll just leave this field alone, but if you’ve set up some email forwarding to use a different email address, you can enter that one here.

Category: Here you have 2 options. You can choose whether you want to include the category field for your end-users to be able to attempt to categorize their tickets themselves. You can also choose to make this selection mandatory in order to submit a ticket.

Portal Authentication: There are three methods you can configure for access to the User Portal. Authenticated users are able to create new tickets, and view and search their ticket history. Guest users are only able to submit new tickets.

• Active Directory: You can have your end users log in to the portal using their Active Directory credentials. Just go to the Active Directory settings page for your organization and click the Enable button. You’ll then need to follow these instructions to finish the setup.
• Authorization Required: Your end-users enter their email address and then log in through a verification email each time they access the portal. This option is on by default when you aren’t using Active Directory authentication.

Guest User Allowed: Your end-users enter their email address together with a ticket summary and description. No authentication/login is required. This mode is restricted from uploading attachments, and some users may have to complete a captcha when they submit their ticket. All tickets are created by Portal Guest and your end user will not receive a confirmation email that their ticket was created. The email address entered by the user is prepended to the Description of their new ticket allowing you to verify the authenticity of the ticket before setting the ticket’s Contact. Once you’ve updated the Contact, notification emails will be delivered to the end user as normal.

4: Secure your installation

Don’t forget to keep your Help Desk Server (HDS) virtual machine up-to-date with the latest security patches! We recommend keeping the HDS operating system and components updated through automatic updates and that you include your HDS VM in your company’s normal testing and implementation procedures. You can read more about automatic updates here.

Setting up Ticket monitors

You can set up ticket monitors to let you know when tickets have been unassigned for too long, past due, approaching their due date, or a number of other triggers.

You can add monitors by selecting Monitors & Alerts from each Organization on your Settings page.

• is past due
• due in
• open for >
• inactive > “Inactive” means that no admin or end-user has made an update.
• stale for > “Stale” means that there as been no update by the end-user. This does not take admin updates into account
• waiting > This is for tickets in the “waiting on user” status.

You’ll probably want to leave the boxes checked here, especially when you’re creating new monitors, as email is the only way that you’ll see that an alert was generated.

Setting up Active Directory access for the user portal

You can restrict access to the user portal by requiring your users to log in to Active Directory to access it. But what if you don’t want to expose Active Directory information outside of your network? No worries. You’ll be using a JSON Web Token to allow the authentication to happen completely in the browser without exposing your network infrastructure to the outside world.

How authentication works

You may be wondering how does the authentication work without Active Directory passwords leaving your network or without exposing them. Here’s a quick rundown:

1. Your end user accesses the user portal URL.
2. Spiceworks Help Desk sees that you have Active Directory Authentication set up and redirects your browser to your IIS server (you are operating entirely within your network).
3. IIS prompts for a login, which it then checks against Active Directory. If successful, a token containing a secret key is sent back to the browser.
4. The browser now sends that token to the Spiceworks Help Desk, where the secret key is compared to the one stored in your Help Desk. If the two match,the user is authenticated and allowed to access the portal.

Prerequisites

You’ll need an IIS server that is able to communicate with your Active Directory server, along with the following installed (for more information on getting these installed, click here.)

• Windows Server 2012 or later
• Internet Information Services (IIS)
• IIS ASP.NET support (4.5 or above)
• IIS Windows Authentication
• .NET Framework 4.8

Enable Active Directory authentication

Navigate to Settings and choose the organization you want to enable Active Directory authentication for. Choose Active Directory in the settings for that organization. Then click the Enable button.

Enter the auth server address

This is the IIS server where you will install the MSI handler that Spiceworks Help Desk Server will use to authenticate your end-users. Just click on the text that is already there to edit it. Make sure to include SWAuth at the end unless you intend to choose a different directory for the installation.

Generate your secret key

You’ll need a key to authorize the connection with AD, so click the Generate New Key link to create one, and copy and paste it somewhere so you’ll have access to it. You’ll only be able to see this once, so if you lose the key, you’ll have to generate a new one which will wipe out the old one.

Install the AD request handler service

Click the Download button to download the AD handler service you’ll need for this whole thing to work. Make sure to Run it as an Administrator on the machine that you specified during the Enter the auth server address section.

After that paste your secret key into the appropriate field and click Next.

From this point forward, most people will be fine with leaving all the default values in place. You’ll just need to enter admin login credentials. But if you’re curious, we’ll go ahead and cover them:

• AD Domain: The AD domain where your users reside. If yours is different than the default, you’ll need to change this.
• AD Server URL: If your Active Directory and IIS servers are separate, enter the URL for your Active Directory server here. Note: This is an LDAP URL like ldap://DomainController:389/ou=employees,dc=company,dc=org
• Allowed Roles: This will include all users by default. If you want to limit the users who have access to your user portal, you’ll need to change this value. Make sure you’re using the exact group names from Active Directory and separating them by semicolon.
• Email: Set this value to mail if your AD users have an email address defined in the General → Email field.
• First Name, Last name Attributes: Change these if your Active Directory environment uses different fields for these values.
• Full Name Attribute: If you have set up the full name field instead of individual first and last name fields, enter the value here. You’ll need one or the other; Spiceworks Help Desk Server requires a name value for end-users.

Advanced Setup

Adding network interfaces

You can add and configure multiple network interfaces using standard Ubuntu configuration. Use your hypervisor’s virtual machine (VM) settings to add the new virtual network interface to your Help Desk Server (HDS) VM.

Then within the HDS VM, you can use netplan to configure DHCP for the new network interface:

• view network interface information using ip addr
• create/edit a config file using sudo nano /etc/netplan/99_config.yaml
• add config per ubuntu documentation
• save the config file with ctrl + o
• sudo netplan apply
• confirm changes with ip addr

Enabling remote SSH access

By default, remote SSH access is disabled on new installations of HDS. Enabling remote SSH allows you to remotely access the HDS console via SSH, just as you would access any other server with a remote SSH service available. This allows you to remotely run console commands from the comfort of your own workstation’s terminal.

Note: only enable remote SSH if you control SSH/port 22 access to your HDS at the network level, and have a strong password on your HDS user account. Securing your HDS is your responsibility!

Run these commands from the HDS console to enable remote SSH:

sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

Don’t create a passphrase if prompted.

sudo service ssh restart

now you can “SSH in” from a terminal/console on your workstation using the typical:

If you don’t know the IP address of your HDS virtual machine, run this command:

Set the timezone for the VM

• check the list of available timezones using timedatectl list-timezones
• set your timezone using sudo timedatectl set-timezone your_time_zone (ex. sudo timedatectl set-timezone America/Chicago )

Troubleshooting

Common SWAuth Errors

Error: Signature verification raised

The secret key set in Settings > Active Directory does not match the key stored on the domain controller. Generate a new secret key and save that new key into your C:\inetpub\wwwroot\SWAuth\Web.config file, in the value.