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
- Go to Ticket Systems:
web client: Navigate to 
Settings | 
External Integration | Ticket Systems.
desktop client: Navigate to Administrative Tools | Settings | External Integration | Ticket Systems.
- Click
Add to add a ticket system.
- Do the following:
- web client: Select Other and complete this information:
- desktop client: On the Ticket System dialog, enter:
- Click Validate to validate the Regular Expression entry.
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. For more information, see Creating an access request policy
- 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.
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 join 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 168: 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 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 joining Safeguard for Privileged Sessions to Safeguard for Privileged Passwords, 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:
- Go to Trusted Servers, CORS and Redirects:
- web client: Navigate to Settings| External Integration | Trusted Servers, CORS and Redirects.
- desktop client: Navigate to Administrative Tools | Settings | External Integration | Trusted Servers, CORS and Redirects.
Refresh: Update the information displayed.
- 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.
- Click OK (desktop client) or Save (web client).
desktop client: To use Messaging, see Messaging settings
desktop client only
Use the Password settings to define the profile configuration settings, including account password rules and password check and change schedules, which can then be used in profile definitions.
Navigate to Administrative Tools | Settings | Password Management.
Table 169: Profile settings
| Account Password Rules |
Where you define the complexity rules used by Safeguard for Privileged Passwords when constructing new passwords during an automatic account password change |
| Change Password |
Where you define the rules Safeguard for Privileged Passwords uses to reset account passwords |
| Check Password |
Where you define the rules Safeguard for Privileged Passwords uses to verify account passwords |
|
Password sync groups |
Where you define the password sync groups and associated accounts so Safeguard for Privileged Passwords can synchronize passwords across accounts |
