Credentials

On this page

Introduction

In Service Desk, credentials are configured with information that vouches for the identity of a person through some method of trust and authentication. Credentials need to be set up only once.

Using credentials:

You can ensure the quality of the information you receive from Discovery scans.
Administrators can set up and use credentials for process integrations based on authentication method.

See Available authentication protocol types and required information.

Navigation

ITSM customers	ESM customers
Setup > Account > Credentials	IT Service Provider > Setup > Account > Credentials

Use Credentials for Discovery

SolarWinds recommends the use of credentials for Discovery. With credentials, you can collect the most information possible.

Credentials are used in subnet and router scans. For integration scans, such as SCCM, vCenter, AWS, or SolarWinds Platform, see Connections. When you don't use credentials, the quality of the information you receive from a scan is dependent on what is available with no credentials. For example, if a unique identifier for a device is not available, the device could be dropped. See Credentials for Discovery.

Use Credentials for Process Integrations

Process integration allows you to integrate with third-party applications to use a target for commands within your automated workflows. When you set up integration you can reuse it for many workflows.

Process integrations in Service Desk allow you to connect with third-party applications and execute commands as part of your automated workflows. These integrations rely on credentials to authenticate and authorize access to external systems.

Adding a new process integration is easy. When you're finished, it becomes an available source to connect your workflows when building service catalog items, change catalog items, or runbooks. Integrations can be configured to perform actions such as creating users, updating records, or retrieving data from external systems.

ESM customers are limited to adding process integrations to service catalog items only. They can add existing process integrations previously created by the IT service provider. See Manually create a new process workflow.

Why Use Credentials?

Using credentials ensures secure and reliable communication with external systems. Without credentials, integrations may fail or return incomplete data due to access restrictions.

Benefits of Credentialed Integrations

Security. Credentials ensure that only authorized systems and users can access sensitive data.
Reusability. Once configured, credentials can be reused across multiple workflows and integrations.
Scalability. Easily manage and update credentials from a central location.

Available credential types are described at Credential types for Process Integrations.

Also see Process integrations.

All Credentials index page

The All Credentials index page contains these columns:

Name (click to open credential details and edit): The name assigned to the credential
Where used: The number of connections or integrations using the credential
Type: The credential type; for example, SNMP, SSH, OAuth2, or another type
Last update: The most recent date and time the credential was updated

The table below explains the columns on the All Credentials index page.

Column	Description
NAME	It is important to select a meaningful name that assists you in defining your environment. Click on the name to modify and add a description. You can also update the credentials here. The required details are dependent on the Credential Type. SNMPv3 requires a Username, Authentication Protocol, Authentication Key, Privacy Protocol, and Privacy Key SSH Password only requires a Username and Password.
WHERE USED	Describes the number of subnets and the number of network devices associated to each subnet. For process integrations, it specifies the number of integrations associated with the credential.
TYPE	The selected type of the created credential.
LAST UPDATE	Provides the date and time of the last change.
ACTIONS	When hovering over the row, a trash bin displays. You may delete the credential as long as it is not currently in use.

You can customize the All Credentials index page to a view that best meets your needs. See List view for more information.

Create a new credentials set

These two facts about Service Desk credential sets are important to know:

The information stored in credential sets is very sensitive and should never be shared with others via any method.

Credentials are not used unless they are associated with a connection or a process integration.

Navigate to Setup > Account > Credentials.
Click Add and select the appropriate authentication method from the dropdown list.
Enter the required* information.

Create a meaningful name, add a description (optional), add an authentication URL, and create or update the token path. Additionally, you can use the body and headers to provide information such as an OAuth 2.0 Client ID and/or Client Secret.

Required information varies based on the selected authentication protocol method/type. Rely on each vendor's instructions to gather the information you need for creating credential sets in Service Desk.

Examples for authentication method/type OAuth 2.0

For more information on OAuth 2.0, see OAuth 2.0 prerequisites and additional information.

Example 1: Service Desk credentials for Zoom

A use case guide is available providing instructions on how to Obtain Zoom meeting details via bi-directional process integration with OAuth 2.0 credentials.

Example 2: Service Desk credentials for Microsoft Entra ID

Changes to the token path or headers may affect existing integrations. Always test changes in a non-production environment first.

See Connections or Process integrations.

Delete credentials

A credentials set can only be deleted when not in use.

Available authentication protocol types and required information

Authentication methods/types are used differently in Service Desk based on whether they are to facilitate Discovery scans or for Process integrations.

Credential types for Discovery scans

Credential types for Discovery scans
Method/Type	Use	Required information	Optional information
SNMP v1/v2c	Used to access network devices like routers, printers, and switches	Name Community	Description
SNMPv3	Used for scanning network devices like, printers, routers, and switches	Name Username Authentication Key Privacy Key	Description Authentication Protocol (None, MD5, or SHA) Privacy Protocol (None, DES, AES, or AES256)
SSH Credentials Key	Used to authenticate users and hosts on the Secure Shell (SSH) network protocol. Required information allows greater visibility into the subnet.	Name Username SSH Private Key	Description
SSH Credentials (username and password)	Used to authenticate users and hosts on the Secure Shell (SSH) network protocol. Required information allows greater visibility into the subnet.	Name Username Password	Description
Although it is not mandatory, SolarWinds highly recommends providing descriptions so you can better understand your network.

Credential types for Process integrations

Credential types for Process integrations
Method/type	Use	Required information	Optional information
User and Password	A set of unique identifiers that allow a user to log in to a digital system	Name Username Password	Description
OAuth 2.0 See OAuth 2.0 prerequisites and additional information.	Used to grant third-party applications access to a user's protected resources without sharing the user's long-term credentials. See RFC 6749.	Name Authentication URL	Description Update Token Path (Show button to view or edit the Token Path. Modifying this setting will affect your integration connection. Changes will only be applied after you save them.) Additional Headers (You can add headers.)
Web Token	Temporary keys that verify a user's identity and allow them to access a website or application.	Name Token	Description Additional Headers (Custom headers for your process integration API call.)
Bearer Token	Used to grant access to a resource or service in authentication protocols like OAuth 2.0.	Name Token	Description Additional Headers (Custom headers for your process integration API call.)

OAuth 2.0 overview, prerequisites, and other useful information

Oauth 2.0 overview

SolarWinds strongly recommends that you have a good understanding of OAuth 2.0 and how it works. Although very secure, it is also complicated.

OAuth 2.0 is an industry-standard protocol for authorization that allows users to grant third-party applications access to their data or services without revealing their credentials. It is primarily used to delegate access to protected resources; not for the initial authentication of users.

OAuth 2.0 is used for authorization, not authentication. It verifies that a user or application has permission to access a resource, but it does not confirm the user's identity.

You can learn more and watch videos at OAuth2.0.net. You can also see the Internet Engineering Task Force (IETF) request for comment regarding the OAuth 2.0 Authorization Framework at RFC 6749.

Prerequisites

Before configuring OAuth 2.0 credentials in Service Desk, ensure the following:

You have a solid understanding of how OAuth 2.0 works.
You have access to the third-party application’s developer portal or documentation.
You have obtained the necessary credentials from the vendor, such as:
- Client ID – Identifies your application to the vendor and tells the vendor who you are.
- Client Secret – Authenticates your application with the vendor (like a password). It tells the integrated vendor that you are authorized to connect because your secret matches the one in vendor's account, like a password.

Key concepts

Term	Description
Client ID	A public identifier for your application.
Client secret	A confidential key used to authenticate your application.
Authentication URL	The endpoint where the OAuth 2.0 flow begins.
Token path	The endpoint used to retrieve or refresh the access token.
Headers/Body	Optional fields where you can include additional metadata or credentials.

To set up a process integration with Service Desk, OAuth 2.0 requires that you provide vendor credential information, such as a Client ID and a Client secret used to log into a vendor account, for example, Microsoft Entra ID.

When you log into the vendor account, the vendor authenticates that you are an authorized user, and then generates a token. You will likely need to provide the token during creation of the Service Desk credential set.

Refer to your vendor’s documentation for specific requirements. Each vendor may require different parameters or formats for OAuth 2.0 setup. Required elements for each vendor can be different because the vendor specifies what information is required, and where and how you provide that information. For example, some vendors might require the Client ID in the URL, while others might require a different method. Always refer to the vendor's documentation to ensure you set up credentials correctly.

Search SolarWinds Support