Table of Contents

Login & Authentication

Niamh Ferns Updated by Niamh Ferns

Login & Authentication Overview

You can read more on tracking logins via our contact authentication audit log documentation.

DeskDirector provides a plethora of authentication methods for users to use. This means that regardless of your environment, preferences, or restrictions you operate under, there will be a method that works for you. In This article we give an introduction to each of these and provide details steps on how to get these set up.

While the article is longer, you do not need to read it all at once. We encourage the team managing DeskDirector at your company to book mark this document for further reference. On the right hand side, you can see each method in the table of contents.

Automatic Contact Creation

DeskDirector includes the ability for you to create contacts automatically via Active Director. This relies on the same 3 core components that sign-in does. You can read more in our Automatic Contact Creation documentation. Automatic contact creation is useful especially for larger companies that have many users who infrequently submit tickets.

Login via OAuth - Microsoft SSO

Historically, DeskDirector used custom applications for authenticating users via SSO. This has since been deprecated and is no longer supported. If you run into issues with your OAuth setup and you are not using new OAuth, please see "Am I already using new OAuth?" and "How do I switch to new OAuth?" in our FAQ at the bottom of this article.

DeskDirector's client portal offers Office 365 Single Sign-On (OAuth) as the recommended login method for users. This authentication method provides a secure and convenient way for users to access the client portal using their Office 365 credentials. By leveraging OAuth, DeskDirector enhances the login experience and offers additional security features, including two-factor authentication (2FA) and the latest security protectors provided by Microsoft.

Benefits of Using OAuth for Client Portal Login:

  1. Enhanced Security: OAuth provides a more secure authentication method compared to traditional password-based logins. With OAuth, user passwords are not stored or transmitted directly to DeskDirector. Instead, the authentication process is handled by Microsoft's secure infrastructure. This reduces the risk of password-related vulnerabilities, such as weak passwords, password reuse, or interception of credentials.
  2. Two-Factor Authentication (2FA): DeskDirector leverages the 2FA capabilities provided by Microsoft through OAuth. With 2FA enabled, users are required to provide an additional verification factor, such as a unique code sent to their mobile device or a biometric scan, in addition to their Office 365 credentials. This adds an extra layer of security, making it significantly more challenging for unauthorized individuals to gain access to the client portal, even if the user's password is compromised.
  3. Compliance with Industry Standards: By utilizing OAuth and integrating with Office 365, DeskDirector aligns with industry best practices and security standards. Microsoft invests heavily in securing their authentication infrastructure, ensuring that OAuth meets stringent security requirements and undergoes regular security audits and updates. By leveraging OAuth, DeskDirector inherits the robust security measures implemented by Microsoft, further enhancing the protection of user accounts and sensitive data.
  4. Continuous Security Improvements: Microsoft continually enhances the security features and protocols associated with OAuth. They monitor and address emerging threats, implement advanced security controls, and provide regular security updates to address vulnerabilities. By using OAuth for client portal authentication, DeskDirector customers benefit from these continuous security improvements without requiring additional effort or maintenance on their part.

Configuring OAuth

If this is your first time using the new OAuth implementation, an administrator from each customer's tenancy will need to grant permissions to DeskDirector on first login.
  1. Login to your Desk Director Admin Portal.
  2. Navigate to System > Authentication > TECH Portal Office365 Single Sign-On
  3. Select the drop down for "Admin Consent" and select "DeskDirector"
  4. Select "Grant Consent"
  5. Login with a MS account that has admin permissions for each tenancy, it looks like this:
  6. Select Accept

If granting consent was successful, you will see a message like that below:

Now contacts from this tenancy can login to the client portal seamlessly via Microsoft SSO.

Granting Consent to the Desk Director Tech portal will also grant consent to the Desk Director client portal for that tenancy.

We recommend granting consent via the Tech portal option outlined above because the client portal consent option will be linked to your existing custom application, until you make the switch to the new OAuth in the next steps below.

Automatic Login via Active Directory

This authentication method is only available with our Desktop Client.

DeskDirector's automatic login via Active Directory relies on 3 core components:

  • The Domain SID
  • Email address in the User's AD Profile ("Email" under the General Tab)
  • Email address of the contact in your PSA

Automatic Login Configuration

Let's go through adding automatic login to a company in your Administration Console.

  1. Download the DeskDirector SID Tool.
    You can read more about the DeskDirector SID Tool in our Login & Authentication Troubleshooting documents.
  2. Next, run this tool on any machine in the user's domain. It could be an end user's computer or a server, as long as it's on the domain. Check that the domain and email address associated with the account are displaying correctly here. Copy the Domain SID using the Copy button.
  3. Now go to the companies page then find the company you ran the tool for and enter their SID and email domains:

And that's it. Client portal users from that company will now automatically login through Active Directory.

Automatic Login Advanced Setup

It is not uncommon for larger companies that are either comprised of multiple smaller companies under a parent or that are split over different countries to have multiple companies with the same SID in DeskDirector. You may also run into situations where users are working on personal devices that are not domain joined but would still like to login automatically.

You can read more on handling those types of situations in our troubleshooting document.

We highly encourage a read through of this document even if you are not actively experiencing issues related to automatic login as it can be a fairly complex system.

Login via Magic Token

Global tokens can be used to automatically log your clients into the web version of DeskDirector.

The main thing to remember about using this feature is that anyone with access to one of these links will be able to authenticate as the recipient of the email. So unless your clients are forwarding their ticket notifications to malicious parties, there is nothing to worry about. You can of course disable this feature at any time.

Enabling Global Magic Token

The setting to enable/disable the Global Magic Token can be found on in your admin console then head to System > Passwordless page. Scroll down to the end of the page to see the Global Magic Token section.

If you want to take your users to a specific ticket, use the bottom link or if you just want to log them in via email use the top link.

Using Magic Tokens

When using Magic Tokens in emails generated by ConnectWise/Autotask, see below for how to format these:

ConnectWise:

<a href="https://{{yourSubdomain}}.deskdirector.com?gtoken=1234567890[contactrecordid]1234567890&ticketid=[srnumber]">Click to view your ticket!</a>

Autotask:

<a href="https://{{yourSubdomain}}.deskdirector.com?gtoken=1234567890[Contact: ID]1234567890&ticketid=[Ticket: Number]">Click to view your ticket!</a>

Login via Email Token (Passwordless)

The passwordless feature allows for a backup login method incase Active Directory or SSO login fail. All they need is an email address so users can receive a token to login in their inbox.

To enable the Passwordless feature, open the Admin portal and head to System > Mail Token > Passwordless

Simply tick the Enable Passwordless box and save your settings.  From this screen you can also change the DeskDirector Name which is referenced in the email to the client. DeskDirector will however automatically use the DeskDirector name you have configured at the client in this email.

This is also where you configure the email address the email will be sent from. This could be a valid address or a "no-reply" type address.

Setting up Company's Email Domain

Passwordless supports adding the email domain[s] for that client. This will be used as a method to determine which company the user works for and is critical in ensuring contacts are created under the correct company/account in your PSA, if we cannot find a contact with a matching email address.

  1. For each of your clients, under the Companies tab, search for their company, and click their name.
  2. In the window that follows, enter their email domain (e.g. deskdirector.com) and click Add then save. You can add multiple domains for a company if required.
Logging in an email token

Users will be given a dialog to enter their email where they will receive their login token:

  1. User enters their email address
  2. Select Sign in using email token.
  3. An email will be sent to that email address with a temporary token.  They can either click Login Now from the email, or copy the token and paste it into the login dialog.  The token only lasts 10 minutes, so make sure they need to complete this step quickly to ensure there are no issues.
  4. Optionally, if the token never arrives or expires they can click Resend token

The diagram below shows the login process when Passwordless is enabled.

Note the importance of having an email domain or Domain SID configured for your clients to ensure they are always able to login regardless of whether they exist or not.
4. User login flow diagram

Once this is completed the user will be logged in.

Login in via Password

To set a password for a contact, navigate to the Admin portal and head to Portal > Contacts. From here, simply search for the contact whose password you wish to add or reset. Once in the Profile page for the specific contact, scroll down to the Password section and click on "Set New Password".

Alternatively, users can also initiate a password reset from the DeskDirector Portal login screen themself. All they need to do is initiate a login and select sign-in with a password. They should be greeted by a login screen where they can enter their password.

Just click on the "Reset password" link and they will be prompted to send a password reset email. Follow the on-screen instructions and they should be all set.

 After setting/resetting the password, the user can now try logging in with his username and password.

Password Requirements

DeskDirector uses zxcvbn created by DropBox to enforce password strength. In short, we calculate how fast it is to brute force your password and give it a score based on that. The longer it takes to brute force, the better. This will be shown in 5 levels:

  • 0: Very weak
  • 1: Weak
  • 2: So-so
  • 3: Good
  • 4: Great

We currently accept passwords level 2 or above.

Saved Passwords

Passwords are not saved in plaint text. This means if our database were ever to be compromised, the stored, salted password hashes would still be useless to an attacker. You can read from Salted Password Hashing - Doing it Right. This helps in particular with rainbow table attacks.

For example, if single password requires a year to decrypt, then it is not cost effective for an attacker to do so. This also provides a buffer time for users to change their password.

The salt that added to the password hashing, helps protect from rainbow attack. Where attacker cannot use a list of commonly used password to guess the value of hashed value.

Password strength

Password strength is another hot topic related to passwords. Developers of applications often setup rules to help users strengthen their password.

Many of us have definitely encountered these rules before. You're able to use your own name, date of birth, phone, address etc, but are limited on how the password is built. Does that help? No. The primary reason why passwords easily brute forced by attackers is because Your Password is Too Short!

Do special characters and numbers inside passwords help? Certainly, that means for each character there are more options. But when a rule is defined, it is actually easier for the attacker to guess. They now know exactly what is possible and what is not possible. Less valid options means less guess work. Someone may argue that password rules were created by a security expert, so why move away? The Guy Who Invented Those Annoying Password Rules Now Regrets Wasting Your Time.

As a rule of thumb, the factors below determine how fast a computer can crack a user's password:
-
The length of password
- Character restrictions (allow any character including accents, emoji, or non-Latin writing systems like hangul, kana/kanji or hanzii.)
- User profile related data (username, email, phone, address etc.)

Hopefully this article gives better understanding on DeskDirector's password system.

Frequently Asked Questions

"Am I already using the new OAuth?"

Open your Admin portal and head to System > Authentication > Client Portal Office 365 Single Sign-On. When using a custom application, you will see the Custom Application and Redirect URL input fields filled. If these are empty, you are using new OAuth.

New OAuth:

​Center

Old OAuth (via Custom Application):

"How do I switch to new OAuth?"
If this is your first time using the new OAuth implementation, an administrator from each customer's tenancy will need to grant permissions to DeskDirector on first login. This can be performed ahead of your cutover. See our above.
  1. Login to your Desk Director Admin Portal and head to System > Authentication > Client Portal Office365 Tab.
  2. Select Delete Custom Application from the drop down arrow.
  3. Make sure the custom application text box is blank and "Allow Office365 Single Sign-On" is ticked.
  4. Press Save
"Why did DeskDirector deprecate custom application OAuth?"

Custom application was never a legitimate way to perform OAuth. The application should be owned by the software service provider, not by customer. From legal point of view, the responsibility of reading user profile data should be taken by DeskDirector. From usability point of view, we also came to a point where it wasn't feasible to maintain. As we expand our offerings, there are many settings we have to adjust and this caused significant growing pains. We also found secret maintenance to be a major concern for our clients.

"What is the issue with secret maintenance?"

Application secrets should be short lived, thus Microsoft has been limiting secret lifetimes to maximum of 2 years. They also introduced asymmetric key to replace secrets. As we keep improve the security, we will eventually move to use asymmetric key rather than secret. As such, maintenance costs for both DeskDirector and our customers was too high.

"Will DeskDirector remove Custom Application anytime soon?"

We don't have any specific date been setup, the feature has been deprecated on 15th of Jun 2023. We do not provide any support for old OAuth at this stage, however, and will only assist in moving to new OAuth.

"Do we need to adjust anything for this deprecation?"

No, everything should be working as intended, even if we remove the custom application, we will based on existing setup to auto enable default SSO. The only impact will be the end user might encounter consent to view their profile.

"How do we minimize impacts of migrating to new OAuth?"

You can perform admin consent to grant DeskDirector read user profile access for a specific tenant. You can perform that under company profile page or authentication page. Admin consent will not grant DeskDirector access to list users in the tenant. It only allow auto-approve consent when a specific user of that tenant request it.

User.Read, openid, email and profile. You can check what to expect in Microsoft's documentation. During authentication, our application will only ask to read user's profile through User.Read, where openid, email and profile are for the desktop application to authenticate users. It uses OAuth's openid to read user's profile to find things like their primary email.

How did we do?

Custom Branding

Contact