NC State ServiceNow

We will assist your organization with the process of scanning your network, discovering relevant assets and capturing that information as Configuration Items (CI).

Starting the CMDB Discovery process

Send a request to oit_cmdb_mgmt@help.ncsu.edu. Once the CMDB Discovery Prerequisites have been collected, the discovery process will start.

Terminology (links to ServiceNow documentation)

Multisource CMDB Discovery (Tokyo) - ServiceNow Cloud Discovery finds applications and devices on your network, then updates the Multisource CMDB
MID server (Tokyo) - The Management, Instrumentation, and Discovery (MID) Server runs as a Windows service or UNIX daemon on a server in your local network.
Configuration Management Database (Tokyo) - CMDB video (2017) - Creates and maintains the logical configurations that your infrastructure needs to support a ServiceNow service.
Configuration Item (CI) - Any computer, device, software, or service in the CMDB. A CI's record will include all of the relevant data, such as manufacturer, vendor, location, etc. Configuration items can be created or maintained either using tables, lists, and forms within the platform, or using the Discovery application.

CMDB Discovery Prerequisites

Configure Firewall access setup to Production and Development MID Server(s):
- Reference docs for ServiceNow required ports (Tokyo))
- TCP port access - These ports are defined in the "SNOW_Discovery_CMDB" port group
- Allow MID servers access to target hosts
  - Production ---- snowdismidprod.oit.ncsu.edu - 10.36.1.63
  - Development - snowdismiddev.oit.ncsu.edu - 10.36.1.64
  - Test ------- snowdismidtst.oit.ncsu.edu - 10.36.1.68
- New ServiceNow accounts for customers will be added to the credential_admin group in ServiceNow Development, Test and Production

Credential Requirements for Discovery of a host

Windows credential requirements (Tokyo)
- Domain User with local Admin privileges - The account "Wolftech\wt-cmdb-adi.svc" has already been created for this purpose, or a new one can be created. It is configured with local Admin privileges.
- admin$ share access
- PowerShell access
- Membership in the Distributed COM Users local security group
- Account configured in the credentials must have local admin access
- Non-domain systems must have a local Administrator account
- Domain credentials must be used for remote access if User Account Control is active.
- If using software firewall, access to the WMI service in the current namespace and subspaces
- Example settings in ServiceNow

Unix/Linux Credential Requirements (Tokyo)
- Secure Shell (SSH) – SSH credentials require either :
  - A standard SSH user
  - A private key (with an optional pass phrase)
- Individual commands that require SUDO access are outlined on links below.
- NCSU CLS Config for SSH Key Account Discovery (Google doc)
- Example settings in ServiceNow

Using SSH keys for authentication from MID server to host being discovered
- Supported MID server cryptographic algorithms (Tokyo)

Using SSH keys as credentials for ServiceNow Discovery in Windows
- Additional setup on Windows hosts is required to use SSH keys
- Configuring SSH key authentication in Windows (KB0020363)

SNMP Discovery
- 'Read Only' string is required for network based devices (Routers/Switches/Printers/UPS/PDU)
- SNMP Credential Requirements (Tokyo)
- Show settings in ServiceNow: OIT ComTech SNMP Account

VMWare Discovery
- The vCenter credential is a read only user that queries the vCenter API and identifies
  - a running process
  - a discovered vCenter appliance.
- VMWare Credential Requirements (Tokyo)
- Show example settings in ServiceNow: Campus IT - Libraries vCenter Account

Cloud Service accounts - your managed cloud infrastructure.
- Amazon Web Services (AWS)
- Microsoft Azure
- Google Cloud Platform (GCP)
- Show example settings in ServiceNow: OIT Windows Services (WMS) Azure Service Account

Scope of discovery

Servers, VMs, network appliances, network storage and cloud data centers. As these devices are discovered, configuration items (CI) will be created.

Host information

Provide the information on the hosts to be discovered
- Host names, IP addresses (preferred) or network ranges for the devices to be discovered
- Linux or Windows
Define the owner/group responsible for managing the details of a CI. This information will help us define the business rules for how the assets are managed
- Owned By - user that is responsible/CI owner?
- Change Group - which group is responsible for change management
- Support Group - group responsible for incidents involving an asset (CI)
- Managed by - assigned a default based on class (Linux vs Windows) at a particular location.

Excluding test hosts from discovery

These are typically test systems that may only exist for short periods of time or whose configuration may not match that of the corresponding production host(s)
The current way to exclude hosts from CMDB Discovery is through the use of the "CMDBDiscovery" tag category in VMWare.
If a host should not be captured for CMDB Discovery, the "CMDBDiscovery" category should be populated with the tag value "CMDBExclude".

Adding the CMDBExclude tag

1. Log into vSphere
2. Select the VM object
3. Right click the VM name and select "Tags and Custom Attributes" OR when viewing the asset, select "Tags and Custom Attributes" from the 3 line menu in the upper left corner
4. Select "Assign Tag"
5. Click in the "TagName" header to sort by tag name, then navigate to the tag "CMDBExclude"
6. Click in the checkbox next to "CMDBExclude"
7. Click Assign

Discovery Testing and Verification

Initial Discovery will be conducted in the Development NCSU ServiceNow instance using the Development Mid Server.

Development instance : https://ncsudev.service-now.com/

Signoff/Approval by stakeholders

Once successful discovery is verified on the development instance, the discovery schedules will be re-created on the production instance and re-tested.

Production instance : https://ncsu.service-now.com/