One Identity Safeguard for Privileged Sessions 8.0 LTS

Use the /ldaptest endpoint to test whether your LDAP server configuration was successful and the connection between the LDAP server and SPS can be established. You can identify connection issues based on the specific error messages received (for example, unsuccessful authorization due to incomplete credentials).

URL

GET https://<IP-address-of-SPS>/api/tools/ldaptest

Cookies

Cookie name	Description	Required	Values
session_id	Contains the authentication token of the user	Required	The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API. NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format).

Sample request

The following command lists endpoints for testing LDAP server availability.

curl -k -X GET -b "${COOKIE_PATH}" https://<IP-address-of-SPS>/api/tools/ldaptest

Response

The following is a sample response received when LDAP test endpoints are listed.

For more information on the meta object, see Message format.

{
     "items": [
       {
         "key": "aaa",
         "meta": {
           "href": "/api/tools/ldaptest/aaa"
         }
       },
       {
         "key": "policies",
         "meta": {
           "href": "/api/tools/ldaptest/policies"
         }
       }
     ],
     "meta": {
       "aaa": "/api/tools/ldaptest/aaa",
       "href": "/api/tools/ldaptest",
       "parent": "/api/tools",
       "policies": "/api/tools/ldaptest/policies",
       "remaining_seconds": 600
     }
   }

Operations

Operations with the /ldaptest endpoint include:

Operation	HTTP method	URL
List endpoints for testing LDAP server availability	GET	/api/tools/ldaptest
Testing a LDAP server	POST	/api/tools/ldaptest/policies
Testing an AAA LDAP server	POST	/api/tools/ldaptest/aaa

Example: Testing LDAP server connection

To test your connection to a LDAP server, you have to

Authenticate to SPS. For more information, see Authenticate to the SPS REST API.

List the available LDAP servers that you have previously configured.

curl -k -X GET -b "${COOKIE_PATH}" https://<IP-address-of-SPS>/api/configuration/policies/ldap_servers

Select the key of the LDAP server that you want to test.

Use the key to test whether you can connect to the LDAP server.

curl -k -X POST -H "Content-Type: application/json" -b "${COOKIE_PATH}" https://<IP-address-of-SPS>/api/tools/ldaptest/policies --data '{"key": "200796612861e564724534a"}'

Response

The following is a sample response received when you test your connection to a LDAP server.

For more information on the meta object, see Message format.

{
     "meta": {
       "href": "/api/tools/ldaptest/policies",
       "ldap_server": "/api/configuration/policies/ldap_servers/200796612861e564724534a",
       "parent": "/api/tools/ldaptest",
       "remaining_seconds": 600
     },
     "success": true
   }

Example: Testing AAA LDAP server connection

To test your connection to an AAA LDAP server, you have to

Authenticate to SPS. For more information, see Authenticate to the SPS REST API.

List the available AAA LDAP servers that you have previously configured.

curl -k -X GET -b "${COOKIE_PATH}" https://<IP-address-of-SPS>/api/configuration/aaa/ldap_servers

Select the key of the AAA LDAP server that you want to test.

Use the key to test whether you can connect to the AAA LDAP server.

curl -k -X POST -H "Content-Type: application/json" -b "${COOKIE_PATH}" https://<IP-address-of-SPS>/api/tools/ldaptest/aaa --data '{"key": "200796612861e564724534a"}'

Response

The following is a sample response received when you test your connection to an AAA LDAP server.

For more information on the meta object, see Message format.

{
     "meta": {
       "href": "/api/tools/ldaptest/policies",
       "ldap_server": "/api/configuration/aaa/ldap_servers/200796612861e564724534a",
       "parent": "/api/tools/ldaptest",
       "remaining_seconds": 600
     },
     "success": true
   }

Elements of the response message body include:

Element	Type	Description	Notes
success	boolean	Indicates that the connection to the provided LDAP server could be established.	Possible values are: true - the test was successful false - the test was not successful
meta.href	string (relative path)	Path of the resource that returned the response. When creating a new object, this is the URL of the created object.
meta.ldap_server	string (relative path)	Identifier of the LDAP server that was tested.
meta.parent	string (relative path)
meta.remaining_seconds	integer	Time left until the session times out in seconds.	SPS closes idle sessions after a period of inactivity. This value shows the number of seconds left until the timeout. For more information on setting the session timeout, Login settings.

HTTP response codes

HTTP response codes comprise of standard or endpoint-specific HTTP status and error codes. The following table lists the endpoint-specific HTTP response codes for this request.

HTTP response code	Status/Error	Description
400	TransactionMustBeClosed	The user attempted to test a LDAP server while a transaction was open (for example, there were pending configuration changes while the test was attempted). Commit or roll back the transaction before testing the LDAP server.
400	NoSuchLDAPServer	There are no LDAP servers configured with the identifier specified in the request: --data '{"key": "<invalid value>"}' Make sure that you use a valid key from the list of configured LDAP servers. This can also occur if you attempt to test an AAA LDAP server using the /ldaptest/policies endpoint or vice versa.
400	LDAPServerWithNoBindPassword	You can connect to a LDAP server using a bind DN (bind_dn) and a bind password (bind_password). These credentials are used for authentication. Normally, you need both credentials to make a successful connection, so that access to the LDAP server can be controlled. Some LDAP servers might be configured to allow so-called anonymous connections, meaning that there is no access control whatsoever and anybody can connect to that server. To test such a connection, there must be no credentials configured for that LDAP server. valid: a bind_dn and a bind_password are both configured, or there is no bind_dn and no bind_password invalid: there is a bind_dn, but no bind_password, or there is a bind_password, but no bind_dn
400	LDAPServerWithNoBindDn	See LDAPServerWithNoBindPassword.
500	LDAPConnectionFailure	Something went wrong during testing the connection. The most common reason would be an incorrect server address/port, DNS resolution failure, firewalls, or a damaged networking cable. Make sure that the configured address/port is reachable from SPS.

For more information and a list of standard HTTP response codes, see Application level error codes.

General connection settings

Channel policy

The channel policy lists the channels (for example, terminal session and SCP in SSH, Drawing, Clipboard in RDP) that can be used in a connection. The channel policy can further restrict access to each channel based on the IP address of the client or the server, a user list, user group, or a time policy. For example, all clients may access the servers defined in a connection via SSH terminal, but the channel policy may restrict SCP access only to a single client. The policies set in the channel policy are checked when the user attempts to open a particular channel type in the connection.

Channel policies are protocol specific. To list the available Channel policies for a protocol, use the following command.

curl --cookie cookies.txt https://<IP-address-of-SPS>/api/configuration/<http|ica|rdp|ssh|telnet|vnc>/channel_policies

The following sections detail the properties of Channel policy objects.

URL

GET https:<IP-address-of-SPS>/api/configuration/<http|ica|rdp|ssh|telnet|vnc>/channel_policies/<object-id>

Cookies

Cookie name	Description	Required	Values
session_id	Contains the authentication token of the user	Required	The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API. NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format).

Sample request

The following command lists the properties of a specific RDP Channel policy object.

curl --cookie cookies.txt -https:<IP-address-of-SPS>/api/configuration/<rdp>/channel_policies/<object-id>

Response

The following is a sample response received, showing the properties of Channel policy objects.

For more information on the meta object, see Message format.

{
  "body": {
    "name": "terminal-only",
    "rules": [
      {
        "actions": {
          "audit": true,
          "content_policy": null,
          "four_eyes": false,
          "ids": false
        },
        "allowed_for": {
          "clients": [],
          "gateway_groups": [],
          "remote_groups": [],
          "servers": [],
          "time_policy": {
            "key": "-100",
            "meta": {
              "href": "/api/configuration/policies/time_policies/-100"
            }
          }
        },
        "channel": "#drawing"
      },
      {
        "actions": {
          "audit": true,
          "four_eyes": false,
          "ids": false
        },
        "allowed_for": {
          "clients": [],
          "gateway_groups": [],
          "remote_groups": [],
          "servers": [],
          "time_policy": {
            "key": "-100",
            "meta": {
              "href": "/api/configuration/policies/time_policies/-100"
            }
          }
        },
        "channel": "cliprdr"
      }
    ]
  }
}

Element		Type	Description
name		string	Top level element, the name of the object. This name is also displayed on the SPS web interface. It cannot contain whitespace.
rules		list of JSON objects	Top level element, contains the configuration properties of the object.
	actions	JSON object	The actions that SPS performs for the channel, for example, recording the traffic into an audit trail.
	allowed_for	JSON object	Specifies the access control rules of the channel, for example, permitted target IP addresses or usergroups.
	channel	string	The type of the channel. Note that channels are protocol specific, and different type of channels can have different parameters. For details on HTTP-specific channels, see HTTP channels. For details on Citrix ICA-specific channels, see ICA channels. For details on RDP-specific channels, see RDP channels. For details on SSH-specific channels, see SSH channels. For details on Telnet-specific channels, see Telnet channels. For example: "channel": "#drawing",

Element		Type	Description
actions		JSON object	The list of actions to perform when the Content policy matches the analyzed traffic. All actions are boolean values (true or false)
	audit	boolean	Set to true to record the activities of the channel into audit trails. Possible values: true or false
	content_policy	JSON object	Specifies the Content policy to use in the channel, otherwise its value is null (which is the default). For details on Content policies, see Real-time content monitoring with Content Policies For example: "content_policy": { "key": "<object-id>", }
	four_eyes	boolean	Set to true to require four-eyes authorization to access the channel. For details, see Configuring four-eyes authorization in the Administration Guide. Possible values: true or false

Element		Type	Description
allowed_for		JSON object	Specifies the access control rules of the channel.
	clients	list	To restrict the availability of the channel only to certain clients, list the IP address or network of the clients allowed to use this the channel. For IPv6 addresses, use the canonized format of the address. For example: "clients": [ "192.168.1.1/24", "2001:db8:85a3::8a2e:0:0/32" Alternatively, you can also enter a hostname instead. One Identity Safeguard for Privileged Sessions (SPS) saves the hostname and resolves it when opening channels, therefore SPS can trace dynamic IP addresses. NOTE: Note the following limitations: The Domain Name Servers you set must be able to resolve the hostnames you enter into the clients and servers fields, otherwise this function (and, therefore, the sessions using this Channel Policy) will not work. SPS Channel Policies support wildcard characters in the *.example.com format. If the channel opening request contains an IP address, SPS uses a reverse lookup method to resolve this IP address into a hostname for a match. SPS uses the Domain Name Servers set in the /api/configuration/network/dns endpoint to resolve the hostnames.
	gateway_groups	list	You can control channel access during gateway authentication with blacklists or whitelists of user groups. You can use local user lists on SPS, or LDAP groups. To use this option, you must also configure web gateway authentication in the connection policy, or client-side gateway authentication back-end in the authentication policy. For example: "gateway_groups": ["group1", "group2"], To configure local user lists, see User lists.
	remote_groups	list	You can control channel access during authentication to the remote server with blacklists or whitelists of user groups. You can use local user lists on SPS, or LDAP groups. For example: "remote_groups": ["group1", "group2"], To configure local user lists, see User lists.
	servers	list	To restrict the availability of the channel only to certain servers, list the IP address or network of the servers that your clients are allowed to access using this the channel. For IPv6 addresses, use the canonized format of the address. For example: "servers": [ "192.168.1.1/24", "2001:db8:85a3::8a2e:0:0/32" Alternatively, you can also enter a hostname instead. One Identity Safeguard for Privileged Sessions (SPS) saves the hostname and resolves it when opening channels, therefore SPS can trace dynamic IP addresses. NOTE: Note the following limitations: The Domain Name Servers you set must be able to resolve the hostnames you enter into the clients and servers fields, otherwise this function (and, therefore, the sessions using this Channel Policy) will not work. SPS Channel Policies support wildcard characters in the *.example.com format. If the channel opening request contains an IP address, SPS uses a reverse lookup method to resolve this IP address into a hostname for a match. SPS uses the Domain Name Servers set in the /api/configuration/network/dns endpoint to resolve the hostnames. Alternatively, you can configure a custom DNS server to be used for target selection custom_dns field of the Connection Policy.
	time_policy	JSON object	Specifies the Time policy to use in the channel. If you do not want to restrict access, use the default 7x24 policy-100. For details on Time policies, see Time policy. For example: "time_policy": { "key": "-100", }

Policies

List of endpoints for configuring policies and settings that can be referenced when configuring connections.

URL

GET https://<IP-address-of-SPS>/api/configuration/policies

Cookies

Cookie name	Description	Required	Values
session_id	Contains the authentication token of the user	Required	The value of the session ID cookie received from the REST server in the authentication response, for example, a1f71d030e657634730b9e887cb59a5e56162860. For more information on authentication, see Authenticate to the SPS REST API. NOTE: This session ID refers to the connection between the REST client and the SPS REST API. It is not related to the sessions that SPS records (and which also have a session ID, but in a different format).

Sample request

The following command lists the available endpoints.

curl --cookie cookies.txt https://<IP-address-of-SPS>/api/configuration/policies

Response

The following is a sample response received when listing the available configuration endpoints.

For more information on the meta object, see Message format.

{
  "items": [
    {
      "key": "aa_plugin_instances",
      "meta": {
        "href": "/api/configuration/policies/aa_plugin_instances"
      }
    },
    {
      "key": "analytics",
      "meta": {
        "href": "/api/configuration/policies/analytics"
      }
    },
    {
      "key": "archive_cleanup_policies",
      "meta": {
        "href": "/api/configuration/policies/archive_cleanup_policies"
      }
    },
    {
      "key": "audit_policies",
      "meta": {
        "href": "/api/configuration/policies/audit_policies"
      }
    },
    {
      "key": "backup_policies",
      "meta": {
        "href": "/api/configuration/policies/backup_policies"
      }
    },
    {
      "key": "content_policies",
      "meta": {
        "href": "/api/configuration/policies/content_policies"
      }
    },
    {
      "key": "credentialstores",
      "meta": {
        "href": "/api/configuration/policies/credentialstores"
      }
    },
    {
      "key": "indexing",
      "meta": {
        "href": "/api/configuration/policies/indexing"
      }
    },
    {
      "key": "ldap_servers",
      "meta": {
        "href": "/api/configuration/policies/ldap_servers"
      }
    },
    {
      "key": "signing_cas",
      "meta": {
        "href": "/api/configuration/policies/signing_cas"
      }
    },
    {
      "key": "time_policies",
      "meta": {
        "href": "/api/configuration/policies/time_policies"
      }
    },
    {
      "key": "trusted_ca_lists",
      "meta": {
        "href": "/api/configuration/policies/trusted_ca_lists"
      }
    },
    {
      "key": "user_databases",
      "meta": {
        "href": "/api/configuration/policies/user_databases"
      }
    },
    {
      "key": "userlists",
      "meta": {
        "href": "/api/configuration/policies/userlists"
      }
    },
    {
      "key": "usermapping_policies",
      "meta": {
        "href": "/api/configuration/policies/usermapping_policies"
      }
    }
  ],
  "meta": {
    "first": "/api/configuration/aaa",
    "href": "/api/configuration/policies",
    "last": "/api/configuration/x509",
    "next": "/api/configuration/private_keys",
    "parent": "/api/configuration",
    "previous": "/api/configuration/plugins",
    "transaction": "/api/transaction"
  }
}

Endpoint	Description
aa_plugin_instances	Authentication and Authorization plugin policies
analytics	Analytics.
archive_cleanup_policies	Archive/Cleanup policies.
audit_policies	Audit trail encryption, timestamping, and signing.
backup_policies	Backup policies.
content_policies	Actions for detected commands, screen content, credit card information, and window titles.
credentialstores	Local and external credential stores.
indexing	Languages for Optical Character Recognition (OCR).
ldap_servers	LDAP servers.
signing_cas	Signing CAs for generating the server-side certificates on the fly. You can use such CAs in SSL-encrypted RDP sessions, RDP sessions that use Network Level Authentication (CredSSP), or SSH connections that use X.509-based authentication. To configure signing for audit trails, use the audit_policies endpoint.
time_policies	Time policies.
trusted_ca_lists	Trusted Certificate Authorities (CAs), and options for restricting the accepted certificates.
user_databases	Local User Databases are available for RDP, SSH and Telnet protocols, and can be used to authenticate the clients to credentials (passwords, public keys, and certificates) that are locally available on SPS.
userlists	Local white- or blacklists of usernames that allow fine-control over who can access a connection or a channel.
usermapping_policies	Usermapping policies describe who can use a specific username to access the remote server.

Status and error codes

The following table lists the typical status and error codes for this request. For a complete list of error codes, see Application level error codes.

Code	Description	Notes
401	Unauthenticated	The requested resource cannot be retrieved because the client is not authenticated and the resource requires authorization to access it. The details section contains the path that was attempted to be accessed, but could not be retrieved.
403	Unauthorized	The requested resource cannot be retrieved because the client is not authorized to access it. The details section contains the path that was attempted to be accessed, but could not be retrieved.
404	NotFound	The requested object does not exist.

One Identity Safeguard for Privileged Sessions 8.0 LTS - REST API Reference Guide

Testing LDAP server connection

URL

Cookies

Sample request

Response

Operations

Example: Testing LDAP server connection

Response

Example: Testing AAA LDAP server connection

Response

HTTP response codes

General connection settings

Detailed information about this topic

Channel policy

URL

Cookies

Sample request

Response

Policies

URL

Cookies

Sample request

Response

Status and error codes

Seleccione su producto:

Con el fin de ofrecerle un mejor servicio, complete el campo Motivo del chat:

Soluciones recomendadas para su problema

One Identity Safeguard for Privileged Sessions 8.0 LTS - REST API Reference Guide

Testing LDAP server connection

URL

Cookies

Sample request

Response

Operations

Example: Testing LDAP server connection

Response

Example: Testing AAA LDAP server connection

Response

HTTP response codes

General connection settings

Detailed information about this topic

Channel policy

URL

Cookies

Sample request

Response

Policies

URL

Cookies

Sample request

Response

Status and error codes