Service Desk Industry End-User Authentication Methods
The key can be retrieved either via the end user’s profile or from their MS account if it’s linked to that site. If neither of these methods work, end users can contact an authorized service desk agent who, upon verification of their identity, typically retrieves the key from the user’s AD account and relays those credentials so users can regain access. While the approach for restoring access may vary, establishing a documented authentication process that leverages the appropriate industry tools is the most efficient way to ensure information security while maintaining productivity. With such a preponderance of information, one of Information Technology’s primary roles is not only securing the data from an infrastructure management standpoint but controlling how such data is disseminated at the service desk. Particularly for organizations in the healthcare and financial industry, the disclosure of secure data is considerably regulated and, as a result, incorporated in its agreements with all IT vendors. Even for clients outside of healthcare and financial, maintaining rigid control over how secure data is accessed is an essential element of IT operations and end-user authentication is a primary component of that information security strategy. Below are some authentication methods that both the end user and service desk outsourcing provider can incorporate to streamline and strengthen their approach to data security.
Before implementing a new service desk solution, clients initially provide a list of all eligible users, often in the form of an Active Directory export. Once established, end-user contact information can be updated in electronic format either via periodic Excel import or LDAP Active Directory synchronization. For authentication, initial default passwords can be assigned when user accounts are created. In such instances, passwords are never communicated to the user by the service desk. Authentication is either seamless via Active Directory Single Sign-On (SSO), or users set their own passwords with automatic email verification upon first use. For voice contacts, service desk agents authenticate end users by verifying the response to their security question stored in Active Directory.
To elaborate, SSO enables end-user access to multiple systems without their entering multiple passwords and usernames. It’s designed to minimize the chance of incorrect login credentials and potential lockouts as well as subsequent calls to the service desk. But given the sheer number of web-based accounts most people regularly access, lockouts aren’t completely avoidable. So it’s important that all organizations establish a uniform lockout policy. Whether managed by the client or service desk’s security team, SSO configuration should specify a maximum number of failed login attempts. Such a policy should also specify how much time must elapse before the account can be unlocked except for authorized personnel with administrative access. In an Active Directory lockout scenario, service desk agents granted such access typically authenticate end users by verifying the response to their security question stored in Active Directory and cross-reference that with other predetermined fields (employee ID number, position, title, location, etc.) before unlocking their account.
If selecting a tool for self-managing user credentials, it is best to opt for one that, upon initial login, prompts users to create a password with high strength and complexity (i.e. a combination of case-sensitive alphanumeric, special characters). Creating a unique, if not randomly generated, password with high complexity will go further towards ensuring data security than the hackneyed and easily hacked “Pa55word.” For passwords of the randomly generated variety, many IT organizations use an RSA SecurID authentication mechanism that creates a six or nine digit number or token associated with a specific user. RSA tokens can be issued to end users either as hardware such as a dongle or key fob or as a software token which refreshes the digits in 60 second intervals. RSA tokens are used in conjunction with two factor authentication (i.e. credential combinations stored separately and joined at login such as password plus the token number or PIN).
According to ABS Remote Level 2 Technician Rico Feliciano, RSA token technology is not without its glitches. “Sometimes the dongles go out of synch and no longer generate the correct sequence associated with the end user’s device which prompts a call to the help desk,” says Rico. “Agents then login to the RSA console, access the user’s account in administrative mode, and select the option to resynch after verifying the serial number on the hard token.”
For mobile devices, there are a number of similar two factor authentication applications that can be installed to generate secure keys for end user access such as Microsoft Authenticator and SafeNet MobilePASS which enables a direct connection to the supported organization’s server environment.
Another security feature leveraged by MS Windows end users is the Bitlocker encryption tool. After multiple failed login attempts and a lockout, Bitlocker is activated and, upon machine reboot, prompts the end user for a 128-bit or 256-bit key. The key can be retrieved either via the end user’s profile or from their MS account if it’s linked to that site. If neither of these methods work, the end user can contact an authorized service desk agent who, upon verification of their identity, typically retrieves the key from the user’s AD account and relays those credentials so the user can regain access. While the approach for restoring access may vary, establishing a documented authentication process that leverages the appropriate industry tools is the most efficient way to ensure information security while maintaining productivity.