Chat now with support
Chat with Support

We are currently experiencing issues on our phone support and are working diligently to restore services. For support, please sign in and create a case or email supportadmin@quest.com for assistance

One Identity Safeguard for Privileged Passwords 7.4.1 - Administration Guide

Introduction System requirements and versions Using API and PowerShell tools Using the virtual appliance and web management console Cloud deployment considerations Setting up Safeguard for Privileged Passwords for the first time Using the web client Home page Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Global Services External Integration Real-Time Reports Safeguard Access Appliance Management Settings
Asset Management
Account Automation Accounts Assets Partitions Discovery Profiles Tags Registered Connectors Custom platforms Importing objects
Security Policy Management
Access Request Activity Account Groups Application to Application Cloud Assistant Asset Groups Entitlements Linked Accounts User Groups Security Policy Settings
User Management Reports Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP and SPS join guidance Appendix C: Regular Expressions

ServiceNow ticketing system integration

ServiceNow is a cloud-based issue tracking system. SPP can exchange the following ticket types with ServiceNow:

  • INC (incident) tickets
  • CHG (change) tickets
  • RITM (request) tickets
  • PRB (problem) tickets

The data items specific to ServiceNow may be optional based on your configuration.

To use ServiceNow, the root CA Certificate required for ServiceNow must be installed in SPP. For more information, see Trusted CA Certificates.. To add a trusted certificate, see Adding a trusted certificate.

Tickets can be viewed in the Activity Center, Ticket # column.

Setting up the integration

  1.  Go to Ticket Systems:
    • web client: Navigate to External Integration > Ticket Systems.
  2. Click  Add to add a ticket system.
  3. Do the following:
    • web client: Select ServiceNow.
  4. Complete the authorization information based on your installation:
    • Name: Enter the name of your ticketing system
    • URL: Enter the web site address to the ticketing system.
    • Username: Enter an account for SPP to use to access the ticketing system.
    • Password: Enter the user account's password.
    • Client Identifier: Enter the ServiceNow Client ID.
    • Client Secret: Enter the ServiceNow secret key.
  5. Click Test Connection to test the connection to ServiceNow.

Ticket workflow

  1. The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
  2. When the requester makes a request, they must enter the existing ServiceNow ticket number on the New Access Request dialog, Request Details tab, Ticket Number field. See:
  3. SPP queries all configured ticket systems to see if that ticket number represents a ticket that exists and is in an open state. For ServiceNow, Safeguard checks the Active property of the identified ticket returned from the ServiceNow API and considers the ticket number valid if the Active property is not false for that incident.
    1. If the ticket is not active, the request is denied.
    2. If the ticket is active, the access workflow continues.

Remedy ticketing system integration

You can use ticketing that is configured to work with Remedy.

Tickets can be viewed in the Activity Center, Ticket # column.

Safeguard checks the Status property of the incident returned from the Remedy API. The ticket is considered valid if Status is not Closed or Cancelled.

The data items specific to Remedy may be optional based on your configuration.

Setting up the integration

  1.  Go to Ticket Systems:
    • web client: Navigate to External Integration > Ticket Systems.
  2. Click  Add to add a ticket system.
  3. Do the following:
    • web client: Select Remedy.
  4. Complete the authorization information based on your installation:
    • Name: Enter the name of your ticketing system.
    • URL: Enter the web site address to the ticketing system.
    • Username: Enter an account for SPP to use to access the ticketing system.
    • Password: Enter the user account's password.
    • Authentication String: Enter the authentication credential for the Remedy AR (Action Request) system server.
  5. Click Test Connection verify the connection to Remedy works.

Ticket workflow

  1. The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
  2. When the requester makes a request, they must enter the existing Remedy ticket number on the New Access Request dialog, Request Details tab, Ticket Number field. See:
  3. SPP queries all configured ticket systems to see if that ticket number represents a ticket that exists and is in an open state.

Not integrated with ticketing system

You can use ticketing that is not configured with an external ticketing system to track tickets.

Tickets can be viewed in the Activity Center, Ticket # column.

Security Policy Administrators can require requesters to reference a ticket number in their password, SSH key, or session access request but not have the ticket validated against an external ticketing system but, optionally, may be validated against the regular expression of a generic ticketing system. The ticket number is used in the decision to approve the request.

Setting up ticketing

  1.  Go to Ticket Systems:
    • web client: Navigate to External Integration > Ticket Systems.
  2. Click  Add to add a ticket system.
  3. Select Other and complete this information:
  4. Click Validate to validate the Regular Expression entry.

Ticket workflow

  1. The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
  2. When the requester makes a request, they must enter a ticket number on the New Access Request dialog, Request Details tab, Ticket Number field. See:
  3. Safeguard for Privileged Passwords validates the ticket number against the regular expression. If the ticket number is an exact match to the regular expression, the workflow continues.

Trusted Servers, CORS, and Redirects

You can restrict login redirects and Cross Origin Resource Sharing (CORS) requests to a specified list of IP addresses, host names (including DNS wildcards), and CIDR notation networks. By default, a single asterisk (*) means there are no restrictions. This will allow you to easily join multiple Safeguard for Privileged Passwords appliances together to form a cluster. In addition, you will also be able to link to a Safeguard for Privileged Sessions appliance.

However, as a best practice, you should change or delete this value after configuring your cluster. It is recommended to set it to the empty string to prevent external CORS requests and login redirects to unknown servers. Or, set it to a list of known servers that integrate with the Safeguard API.

One or more values can be separated by a space, comma, or new line. Do not include the scheme, port, or path. The maximum length for the setting is 512 characters, including separators. Example values and additional details can be seen in the following table.

Table 58: Value detail

IPv4

No reverse DNS lookup will be performed. No scheme or port values are considered.

10.5.33.37

192.168.0.2

IPv6

No reverse DNS lookup will be performed. No scheme or port values are considered.

2001:0db8:85a3:0000:0000:8a2e:0370:7334

2001:0db8:85a3:0:0:8a2e:0370:7334

2001:db8::1:0:0:1

2001:db8::2:1

2001:db8::1

DNS/Host Names

Case insensitive match. No scheme or port values are considered. If using Internationalized Domain Names (IDN), you must also manually include the punycode equivalent.

spp.contoso.corp

primary.spp.contoso.corp

widget.contoso.corp

widget

DNS Wildcards

Only one level to the wildcard is allowed, just like SSL certificates. No scheme or port values are considered. If using Internationalized Domain Names (IDN), you must also manually include the punycode equivalent.

*.spp.contoso.corp

*.contoso.corp

CIDR Notation

Any DNS or host name values being validated will have DNS lookup performed to see if any resolved IP addresses are contained within any of the specified CIDR networks. No scheme or port values are considered.

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

76.240.155.0/24

fd12:3456:789a:1::/64

fd00::/8

Allow All

A single asterisk, no other values allowed.

*

Allow None

Delete all values and leave as the empty string.

 

Considerations:

  • When adding a new node to the SPP cluster, the node’s host name or IP address must be specified in this list, or enter a single asterisk to allow all.
  • When linking Safeguard for Privileged Sessions to SPP, the host name or IP address of the Safeguard for Privileged Sessions appliance must be specified in this list, or enter a single asterisk to allow all.
  • As a best practice, after clustering (or if using just a single appliance/VM), change the setting value to the empty string or a list of integration applications you wish to allow.

To set up Trusted Servers, CORS and Redirects:

  1. Go to Trusted Servers, CORS and Redirects:
    • web client: Navigate to External Integration > Trusted Servers, CORS and Redirects.
  2. Refresh: Update the information displayed.
  3. In Allow Hosts, enter the list of IP addresses, host names (including DNS wildcards), and CIDR notation networks. As mentioned above, the default is a single asterisk (*) which means there are no restrictions.
  4. Click Save (web client).
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating