This document serves to provide an in-depth overview of the different authentication logon policies in Service Desk. The intended audience is Service Desk administrators wishing to gain a better understanding of the various methods used for authentication. It is assumed the reader has a basic knowledge of Service Desk and the client/server architecture used.
The information in this guide is correct as of Service Desk version 7.5.
Below is an overview of Service Desk authentication.
All users wishing to access Service Desk either as an Analyst or End User (including the alternate end user types Contact and Account Manager) must have a record stored in the Service Desk database. These records are managed within the Administration component of the Service Desk Console and can be imported automatically using the Data Import features. The management of users will not be covered in this document, for more information please see the Administrator manual.
On every user record the following information can be stored and is used by the various authentication logon policies:
- Username - A text string attribute on the User object that identifies the user record. This attribute is required regardless of the logon policy used and must be unique.
- Password - A text string encrypted in the Service Desk database that is used for the standard Explicit logon policy (explained below). Unless specifically set this will be blank by default. This is stored in its own object called Password under the System module and the User object has a relationship to this.
- Network Logins - A collection of text strings that are used to store full network logins for the user. The format required varies depending on the logon policy. This is a separate object called User Network Login under the System module and can be imported into using its relationship back to User to tie the network login back to the relevant user record.
Logon Policies Overview
There are three different logon policies Service Desk can use. Each will be explained in detail later in the document:
- Explicit - Users are authenticated by manually typing in a username and password. This is matched against the username and password stored on the user records in the Service Desk database.
- Integrated - Users are automatically authenticated based on the client (either the Service Desk Console or web browser) sending the user's network login. This is matched up against the network logins stored on the user records in the Service Desk database.
- LDAP - Users are authenticated by manually typing in a username and password. The username is used to match a user record in the Service Desk database, then the password is used with the network logins stored on the user record to authenticate with an LDAP server (ActiveDirectory, eDirectory).
Using a mixture of Logon Policies
The policy used is configured separately for each instance of each application. This allows for example Console to use one policy, while the internal Web Access uses another and the externally facing Web Access uses another. You cannot use a mixture of policies per instance and so must configure separate instances of each application.
Logon Policy Configuration
Each login policy has some specific configuration required however the changes common to all types is a setting called Logon Policy stored in configuration files on both the server and the client (for Console only).
Changing the Logon Policy on the server
The Logon Policy is configured separately for each server application, ie. each instance of Service Desk Framework and Web Access. Note that after making a change to the policy it is normally required to recycle the application.
From 7.5 onwards this can be configured within the Configuration Centre by clicking the Edit button for the application you wish to change and selecting a value of either Explicit Only or Integrated Only for the Logon Policy field.
On versions 7.4 and earlier the setting is changed directly in the tps.config configuration file for each application. This file is stored under C:\ProgramData\Touchpaper\<application-name> (or C:\Documents and Settings\All Users\Application Data\Touchpaper\<application-name> on older versions of Windows). Somewhere within the file will be the following line:
<add key="LogonPolicy" value="ExplicitOnly" />
The value should always be either "ExplicitOnly" or "IntegratedOnly".
Changing the Logon Policy on the client
Analysts using the Console have the same LogonPolicy setting as the server in its configuration file and this must match the policy set for the instance of the Service Desk Framework it is connecting to. The file is called Console.exe.config (or Consolex64.exe.config for 64-bit workstations) and the line to modify is identical to that in the tps.config file on the server (see the section above).
Web Access interfaces (Web Desk, Self Service and Mobile Web Desk) require no cleint-side configuration.
Explicit and LDAP logon policies require the user to enter a password to be sent to the server. The following security is provided for this:
Before Console sends credentials to Service Desk Framework it encrypts the password. The username and the authentication request itself is sent in plain text via HTTP however you can configure SSL within IIS and use HTTPS so all communication is encrypted.
As is common with most HTML forms, both the username and password are sent from the web browser to the Web Access application in plain text unless communicating with it via HTTPS. It is therefore recommended to configure SSL within IIS when hosting Web Access on externally facing systems.
Passwords stored in the Service Desk Database
Passwords for Explicit logon are stored in the Service Desk Database using a one-way encryption hash. The default encryption algorithm is MD5 however can be changed to SHA1 to meet FIPS compliance. For information on changing to SHA1 encryption please contact your local support provider.
Explicit Logon Policy
The standard logon policy used by Service Desk is known as Explicit. To authenticate the user is prompted to specify a username and password and these are then matched against a user record within the Service Desk database. The following flowchart shows the authentication process with Explicit logon:
Integrated Logon Policy
Used for internally facing systems, Integrated logon automatically authenticates a user by taking their Windows login name to match up against a Service Desk user record. The login name is stored on the user record using the Network Logins collection, and should be in one of the following formats:
ActiveDirectory Domain User: DOMAIN\Username
Local User: PCNAME\LocalUsername
Novell User: NDS:\\Tree\Context\Username (Console only)
The following flowchart shows the authentication process with Integrated logon:
Web Browser Security Settings
Quite rightly web browsers will not send the network credentials of the logged in user to any web server that requests them. The sections below give more information on the major supported browsers.
Internet Explorer will only send credentials automatically if the zone the Web Access server resides in is configured to. To check which zone it sees the server in browse to the server root and the zone is displayed in the bottom right hand corner. In general for internally facing systems it should automatically be picked up as the Intranet zone, and by default the zone is allowed to send credentials automatically.
To modify which zone a server appears in or change the settings for that zone use the Security tab of the Internet Options dialog. Click Custom Level... and scroll to the bottom section of settings called User Authentication to see the different options on sending credentials.
By default Firefox will not automatically send credentials to a server even if it appears to be internal. Instead you are prompted for credentials at each visit. However you can add the server to a trusted list for automatic authentication. For instructions on this please see the following link: http://support.mozilla.com/en-US/kb/Firefox%20asks%20for%20user%20name%20and%20password%20on%20internal%20sites. For detailed information on Firefox's support the following link: https://developer.mozilla.org/en/Integrated_Authentication.
There is very little information available on Chrome's support for sending credentials automatically except that it has been supported since version 5. In all tests it automatically detects the server's location in line with Internet Explorer.
Browsers on Mobile Devices (iPhone, Android, BlackBerry, Windows Mobile, etc)
Mobile Web Desk can use Integrated Logon however it is unlikely they will know any credentials to send. Most mobile browsers will prompt you for credentials at each visit.
LDAP Logon Policy
LDAP Logon allows users not on a domain (or outside of the LAN) to access Service Desk without needing to know the password used with Explicit Logon. From a client's perspective they are prompted for a username and password the same as they are for Explicit Logon however the password entered is instead used to attempt authentication with an LDAP server and uses the result of this as the result of the Service Desk logon attempt.
On the assumption that each user in Service Desk has their username set to match their domain username and so as far as they are concerned they are providing their existing domain credentials.
The following flowchart shows the authentication process with LDAP logon:
LDAP Logon works by configuring both the server and client applications to use Explicit Logon and then adding an extra set of configuration to the server to employ an alternative Authentication Provider. There are three providers to choose from for LDAP:
- Active Directory (non-SSL or SSL)
- eDirectory (non-SSL)
- eDirectory (SSL)
Other LDAP servers may be compatible but have not be validated by LANDesk.
With each Authentication Provider is an XML configuration file that stores the details of the LDAP server to connect to. To find the username to connect to the LDAP with the username entered in the client is used to look up the Service Desk user, and then each of their Network Logins is used along with the password provided by the client. The Network Login should be the Distinguished Name of the LDAP user:
ActiveDirectory Domain User: CN=username,CN=users,DC=domain,DC=com
eDirectory User: CN=username,O=organisation
Note that because users can have multiple Network Login entries they could be enabled to for both Integrated and LDAP Logon authentication by having both formats stored against their user record.
For more information on how to configure LDAP Logon authentication see the Appendix of the LDSDSetup.pdf manual. The manual for Service Desk version 7.5 is available from this link: LANDesk Service Desk Suite 7.5 Setup.
If a logon attempt fails unexpectedly there are steps you can take for all logon policies to find the root cause.
Diagnostic Logging (all logon policies)
Logging can be enabled on the Framework or Web Access to trace why a logon attempt failed.
Enabling Diagnostic Logging
From version 7.5 onwards this can be enabled within the Configuration Centre by clicking the Diagnostics button for the application then setting an appropriate logging level for the Authentication category.
On version 7.4 and earlier the logging is enabled directly in the tps.config configuration file for each application. This file is stored under C:\ProgramData\Touchpaper\<application-name> (or C:\Documents and Settings\All Users\Application Data\Touchpaper\<application-name> on older versions of Windows). Within the <appSettings> section of the file add the following line to enable full logging for authentication:
<add key="TraceLevel_Authentication" value="All" />
The value should be All, Errors, or None to disable it.
Analysing the Log Files
A log file is created for each user, although in the case of failed logon attempts the logging data will be saved in the System user's log file. The files are found in C:\ProgramData\Touchpaper\<application-name>\Logfiles (or C:\Documents and Settings\All Users\Application Data\Touchpaper\<application-name>\Logfiles) and named tps-date-username.log.
To read the logged data you should open the log file in Wordpad. Note that Notepad will not format the line breaks on authentication log entries properly. An example authentication log entry looks as follows:
Authentication Authenticate User Logon at 2011-11-16 14:40:07.018 Logon Policy: ExplicitOnly User Name: SA User Guid: 00000000-0000-0000-0000-000000000000 Password: mKKV2DcfP57dqO+rJaduiNkciOPrFSMT Windows Principal (used for Integrated Logon): MYDOMAIN\MyUser Network Logon Hash (used for Integrated Logon): 8C-CA-C1-01-12-2C-3B-F7-11-17-7C-EF-A5-57-85-08-B1-27-32-B5 Is Integrated Logon: False Is Interactive: True Logon Status: Explicit Group Name: Group Guid: 00000000-0000-0000-0000-000000000000 Reason for Logon Failure: WrongPassword FAILED Logon failed
The main lines to take note of are the Logon Policy, the User Name sent from the client (if using Explicit or LDAP logon), the Windows Principal, and most importantly the result (the last two lines) and the Reason for Logon Failure if it failed.
Common values for the Reason for Logon Failure line are: WrongPassword, UserNameNotInDatabase, UserSoftDeleted.