The AD integration makes it possible to set up a single sign-on (SSO) function against a local Active Directory (AD) or other authentication servers with similar functionality.
Authentication against Azure AD is currently not yet available and will be added with a later release.
Single sign-on authentication can optionally be used for logging in as a user and as a user of the Self-Service Portal (SSP).
For secure technical integration, local settings must be made in the customer network and a provided authentication tool must be installed.
|
Note: The function described here is tested exclusively in connection with a local AD. The instructions and the authentication tool provided are also prepared for AD authentication only. Problems with other authentication systems are not supported if not explicitly described in this help. |
Description of the administration settings functions 
•Label of the login button: On the login page, a button for "Windows Login" is displayed after activating the function. The label of this button can be changed individually via this field if special labels exist in the company for such functions.
•AD-authentication: Activates the function in the system. Thus, the option is generally displayed on the login page. Important: the function must be activated additionally for each user and person. The activation takes up to one minute until it is usable.
•Use field UserPrincipalName for authentication: In standard, the AD field "SamAccountName" is used for authentication. Check this box, if the AD field "UserPrinicipleName" is used for authentication instead. Attention: If you have checked this field during the configuration of the AD integration in the ticket system, the UserPrincipalName must also be stored in the "Login Name" field for all persons/users. Please also adjust the import file accordingly.
•RedirectURL: The URL of the server address of the authentication tool must be stored here. The authentication request is made against this system. Replace the URL with "/auth" in the end. You can use http or https, depending on your configuration of the IIS.
Example:
•Link to the authentication tool: This link is generated automatically after entering the redirect URL. The link directly opens the input dialog for the settings token. If the tool opens with this URL, it is set up correctly and the path is also entered correctly.
•User info (for troubleshooting): opens a link with a tool that shows all permissions of the current used windows user to the admin. This helps to understand the domain and permission context the current user is in while setting the SSO configuration. The "SamAccountName" or "User Principal Name" displayed in the User Info must match the login name on the person/user record in the system. Which of the two fields is used for authentication depends on the corresponding setting (see above).
•Button "GENERATE SETTINGS TOKEN": This button generates the token, which automatically makes all settings in the authentication tool and uses a high security encryption standard (SHA 265). Please generate the token only after entering the correct redirect URL.
•Settings-Token: Once the token is generated, it can be copied and pasted into the input field in the local authentication tool (tool opens directly with the input field).
•Deactivate password login for SSP: Option that only the Windows authentication method is offered on the login screen for the SSP. This can avoid misunderstandings if no passwords are to be managed for the ticket system and users try to log in with the Windows user/password. Important note: If the AD integration is not technically available, there is no alternative way to log in to the SSP. The restriction only applies to normal users. Users with a real user account (ticket processors, admins etc.) always have the additional option "username/password" on the login screen to always have a fallback for logging in
|
Notes on the methods, protocols and security mechanisms used: The protocols / mechanisms used are http(s) (configurable by the customer based on IIS) and JSON Web Token (JWT).
Technical process of authentication: •After clicking the login button, the system redirects the user to the web server where the authentication tool is installed (redirect URL). •The IIS performs the authentication against the AD using the Windows authentication integrated there by default. •IIS then sets a variable which is accessed by the authentication tool •The authentication tool generates a JSON Web Token (JWT) signed with SHA256 using the credentials it receives. This token is then securely forwarded to our service using https. The JWT token contains the login name (no password!) of the user. •The login name is searched for in the ticketing system and - if available - used for the login. |
Installation of the authentication tool
To authenticate against your local Active Directory, you do not need to make your system accessible from outside your network. We provide an authentication tool that you install on a machine in your network. Then, the tool uses functions of IIS to authenticate against your local Active Directory. The tool uses the credentials it receives to generate a JSON Web Token (JWT) signed with SHA256. This token is then securely forwarded to our service using HTTPS.
|
Note: As the described setup has to be performed by a customer administrator within the company network, we have no direct access to this configuration settings. As each network can have internal individual specifics and security settings we can not provide direct support in case of problems with the installation. The responsibility of the own network settings lies exclusively with the customer. |
Please download the authentication tool here: DOWNLOAD Authentication Tool
Please set up authentication according to the following instructions:
|
Installation authentication tool
1. Please provide a machine with IIS installed (Microsoft Internet Information Server (IIS) 7.0, 7.5, 8, 8.5 or 10) The system must be located in a domain from which the required Active Directory is accessible. In addition, the IIS must be accessible to all users who are to be authenticated. There must be no direct connection between our services and your IIS! For this reason, an internet connection is only mandatory for the IIS if the users should be able to access the IIS from the internet.
2. The following system components of IIS must be enabled as a minimum:
3. By default, please unzip the zip file provided in this help article to: C:\inetpub\wwroot\auth If there is no folder "auth" under wwwroot, please create it. In the folder „Auth“ the unzipped data/ folder must be contained as follows (directly without additional subfolders):
4. Now, open the IIS Manager, under "Default WebSite" a folder "auth" must now appear
5. Open the menu with the right mouse button and click on "Convert to application". Then, confirm with OK
6. Now, open the application and in it the "Authentication" menu item
Disable all options, only the "Windows Authentication" option must be enabled.
7. Go to the folder C:\inetpub\wwwroot and right-click here to open the properties of the "auth" folder. The users "IUSR" and "IIS_IUSRS" both need the following permissions:
8. The configuration interface is now complete. Under certain circumstances, an "Error" message may still appear stating that the configuration is incomplete. This will disappear after the next step has been implemented.
9. After accepting the settings, the authentication tool is now accessible and can be used.
Please enter the address of the tool as a re-direct URL analog to the following instructions for the setup procedure within the ticketing system. The link is accessible if your own user has local admin rights on the IIS system. Otherwise, you can access via localhost to insert the settings token.
|
Procedure for the setup within the ticketing system
After installing the local authentication tool, the following activities must be performed:
|
AD integration setup steps In the "AD Integration" tile in the system administration: 1.Set the check mark for AD authentication 2.Enter the Redirect URL (your server address of the authentication tool) 3.Click the "GENERATE SETTINGS TOKEN" button 4.Copy the full token and open the "Link to the authentication tool". 5.Enter the complete token in the following input field
All configuration data is automatically adopted via the token, you do not need to make any further settings.
Set the following on the master data forms of the people and users who should be able to log in via single sign-on:
Persons, form section "login data": 1.Generally, the "Access SSP" field must first be set to "Access granted" for all persons who are to have access to the SSP. 2.For all persons for whom authentication via single sign-on is desired, additionally set the Authentication field to "Windows" and thus enter your Windows domain name as mandatory. In this way, the person is given the option of logging into the Self-Service Portal using either a user name/password OR Windows single-sign on. 3.If the Authentication field is set to "Password", the entered Windows domain will be deleted and the person will only be able to log in using the assigned username/password.
Tip: To activate the SSP login or the Windows authentication for many persons at the same time, there are corresponding buttons on the administration tile Persons/User next to the list. You can select several or all persons and then use the buttons to create the authorizations. In the upper left part of the list all persons can be marked by a check mark.
Users, form section "login data": The authentication setting for users is the same as for persons. If access to the Self-Service Portal is granted as an option, the user's user name/password for the Self-Service Portal log-in are identical. The only difference for users is that if "Windows" authentication is set, logging in for normal access using the user name/password is no longer possible! The log-in to the Self-Service Portal is still possible via both options.
|
|
Notes: The login name of the users in the Active Directory must match the user names in the master data of the users and persons so that a single-sign on logon can take place. The passwords in the ticketing system are exclusively those that are individually maintained there by the administrator or user. For security reasons, we do not automatically store e.g. the Windows password of a user here. Each customer is responsible for the individual assignment and any necessary security features of the passwords. |