ServiceNow ticketing system integration
ServiceNow is a cloud-based issue tracking system. Safeguard for Privileged Passwords can exchange the following ticket types with ServiceNow:
- 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 Safeguard for Privileged Passwords. 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.
Ticket workflow
- The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
- 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:
- Safeguard for Privileged Passwords 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.
- If the ticket is not active, the request is denied.
- 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.
Ticket workflow
- The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
- 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:
- Safeguard for Privileged Passwords 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.
Ticket workflow
- The Security Policy Administrator creates an access request policy that requires the requester to provide a ticket number when creating an access request.
- 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:
- 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 SPS 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 60: Value detail
IPv4
No reverse DNS lookup will be performed. No scheme or port values are considered. |
10.5.33.37192.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:73342001:0db8:85a3:0:0:8a2e:0370:73342001:db8::1:0:0:12001:db8::2:12001: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.corpprimary.spp.contoso.corpwidget.contoso.corpwidget |
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/8172.16.0.0/12192.168.0.0/1676.240.155.0/24fd12:3456:789a:1::/64fd00::/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 Safeguard for Privileged Passwords 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 SPS to Safeguard for Privileged Passwords, the host name or IP address of the SPS 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.