> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.itential.com/adapters/configure/reference/nso/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server. # NSO adapter > Reference for configuring the NSO adapter, including adapter properties, sample configuration, itential-tools compatibility, external authentication, NACM rules, NETCONF events, SSL, and LSA setup. The NSO adapter connects to NSO using the web UI port and NETCONF port. Each time the NSO adapter establishes a connection to NSO, the adapter reads the service models advertised by NSO. To securely configure the NSO adapter, ensure the HTTP hostname is configured with the same hostname in the common name of the NSO server certificate. * NSO must be installed on a server that Itential Platform can access. * NSO does not need to be installed on the same server as Itential Platform. * Refer to the [NSO Version Support policy](/cisco-nso/supported-versions). See [Cisco NSO Service Manager](/cisco-nso/overview) for more information. ## Adapter properties | Property | Type | Description | | --------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `http.host` | String | Host address of the NSO web interface. | | `http.port` | Number | Host port of the NSO web interface. | | `ssl.enabled` | Boolean | Use HTTPS instead of HTTP for relevant protocols (JSON-RPC and RESTCONF). The `http.host` and `http.port` properties still determine which host/port is used. Does not affect NETCONF connections. | | `ssl.acceptInvalidCerts` | Boolean | Accept invalid certificates. | | `ssl.caFile` | String | Certificate Authority file. | | `ssl.ciphers` | String | SSL ciphers. | | `netconf.host` | String | Host address of NSO NETCONF. | | `netconf.port` | Number | Host port of NSO NETCONF. | | `netconf.protocol` | String | Protocol used for NETCONF transactions. | | `netconf.frame_size` | Number | NETCONF frame size to use. Default: `16736`. | | `authenticationStrategy.type` | String | Set to `dynamic`. | | `authenticationStrategy.location` | String | Set to `NSO`. | | `authenticationStrategy.method` | String | Set to either `tokenLogin` or `machineLogin`. | | `credentials.user` | String | NSO login account username. | | `credentials.passwd` | String | NSO login account password. | | `commitWait` | Number | Maximum timeout for a commit, in seconds. | | `commitQueue` | Boolean | Whether commit queues will be enabled by default. | | `poolSize` | Number | The default pool size. | | `yangDirs` | Array of Strings | Directories to scan for YANG. Supports the `*` wildcard. Only required when connecting to NSO versions earlier than 4.5.2. | | `max_reconnect_attempts` | Number | The maximum number of times Itential Platform will try to connect to NSO before stopping. If both `max_reconnect_attempts` and `total_reconnect_window` are configured, whichever condition is met first sets the effective limit. Set to `0` to continue connecting indefinitely using a back-off algorithm. | | `total_reconnect_window` | Number | A maximum reconnect window in minutes. If both `max_reconnect_attempts` and `total_reconnect_window` are configured, whichever condition is met first sets the effective limit. Set to `0` to enforce no time window. | | `min_reconnect_interval` | Number | Seconds to wait after an NSO down event is detected before the first reconnection attempt. This value is doubled for each subsequent attempt until `max_reconnect_interval` is reached. | | `max_reconnect_interval` | Number | When NSO becomes unavailable, Itential Platform starts its reconnect timer at `min_reconnect_interval`. If the first attempt fails, the timer doubles each time. The process continues until the timer reaches or exceeds `max_reconnect_interval`, at which point all future reconnect attempts occur at this frequency. | | `netconfSubscriptions` | Array of Strings | List of NETCONF streams in NSO to listen for NETCONF events. | | `entity_cache_TTL` | Number | Hours that device metadata entries are stored in the entity cache. Default: `24`. Set to `0` to disable device information caching. | | `max_cache_entries` | Number | Maximum number of device metadata entries stored in the entity cache. Default: `5000`. | ## Sample configuration Configure at minimum the following properties before deploying: * `http.host` * `http.port` * `ssl.enabled` * `ssl.caFile` * `ssl.ciphers` * `netconf.host` * `netconf.port` * `credentials.user` * `credentials.passwd` The default configuration uses `machineLogin` for all transactions. To enable individual user authorization handled by NSO, NSO must be configured with an external authentication script capable of returning external group memberships for a given user ID. Ensure NSO is configured for external authentication and set `authenticationStrategy.method` to `tokenLogin`. ```json { "id": "nso", "type": "NSO", "properties": { "http": { "host": "localhost", "port": 8888 }, "ssl": { "enabled": true, "acceptInvalidCerts": false, "caFile": "/etc/ssl/ca.cert", "ciphers": "DHE-RSA-AES256-SHA" }, "netconf": { "host": "localhost", "port": 2022, "protocol": "ssh", "frame_size": 16736 }, "credentials": { "user": "admin", "passwd": "admin" }, "authenticationStrategy": { "type": "dynamic", "location": "NSO", "method": "machineLogin" }, "netconfSubscriptions": [ "ncs-events", "ncs-alarms", "device-notifications", "service-state-changes" ], "commitWait": 30000, "commitQueue": false, "max_reconnect_attempts": 0, "total_reconnect_window": 120, "min_reconnect_interval": 30, "max_reconnect_interval": 900, "entity_cache_TTL": 24, "max_cache_entries": 5000, "poolSize": 3, "yangdirs": [] } } ``` ## itential-tools package compatibility with NSO To support various versions of Cisco NSO, Itential offers two packages: `itential-tools` and `itential-tools-nso6.4`. If you have access to the `itential_tools` repository in Nexus, you can access both packages and choose which to install based on your NSO version. ### itential-tools `itential-tools` is compatible with NSO versions: 5.6.x, 5.7.x (LTS), 5.8.x, 6.0.x, 6.1.x (LTS), 6.2.x, and 6.3.x. ### itential-tools-nso6.4 `itential-tools-nso6.4` is built specifically to support NSO 6.4 and above. If you are using NSO 6.4 and above with `itential-tools-nso6.4`, you must use one of the following minimum versions of `adapter-nso`: * Platform 6.0.3 or later * 2023.2.14 or later * 2023.1.34 or later ### itential-tools in the Nexus repository The Nexus repository contains two folder types: `itential_tools` and `itential_tools-64`. Each folder contains the assets and components necessary for Itential Platform to interact with NSO. ![](/_fern-img/16cb5b389c369ca71724b792d6641a1ec2c1644a0357474f4ce6a939bd46850c.webp) **itential-tools 1.23.x** supports Cisco NSO 5.6.x, 5.7.x (LTS), 5.8.x, 6.0.x, 6.1.x (LTS), 6.2.x, and 6.3.x. ![](/_fern-img/b15abba77cf4010ff9339bb0679ca4b4b58cf6c1a3f0094ac23f8dd11ac544fb.webp) **itential-tools-64** supports Cisco NSO 6.4.x and above, and contains `itential-tools-64-1.23.48` as the first package release. ![](/_fern-img/c0692246c157173d52d191aec7fb2ecf7a2cf002cc29f2848bf77b866b072044.webp) ### Download from the Nexus repository #### Change to the NCS packages directory ```bash cd /var/opt/ncs/packages ``` #### Extract the itential-tools package ```bash tar xzf itential_tools_VERSION.tgz ``` #### Run make in the src directory ```bash cd itential-tools/src && make clean all -s && cd - ``` #### Reload packages using ncs\_cli ```bash ncs_cli -u admin -C --noaaa > package reload ``` ## NSO external authentication installation To use external authentication, install the `ph-auth` script and configure the `ncs.conf` file. The NSO external authentication script requires Python and the `requests` module. Network connectivity is required between NSO and Itential Platform (typically port 3000). #### Install Python and the requests module ```bash yum install -y python python-pip pip install requests ``` #### Configure the external authentication script Locate the script at: ```bash /var/opt/ncs/packages/itential-tools/external_auth ``` #### Set the Itential Platform hostname and port ```bash PH_ADDRESS = "localhost" PH_PORT = "3000" ``` #### Test the external authentication script ```bash python /var/opt/ncs/packages/itential-tools/external_auth/ph-auth.py ``` #### Verify the script rejects test credentials Type the following and press Enter: ```bash [test;test;] ``` You should receive: ```bash reject ``` ## NSO external authentication configuration Configure the `ncs.conf` file to use external authentication. Both `external-authentication` and either `local-authentication` or PAM should be enabled. Itential Platform initially connects using a global service account with admin privileges. When performing transactions that can bind a request to a human user account, Itential Platform makes calls on behalf of a specific user (for example, `bobjones` instead of `admin`). ```bash vi /etc/ncs/ncs.conf ``` ```xml ${NCS_CONFIG_DIR}/ssh false system-auth true /var/opt/ncs/packages/itential-tools/external_auth/ph-auth.py false prompt ``` Restart NSO: ```bash service ncs restart ``` ### Configure default authgroup mappings If the `tokenLogin` feature of the NSO adapter will be used, verify that users properly map to the appropriate southbound credentials. Ensure credentials are configured for the default `umap` inside NSO. Run this command for each authentication group, applying the appropriate device credentials as `remote-name` and `remote-password`: ```bash ncs_cli -u admin -C config devices authgroups group default default-map remote-name admin remote-password admin commit ``` ## NSO NACM rules To use Itential Platform with an NSO NETCONF Access Control Model (NACM) implementation, reference the sample set of NACM rules provided with this package. The NACM rules assume the following groups model: | Group | Description | | ----------- | ------------------------------------------------------------------------------- | | `pronghorn` | A NACM group applied to the user the NSO adapter uses when connecting with NSO. | | `users` | A NACM group applied to the user the NSO adapter uses when connecting with NSO. | | `admins` | A NACM group applied to administrators of the system. | These groups are shared across both Itential Platform and NSO. Using the sample external authentication script, Itential Platform provides the set of groups defined inside Itential Platform and discovered from the configured AAA system to NSO, to be applied to the NACM rule-lists. The set of groups returned by the NSO AAA provider must properly match NACM rule-list group assignments. The following rule-lists are provided in the sample rules: | List | Description | | ------------------ | --------------------------------------------------- | | `pronghorn-system` | Applied to the Itential Platform `pronghorn` group. | | `pronghorn-users` | Applied to the Itential Platform user groups. | | `admins` | Applied to `pronghorn` and `admins` groups. | Adjust the groups associated with these rule-lists to ensure they are mapped to the correct user accounts. ### Install NACM rules in NSO Load `sample-nacm-rules.xml` into the NSO CDB using the `load merge` feature of `ncs_cli`: ```bash ncs_cli -u admin -C config load merge sample-nacm-rules.xml commit dry-run commit ``` ### Configure device whitelists The sample NACM rules contain a rule-list for whitelisting devices to the users group. Configure the sample rule-list or create your own to associate devices with groups of users: ```bash ncs_cli -u admin -C config nacm rule-list whitelist-devices rule permit-device-mydevicename path /devices/device[name='mydevicename'] action permit commit ``` In a NACM-enabled system, any new device added must have its groups defined at the time of device turn-up. This applies to both manual configuration in NSO and device turn-up workflows. ### Configure service whitelists The sample NACM rules contain a rule-list for whitelisting service instances to the users group. Add all service instances for a model to the users whitelist: ```bash ncs_cli -u admin -C config nacm rule-list whitelist-services rule permit-service-cisco-ios path /services/cisco-ios action permit commit ``` To add a single instance instead: ```bash ncs_cli -u admin -C config nacm rule-list whitelist-services rule permit-service-cisco-ios-101 path /services/cisco-ios[vlan=101] action permit commit ``` In a NACM-enabled system, any new service instance added must have its groups defined. Service instances may be restricted to an individual group or made accessible to multiple groups with the appropriate NACM rules. ## NSO NETCONF events in workflows Configure workflows in Itential Platform to wait for Cisco NSO northbound NETCONF event notifications before proceeding. Cisco NSO emits notifications over NETCONF for various events. The NSO adapter can be configured to listen to NSO NETCONF event streams, and the Itential Platform Event System can consume and process these events within a workflow. ### Configure NSO NETCONF event streams Event streams are configured in NSO within the `ncs.conf` file. NSO allows the following event streams: * `ncs-alarms` * `ncs-events` * `device-notifications` * `service-state-changes` * `NETCONF` This example configures an `ncs-alarms` event stream inside `ncs.conf`: ```xml ncs-alarms NCS alarms according to tailf-ncs-alarms.yang false false ./state S10M 50 ``` Every stream that is configured must be defined within `ncs.conf` regardless of whether it supports replay. NSO logs notifications, and a NETCONF client can request logged notifications if replay support is enabled. ### Configure the NSO adapter to listen to NETCONF streams Define which NSO NETCONF event streams to subscribe to using the `netconfSubscriptions` property in the adapter properties. Restart the NSO adapter after updating the adapter properties. The `netconfSubscriptions` values should correspond to the desired NSO NETCONF streams defined in `ncs.conf`. Example `adapter-nso` properties with `netconfSubscriptions` defined: ```json { "id": "NSO", "type": "NSO", "properties": { "netconfSubscriptions": [ "ncs-events", "ncs-alarms", "device-notifications", "service-state-changes" ], "http": { "host": "localhost", "port": 8080 }, "netconf": { "host": "localhost", "port": 2022, "protocol": "ssh" }, "ssh": { "port": 22 }, "credentials": { "user": "admin", "passwd": "admin" }, "commitWait": 5000, "commitQueue": false }, "groups": [], "brokers": [ "device", "method", "service" ] } ``` ### Workflow configuration The Workflow Engine `eventListener` task is used to listen for events from applications and adapters deployed inside the platform. ![](/_fern-img/8d5cfc3556f2818ef7ee4c0152c488fb9ff22839bdd31c44055af935c8f71bd9.webp) Refer to the **eventListenerJob task reference** for more information. When a job is created, it processes all the tasks it can. Upon reaching the `eventListener` task, the job waits in a `running` state until it receives an event. The event it waits for is configured within the task itself. ![](/_fern-img/12f92c763d558b65fd09bea74b10369edd549d078513bad8f8a0fb7d8c11f68c.webp) ### Event Listener inputs | Input | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Event Source | The application or adapter that will publish the event. For NSO notifications, the NSO adapter is the source. As the adapter is deployed in the `@itential` namespace, provide the fully qualified source location — in most cases `@itential/adapter-nso`. If you have multiple NSO adapters deployed, specify the correct adapter. | | Event Topic | The name of the topic to which the event will be published. For NETCONF, this is the name of the event stream. | | Event Schema Filter | A JSON schema that configures the task to execute only when the received event contains specific data matching the schema filter. When the event is captured, the event payload is compared with the JSON schema, and the task only processes if there is a match. | #### Event schema filter examples This example processes the `eventListener` task only when the following payload is received: ```json { "eventTime": "2019-09-19T18:56:14.227091+01:00", "plan-state-change": { "service": { "_": "/l3vpn:l3vpn-simple-svc[l3vpn:name='IAP']" }, "component": "self", "state": { "_": "ncs:init" }, "operation": "created", "status": "reached" } } ``` The JSON schema for the **Event Schema Filter**: ```json { "type": "object", "properties": { "eventTime": { "type": "string", "default": "2019-09-19T18:56:14.227091+01:00", "examples": ["2019-09-19T18:56:14.227091+01:00"], "format": "date-time" }, "plan-state-change": { "type": "object", "properties": { "service": { "type": "object", "properties": { "_": { "type": "string", "default": "/l3vpn:l3vpn-simple-svc[l3vpn:name='IAP']", "enum": ["/l3vpn:l3vpn-simple-svc[l3vpn:name='IAP']"] } }, "required": ["_"], "additionalProperties": false }, "component": { "type": "string", "default": "self", "examples": ["self"] }, "state": { "type": "object", "properties": { "_": { "type": "string", "default": "ncs:init", "examples": ["ncs:init"] } }, "required": ["_"], "additionalProperties": false }, "operation": { "type": "string", "default": "created", "examples": ["created"] }, "status": { "type": "string", "default": "reached", "examples": ["reached"] } }, "required": ["service", "component", "state", "operation", "status"], "additionalProperties": false } }, "required": ["eventTime", "plan-state-change"], "additionalProperties": false } ``` If you do not need to filter on the payload and only want the task to execute when it receives a specific **Event Topic**, set an empty JSON object `{}` in the **Event Schema Filter** field. ## Itential Tools Rules Engine The Itential Tools Rules Engine allows users to define scripts that execute prior to NSO command-sets being run. These scripts modify (add or change) values in the NSO command-sets before execution. The rules engine has two parts: a rule engine and a script engine. The script engine reads the script files defined for the command that is passed in, reads in the defined rules, then passes the rules to the rule engine for processing. The following files are required: | File | Name | Description | | ------------ | -------------------------- | ----------------------------------------------- | | Command file | `dl_command.json` | Associates the command name to the script name. | | Rule script | `.dls` | Defines the script. Generated by the user. | ### Development tools and libraries The main framework for the Java-based application is the Java Spring framework. | Testing tool | Description | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Mockito](https://site.mockito.org/) | A mocking framework for unit testing. | | [TestNG](https://testng.org/) | A testing framework inspired by JUnit and NUnit, designed to cover all categories of testing. Supports annotations and concurrent testing. Requires JDK 7 or higher. | ### System design The Itential Tools Rules Engine has three functional areas: Script Engine, Rule Engine, and Script Validation Engine. ![](/_fern-img/cbb66bc2dd4dfe9ee263ba333427ea40979200e2da1cb097047730783f674265.webp) **Script Engine** — The main driver for script processing. It receives the command file containing the request to modify the NSO command-set, locates the command to get the script file to execute, reads in the script file, calls the rule engine to process the rules, modifies the NSO command-set appropriately, and returns the modified command-set. Errors are handled and returned to the calling system. **Rule Engine** — Responsible for processing each rule. Input parameters are the rule and the NSO command-set. Output is the modified NSO command-set. Steps: receive parameters, determine which rule to process, perform the rule process and modify the command-set, return the modified command-set, and handle errors by passing them back to the Script Engine. **Script Validation Engine** — Validates that the script has the correct format and that commands are valid with the correct number of parameters. If any validation fails, a custom Java exception is thrown with the appropriate error message and code. | Validation | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------- | | Parameter (required) | Script name. | | Checks | Each command must be terminated with a semicolon. Each command is validated for a valid number of parameters. | ### Validation commands **`$DLC_REPLACE`** — Four parameters: 1st (Any String), 2nd (Any String), 3rd (Int), 4th (Int). **`$DLC_INSERT`** — Five parameters: 1st (Any String), 2nd (Any String), 3rd (Before or After), 4th (Int), 5th (Int). ### Rule command format and usage | Usage | Format | | ------------- | --------------------------------------------------------------------- | | Replace | `$DLC_REPLACE("original string","new string", occurrence, num)` | | Insert Before | `$DLC_INSERT("original string","new string",BEFORE, occurrence, num)` | | Insert After | `$DLC_INSERT("original string","new string",AFTER, occurrence, num)` | ### Arguments | Argument | Description | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `original string` | What the command is looking for. | | `new string` | What will be added. Supports escape characters: `\t` (tab), `\n` (new line), `\r` (return). Also supports `$STRING` and `$LOOP` options described below. | | `occurrence` | The starting position of the original string before the rule begins executing. For example, if there are three instances of the original string and occurrence is `2`, the command starts processing at instance two. | | `num` | Number of times the action occurs — `0` means all. For example, if there are 4 matches and `occurrence=3`, then only the third and fourth are replaced. `num` works in conjunction with `occurrence`: if `occurrence=3` and `num=3`, only two replacements occur. | ### Supported options within the "new string" argument **`$STRING`** Syntax: `$STRING['my string'|'2nd string'|'3rd string']` A single value or an array of strings separated by a pipe (`|`) that will be printed out. An array causes a loop. **`$LOOP`** Syntax: `$LOOP[{start}-{end}|$STRING['{string to print out}']$LOOP_VAR]` Parameters: `{start}` (starting int), `{end}` (ending int), `{string to print out}` (any string), `$LOOP_VAR` (the current loop iteration integer). Multiple references to `$LOOP_VAR` are supported. **Example:** ```js $DLC_INSERT("access-list","new text here",AFTER,1); $DLC_INSERT("access-list","new text here",BEFORE,1); $DLC_INSERT("","\n$LOOP[1-100|$STRING['vlan ']$LOOP_VAR]\n",AFTER,1,1); $DLC_INSERT("","\n$STRING['my string'|'2nd string'|'3rd string']\n",BEFORE,1,1) ``` ### Implementation design Implementation of the Rules Engine includes: integration into the current `itential-tools` Java application, a mechanism to refresh the command list without restarting `itential-tools`, an option to bypass the refresh, and the ability for users to update commands and scripts. | Feature | Description | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Refresh command list | The command list is re-read every time command processing is executed. | | Bypass option | A configuration parameter `bypassRuleEngine` can be defined for `itential-tools`. If not passed, the default value is `TRUE`, which bypasses this feature. | | Update command/script by user | In the first release, all commands/scripts are manually created, edited, and copied to the installed location. No UI is available for script manipulation in the initial release. | **Rule Engine integration** — Include the Java jar file generated by the Rule Engine application in the `private-jar` or `shared-jar` directory to build the `itential-tools` application. Import the `com.itential.datalore_utils.ScriptEngine` package into the calling class: ```js import com.itential.datalore_utils.ScriptEngine; ScriptEngine scriptEngine = new ScriptEngine(sCommand, sNSOCommandSet); try { sNSOCommandSet = scriptEngine.processCommand(); } catch (Exception e) { e.printStackTrace(); } ``` ## Configure NSO for SSL ### NSO SSL configuration #### Upload certificates to the NSO host Upload NSO host and CA X.509 certificates to the NSO host `$CERT_DIR`. #### Copy the private key and signed certificate ```bash NCS_CONFIG_DIR=/etc/ncs cp $NSO_SERVER_PRIV_KEY $NCS_CONFIG_DIR/ssl/cert/host.key cp $CERT_DIR/$NSO_SERVER_CERTIFICATE $NCS_CONFIG_DIR/ssl/cert/host.cert ``` #### Trust the CA certificate The following instructions apply to a CentOS 7 host: ```bash cp $CA_SELF_SIGNED_CERT /etc/pki/ca-trust/source update-ca-trust ``` #### Edit the configuration file ```bash /etc/ncs/ncs.conf ``` #### Enable SSL for NSO REST and JSON RPC APIs ```xml true 0.0.0.0 8888 ${NCS_CONFIG_DIR}/ssl/cert/host.key ${NCS_CONFIG_DIR}/ssl/cert/host.cert ``` #### Enable NETCONF ```xml true true 0.0.0.0 2022 false 127.0.0.1 2023 ``` #### Restart NSO Refer to Cisco NSO Admin and Installation guides for detailed instructions on NSO SSL configuration. ### Itential Platform NSO SSL configuration #### Upload the CA certificate to the Itential Platform host ```bash CERT_DIR=/etc/ssl/certs CA_SELF_SIGNED_CERT=${CERT_DIR}/certificate_authority.crt NSO_HOST=nso-hostname ``` #### Update the NSO adapter configuration Update your desired NSO adapter under **Settings > Services > Adapters** with the following configuration: ```json { "loggerProps": { "description": "Logging", "log_max_files": 10, "log_max_file_size": 10485760, "log_level": "debug", "log_directory": "/var/log/pronghorn", "log_filename": "my_nso.log", "log_timezone_offset": 0, "console_level": "info", "syslog": { "level": "info", "host": "10.1.0.211", "port": 1514, "protocol": "udp4", "facility": "local0", "type": "BSD" } }, "isEncrypted": true, "model": "@itential/adapter-nso", "name": "my_nso", "type": "Adapter", "properties": { "id": "my_nso", "type": "NSO", "properties": { "http": { "host": "nso-hostname", "port": 8888 }, "ssl": { "enabled": true, "acceptInvalidCerts": false, "caFile": "/etc/ipa/ca.crt", "ciphers": "ECDHE-RSA-AES128-GCM-SHA256" }, "netconf": { "host": "nso-hostname", "port": 2022, "protocol": "ssh" }, "ssh": { "port": 22 }, "credentials": { "user": "nso_user", "passwd": "nso_pass" }, "authenticationStrategy": { "type": "dynamic", "location": "NSO", "method": "tokenLogin" }, "commitWait": 5000, "commitQueue": false, "max_reconnect_attempts": 0, "total_reconnect_window": 0, "min_reconnect_interval": 30, "max_reconnect_interval": 900 }, "groups": [], "brokers": ["device", "method", "service"] } } ``` To identify the preferred cipher for your SSL handshake, run the following command from the Itential Platform server: ```bash openssl s_client -connect NSOServer.com:8080 ``` In the example output below, the preferred cipher is `ECDHE-RSA-AES128-GCM-SHA256`: ``` SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 1A1D51D03BFB624A617626DCEEDACAF6AD0317DF9C34DF7F55802BAA776EC112 Master-Key: 4B7827941C Start Time: 1595966521 Timeout : 7200 (sec) Verify return code: 0 (ok) ``` ## NSO LSA (Layered Service Architecture) setup The following principles apply to the NSO adapter in an LSA architecture: * Itential does not support multiple NSO instances having **devices** of the same name. Only one NSO instance manages a given device, and no other devices use that exact same name. * Itential does not support multiple NSO instances having **service models** of the same name/path. Only one NSO instance manages a given service model. For the following LSA architecture — an "upper" NSO service with service models defined, and one or more "lower" NSO services connected to devices — set up Itential Platform as follows: 1. Create an `adapter-nso` instance and point it to the upper node. 2. Create an additional `adapter-nso` instance for every lower node. With this setup, you can use service models (for example, with tasks such as `saveInstances`) and perform device management (for example, with Configuration Manager). NSO can also utilize an Itential Platform broker to further support this setup. When an app task like `saveInstances` is used, you provide the device name to the task. The Itential Platform broker queries all `adapter-nso` instances to see which one has that service model and uses that adapter instance. The same principle applies to tasks that directly interact with devices — for example, the golden config feature in Configuration Manager uses a broker to determine which `adapter-nso` instances manage which device. > Reference for configuring the NSO adapter, including adapter properties, sample configuration, itential-tools compatibility, external authentication, NACM rules, NETCONF events, SSL, and LSA setup.