What do I do when an appliance goes into quarantine
Safeguard for Privileged Passwords appliances can end up in a quarantine state if something goes wrong while doing certain activities. The best defense against losing data or compounding problems associated with quarantined appliances is a good and recent backup. At least one appliance in the Safeguard for Privileged Passwords cluster should be scheduled to periodically generate a backup and send it to an archive server. For more information, see Backup and Retention.
Recovering from a quarantine state
- Follow these steps to create a quarantine bundle from the Recovery Kiosk. For more information, see Recovery Kiosk (Serial Kiosk).
-
Prior to using the Quarantine Bundle function, set up a Windows share where the quarantine bundle is to be sent.
- From the Recovery Kiosk, select the Support Bundle option, click the right arrow, and select Quarantine Bundle.
- Enter the following information:
- Address: Enter the address of the Windows share (<IP Address>\<ShareName>) where the support bundle is to be saved.
- If the Windows share is not anonymous, enter the User name and Password or SSH Key.
- Click Copy to Share.
- You can now restart the appliance. Often, a quarantine happens because the system was waiting for a response that did not return in time. Restarting the appliance allows it to retry and frequently fixes itself.
- To restart a quarantined appliance, connect to the Recovery Kiosk for that appliance and restart it from there. Once the appliance has restarted, it will take several minutes for Safeguard for Privileged Passwords to start.
-
If you attempt to connect to the appliance using the web client while Safeguard for Privileged Passwords is starting, you will get notified of HTTP Error 503. Once the log in service is running you will be presented with a log in screen, but will not be able to proceed until the appliance has proceeded further. Once the appliance has booted out of the quarantine state, you will be able to log in and proceed as normal. At this time you should generate a support bundle. If the appliance remains in a quarantine state, the web client will continue to get HTTP Error 503.
If the web client cannot display the login screen, contact One Identity Technical Support and report the result.
To remove a quarantined appliance from a cluster
You may want to remove a quarantined appliance from a cluster.
- First try to unjoin the replica appliance from the cluster. For more information, see Unjoining replicas from a cluster.
- If unjoining the appliance fails, reset the cluster to remove the appliance from the cluster. For more information, see Resetting a cluster that has lost consensus.
Considerations for a factory reset of a hardware appliance
|
Caution: Care should be taken when performing a factory reset against a physical appliance, because this operation removes all data and audit history, returning it to its original state when it first came from the factory. Performing a factory reset will NOT reset the BMC/IPMI interface or the IP address. However, the BMC/IPMI interface will need to be reenabled after the reset has completed (for more information, see Lights Out Management (BMC)). The appliance must go through configuration again as if it had just come from the factory. For more information, see Setting up Safeguard for Privileged Passwords for the first time.
In addition, performing a factory reset may change the default SSL certificate and default SSH host key.
The appliance resets to the current Long Term Support (LTS) version. For example, if the appliance is running version 6.6 (feature release) or 6.0.6 LTS (maintenance Long Term Support release) and then factory reset, the appliance will reset down to 6.0 LTS and you will have to patch up to your desired version. For more information, see Long Term Support (LTS) and Feature Releases. |
One Identity Technical Support can determine if a factory reset is necessary. If a factory reset is the last option, you will need to contact Support to complete the operation.
-
To perform a factory reset, connect to the Recovery Kiosk and select the Factory Reset option. For more information, see Factory reset from the Recovery Kiosk.
Once the factory reset is started, you must wait until it finishes (it could take up to 30 minutes to complete). When the factory reset is complete, the kiosk will return an Online indicator.
-
Once the factory reset is complete:
- Re-configure the network interface settings.
- Patch to your desired Safeguard for Privileged Passwords version using the required patching path.
- If this appliance will be the primary for the cluster, upload and restore the most recent backup. For more information, see Restore a backup.
- If this appliance will be a replica in a cluster, there is no need to restore a backup. Join the appliance to your cluster. For more information, see Enrolling replicas into a cluster.Safeguard for Privileged Passwords will take care of replicating all the data back to the appliance.
When does the rules engine run for dynamic grouping and tagging
Dynamic account groups are associated with rules engines that run when pertinent objects are created or changed. For example:
- Whenever you add or change an asset account, all applicable rules are reevaluated against that asset account.
- Whenever you change an asset account rule, the rule is reevaluated against all asset accounts within the scope of that rule. In other words, the rule is reevaluated against all asset accounts for grouping and the asset accounts within the designated partitions for tagging.
You can create a dynamic account group without any rules; however, no accounts will be added to this dynamic account group until you have added a rule.
In large environments, there is a possibility that the user interface may return before all of the rules have been reevaluated and you may not see the results you were expecting. If this happens, wait a few minutes and Refresh the screen to view the results.
Related topic:
Adding a dynamic account group
Why did the password or SSH key change during an open request
There are three ways a password or SSH key can change while a user has it checked out.
- An Asset Administrator manually changes the password or SSH key. See: Checking, changing, or setting an account password or Checking, changing, or setting an SSH key.
- A profile was scheduled to automatically change the password or SSH key. See: Change Password or Change SSH Key settings.
- A policy allows both simultaneous access and requires that the password or SSH key change when a user checks it in.
If the password or SSH key changes while a user has it checked out, and the current request is still valid, the user can select either Copy or Show Password or Show SSH Key again to obtain the new password.
Appendix A: Safeguard ports
Safeguard for Privileged Passwords requires port availability for various system operations.
Port details
Safeguard network port details are in the following table.
Table 218: Safeguard ports
|
MGMT |
TCP |
HTTPS used for a secure first-time configuration of the appliance. The IP address is a fixed address that cannot be changed. It is available in case the primary interface becomes unavailable.
Typically used: TCP/443 and IP address: 192.168.1.105 |
Base operation |
25 |
TCP |
SMTP: Simple Mail Transfer |
Base operation |
53 |
TCP / UDP |
DNS (Domain Name Server) |
Base operation |
123 |
|
NTP time synchronization |
Base operation |
88 |
UDP |
For communication with Active Directory, Safeguard uses port 88 (for example, Kerbos authorization against Active Directory). |
Base operation: AD Asset and Account Discovery, password check and change |
389 |
TCP/UDP |
LDAP used for Active Directory Asset Discovery and Directory Accounts Discovery. The standard global catalog port, 3268 (LDAP), must be open on the firewall for every Windows global catalog server in the environment and SPP Appliance to communicate for directory management tasks (for example, adding a directory account, a directory user account, or a directory user group). LDAP uses port 389 for unencrypted connections. For more information, see the Microsoft publication How the Global Catalog Works.
For basic functionality when changing an OS account password, the following ports are required:
- Windows Active Directory: TCP/389 and TCP/445
- Windows, Windows Desktop: TCP/445
Also see:
|
Base operation (password and SSH key check and change) |
445 |
TCP SMB |
NetLogon Service (NP-In) is used to perform:
- Password check and changes for Windows Active Directory
- Password and SSH key check and changes for Windows, Windows Desktop.
Also see port 389 and Preparing Windows systems |
LDAPS |
636 |
|
Supported for non-AD LDAP providers. The default LDAPS port is 636. Port 636 needs to be open to use LDAPS for non-AD LDAP providers. |
WMI |
135
(49152-
65535
Windows) |
TCP |
The firewall must be configured to allow Windows Management Instrumentation (WMI) for computer name and other lookups. WMI is also required if SPP performs any of the functions listed below on any Windows machine (whether it be a dependent system or a normal target platform):
- Managing service account passwords
- Managing scheduled task passwords
- Restarting a service
- Using Account Discovery on the target
WMI / DCOM from DPA will need access to TCP/135 to initiate communication on the target. The conversation continues on a random negotiated port. On Windows 7 and Windows 2008 (and above) this is in the range: 49152 - 65535.
To limit the ports used by WMI/DCOM, refer to these Microsoft articles:
For Windows Active Directory, if using Account Discovery or Auto Discovery CLDAP ping UDP/389 is also required. See:
|
WMI |
49152-65535 |
|
See port 135 |
SPP/SPS internal communications |
8649 |
TCP |
Used for the SPP/SPS internal communications when SPS is linked with SPP.
- SPS to SPP:
- SPS completes the link by talking to SPP on port 8649.
- SPS authenticates a new session and acquires the password from SPP by talking on port 8649.
- SPS queries SPP for cluster information and the appliance version.
- SPP to SPS:
- SPP queries SPS for cluster information and node roles.
- SPP pushes SSH host keys to SPS when a session is initiated.
- SPP queries SPS for session playback, follow mode, and session termination.
In SPS, the nodes require UDP ports 500 and 4500 and TCP 8649. For the latest detail, see the SPS Administration Guide, Enabling cluster management. |
Firewall |
655 |
UDP (X0) |
WireGuard (655) is open for secure VPN communication between appliances in a clustered high-availability configuration.
To enroll an appliance into a cluster, the appliance must communicate over port 655 UDP and port 443 TCP, and must have IPv4 or IPv6 network addresses (not mixed). If both IPv4 and IPv6 are available for the connection then IPv6 will be used. See:
|
Firewall and Client and Web browser points |
443 |
TCP
(X0) |
HTTPS over TLS/SSL (443/TCP) permits inbound requests (for client/Web/API access). Used to initially log on to the appliance to join the cluster member. Users must have access to the cluster X0 ports on port 443.
To enroll an appliance into a cluster, the appliance must communicate over port 655 UDP and port 443 TCP, and must have IPv4 or IPv6 network addresses (not mixed). If both IPv4 and IPv6 are available for the connection then IPv6 will be used. See:
The port is used to prepare VMware ESXi host. See:
|
Global catalog |
3268 |
|
The LDAP standard global catalog port for Active Directory. The standard global catalog port, 3268 (LDAP), must be open on the firewall for every Windows global catalog server in the environment and SPP Appliance to communicate for directory management tasks (for example, adding a directory account, a directory user account, or a directory user group). LDAP uses port 389 for unencrypted connections. For more information, see the Microsoft publication How the Global Catalog Works. Also see:
There are no services listening for this port on a member/server workstation (local configuration). |
Kiosk |
DB9 |
SERIAL |
To connect to the Safeguard Kiosk. See KB article 233584. |
Radius server |
1812 |
|
Default port number that a Radius server uses to listen for authentication requests. See Adding identity and authentication providers. |
SonicWALL SMA or CMS appliance |
8443 |
TCP/ UDP |
For SonicWALL SMA or CMS appliance. See information related to authenticating an asset, Password (local service account). |
SQL server |
1433 |
|
The port on which the SQL server will be listening for connections. See information related to authenticating an asset, Password (local service account). |
Telnet |
23 |
TCP |
Telnet |
Platform ports
ACF2 – 23
ACF2 LDAP – 389
AIX – 22
AWS – 443
Cent OS – 22
Cisco Pix – 22
Debian – 22
IDRAC – 22
ESXi - 443 default
F5 - 22 default
Fortinet – 22 default
Free BSD – 22
HP iLO
IBM i – 23
JunOS – 22
MongoDB - https://docs.mongodb.com/manual/reference/default-mongodb-port/
MySQL – 3306
Oracle – 1521
Oracle Linux – 1521
OSX – 22
Other – port is not supported for the platform
Other Managed - port is not supported for the platform
Linux – 22
Pan OS – 22
PostgreSQL – 5432 default
RACF – 23
RACF LDAP – 389
RHEL – 22
SAP Hana – 39013 default
SAP Netweaver – 3300
Solaris – 22
SoniOS – 22
SonicWall SMA – 22
SQL – 1433
SUSE – 22
SyBase – 5002
Top Secret – 23
Top Secret LDAP – 389
Ubuntu – 22
Windows (various depanding on OS type) – 135/389/445 and maybe dynamic ports
Archiving
Archiving uses uses SFTP/SCP and CIFS.
- SFTP/SCP: 22 TCP (X0). See the Port details table, appliance port 22 for X0.
- CIFS: Uses UDP ports 137 and 138 and TCP ports 139 and 445.
Backup
Same as Archiving.
External Authentication
Federation – Port 443
Secondary Auth – Radius Port 1812
Starling - Port 443
External Integration
SNMP – Port 162 UDP
SMTP - Port 25 TCP Simple Mail Transfer
SysLog – 514 UDP
External Integration for Password and SSH key Workflow
Cloud Assistant - 443
Ticketing – ServiceNow 443
Ticketing - Remedy 1433 (communicates to the SQL server directly)
Other
NTP – port 123 UDP
Directories – Ports 389 LDAP and 3268 global catalog