Credentials (WinRM, SSH, SNMP, LDAP)

Credentials let the scanner log in to devices for full inventory, and let deployments and actions run commands. Manage them under Scanning › Credentials.

Passwords, private keys and SNMP secrets are encrypted at rest (AES-256-GCM) with a key stored outside the database (secret.key in the data directory). They are never shown again after saving. Leave a password field blank when editing to keep the stored one.

Each credential is either global (tried on every asset of its type) or mapped only (used only where you map it). See Mapping credentials.

Some credential types aren't used for scanning devices but for a sync: Active Directory (LDAP bind) and Microsoft Entra ID (Active Directory), and VMware vCenter / ESXi, Proxmox VE (API token), XCP-ng / XenServer and AWS (access key) (Hypervisors & cloud), and Configuration Manager (SCCM), Google Workspace (service account), Workspace ONE UEM, UniFi Network and Cisco Meraki Dashboard (Configuration Manager, Google Workspace, Workspace ONE, UniFi and Meraki). They are chosen on those pages and never mapped.

Mapping credentials#

You can map a credential to:

Map to	Example	Matches
Assets	raspberrypi, nas01	those assets
IP addresses	`192.168.1.50`	a device at that address (also before it was ever inventoried)
IP ranges	`192.168.1.0/24`, `10.0.0.10-10.0.0.50`, `10.0.0.10-50`	any device in the range
Domains / workgroups	`CORP`, `corp.local`, `WORKGROUP`	assets in that domain (`CORP` and `corp.local` match each other)

Where: Scanning › Credentials (Map… on a credential, or Map credential… in the Credential mapping panel), on an asset page (Scanning credentials… in the left panel, administrators), or for several assets at once on the Assets list (select them, then Map credential…).

Order. For every scan, deployment, action, screenshot or live status check over WinRM/SSH (and SNMP for devices), credentials are tried in this order:

the credential that worked on that asset last time;
credentials mapped to the asset, then its IP address, then an IP range containing it, then its domain. Within one target they're tried in the order shown in the Credential mapping panel; change it with ↑ ↓;
credentials selected on the scan target being run;
global credentials, oldest first.

Only credentials of the right type are used for each protocol (WinRM for Windows, SSH for Linux/macOS, SNMP for devices). Scanning credentials… on an asset page shows the exact list for that asset and why each credential is on it.

Global or mapped only. Untick Global when you save a credential to use it only where you map it, for example the pi account of one Raspberry Pi, or a root password for one subnet. A mapped-only credential that isn't mapped anywhere is never used; the list shows not mapped yet. Credentials created before version 0.15 are global, so nothing changes until you map or restrict them.

The credential that works is remembered per device and tried first next time.

Remote scanners#

A remote scanner at another site only receives the credentials you allow for it: Edit › Allowed on remote scanners. This applies to global credentials too. Use an account with rights at that site only, never Domain Admin. See Remote scanners › Credentials.

Global credentials and rogue devices#

Your credentials are protected in storage and on the network. They are encrypted at rest, and Windows (WinRM) and SSH logins travel over encrypted connections, so nobody listening on the network can read them.

The risk is who is at the other end of that connection. A global credential is offered to every device a scan finds, including devices you don't know yet. If someone connects a rogue device to a scanned network, or an existing device is compromised, it can pretend to be a Windows, Linux or SNMP device. It then receives the login just like a real server would, because it is the other end of the encrypted connection:

Credential	What a rogue device receives
SSH password	The password itself. SSH host keys are trusted on first use, so a device at a new address is accepted. A known device whose key changes is refused before any password is sent.
SSH private key	Nothing reusable: a key login proves possession of the key without revealing it.
Windows (WinRM, NTLM)	Not the password, but a login response that can be cracked offline if the password is weak, or relayed to another server.
SNMP v1 / v2c community	The community string. This protocol sends it unencrypted, so anyone on the network path can read it too.
SNMP v3	Much less: the passwords aren't sent, though weak ones can be guessed offline from captured traffic.

The Credentials page shows a security notice while global WinRM, SSH or SNMP v1/v2c credentials are offered to all devices.

Known devices only#

Tick Known devices only on a global credential to offer it only to devices Census has already inventoried: by the Census agent, by a scan with a mapped credential, over SNMP, or listed by VMware/Hyper-V, Intune or Azure. A device that appears out of nowhere, seen only by discovery, gets none of these credentials. New legitimate computers get their first inventory from the Census agent or a mapped credential, and from then on the global credential is used for them too. Credentials selected on a scan target are still used there (that's an explicit choice, like a mapping).

Recommended#

Tick Known devices only on global credentials, or map credentials to the assets, IP ranges or domains they belong to and untick Global.
Use SSH keys instead of passwords for Linux and macOS.
Prefer SNMP v3 with strong passwords for network devices.

SNMP v3 checklist (firewalls, switches)#

If a device's page shows SNMP: No answer from the device after a scan:

SNMP turned on and allowed from the scanner's network. Firewalls usually need SNMP enabled on the agent and allowed on the zone or interface the scan comes from (Sophos Firewall: Administration › SNMP turns the agent on, Administration › Device access ticks SNMP for the LAN zone).
The scanner's address is an authorized host. For a remote site, that's the remote scanner computer's address (shown on Scanning › Remote scanners), not the Census server's.
Queries are accepted for the SNMPv3 user (Sophos: Accept queries).
The credential's version is v3, and the username, the authentication algorithm and password and the privacy (encryption) algorithm and password match the device exactly. Census supports SHA, SHA-256, SHA-512 and MD5 authentication, and AES (128), AES-192, AES-256 and DES encryption.

A wrong password or algorithm shows the device's refusal instead (for example "refused the authentication password" or "couldn't decrypt the request").

Use least-privilege scan accounts: a dedicated account that is local administrator only on the computers it scans (set by group policy), or LAPS-managed local administrator passwords. Never Domain Admin: if a scan account is ever captured, the damage stays limited to what that account can reach.

Windows (WinRM)#

Field	Example
Username	`CORP\svc-census` (domain) or `localadmin` (local account)
Password
Transport	HTTP 5985 (traffic is encrypted with NTLM even over HTTP) or HTTPS 5986

The account needs local administrator rights on the computers.

Enabling WinRM#

Domain (recommended): create a Group Policy that enables the WinRM service (Computer Configuration › Policies › Administrative Templates › Windows Components › Windows Remote Management › WinRM Service › Allow remote server management through WinRM), sets the service to start automatically, and allows inbound TCP 5985 from the Steward IT Census server in Windows Defender Firewall.
Single computer: in an administrator PowerShell, run Enable-PSRemoting -Force -SkipNetworkProfileCheck.
Scans time out on port 5985? That's the firewall dropping the connection. If Enable-PSRemoting ran while the network was marked Public (common on a workgroup computer), Windows sets WinRM up but leaves its firewall rules off. Mark the network private (Set-NetConnectionProfile -NetworkCategory Private) and turn the rule on: Enable-NetFirewallRule -Name WINRM-HTTP-In-TCP-NoScope. Check with Get-NetFirewallRule -Name WINRM* | Select Name, Enabled, Profile.
Login refused (401) with a local administrator account? Set LocalAccountTokenFilterPolicy as described below; without it Windows refuses local accounts over WinRM even when they are administrators.

Local (non-domain) accounts#

Windows filters the admin rights of local accounts over the network (UAC remote restrictions). To use a local admin account other than the built-in Administrator, run once on each computer:

New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1 -PropertyType DWord -Force

Domain accounts are not affected.

Windows LAPS#

If your computers use LAPS (Local Administrator Password Solution), each one has its own local administrator password, stored in Active Directory. Add a credential of type Windows LAPS instead of a shared admin password:

Connect the domain under Scanning › Active Directory & Entra ID (LDAPS or StartTLS; LAPS passwords are never read over plain LDAP).
Create an LDAP credential for an account that may read LAPS passwords (for Windows LAPS: Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" -AllowedPrincipals CORP\svc-census-laps). The normal sync account usually can't.
Add a Windows LAPS credential: choose the domain and that LDAP account. Optionally name the local administrator account (Windows LAPS records it; legacy LAPS doesn't, so Administrator is assumed).
Map it to the computers, ranges or domain where LAPS is used, or make it global.

When a scan or deployment reaches the credential for a Windows computer, Census looks the computer up in AD by its name, reads its password and logs in over WinRM as COMPUTER\Administrator. The password is used for that login only and never stored.

Works with Windows LAPS without password encryption (msLAPS-Password) and legacy LAPS (ms-Mcs-AdmPwd). Windows LAPS with password encryption stores passwords that only Windows can decrypt; Census reports password encrypted in AD for those computers. Use a regular credential there, or turn off encryption for that OU.
The computer is found by its DNS name (reverse DNS), or by the name Census already knows for that address.
Not available through remote scanners yet.
Windows blocks remote logins by local accounts with UAC token filtering unless LocalAccountTokenFilterPolicy is 1 (see Local (non-domain) accounts); LAPS logins are local-account logins too.

Linux / macOS / Unix (SSH)#

Field	Example
Username	`census`
Password / key passphrase
Port	22
Private key	optional; OpenSSH or PEM format

Root rights through sudo. When the account isn't root, scans, deployments and actions run through sudo: passwordless if the account has it, otherwise with the credential's password (sent to sudo on its input, never on a command line). So a normal administrator account in the sudo/wheel group gets the full inventory: serial numbers, memory modules, the SSH server's settings for Compliance, and actions such as Install updates work. If sudo isn't allowed for the account, everything runs as the account itself (less inventory, no system changes). Set Run as root with sudo to No to never use sudo with a credential.
Accounts that aren't allowed to use sudo cause a "not in the sudoers file" entry in the computer's log at each scan; set the option to No for them.
Host keys are trusted on first use. If a server is rebuilt and its key changes, scans stop with "host key changed" (possible impersonation). Clear the stored key under Configuration › General settings › SSH host keys.

Network devices (SNMP)#

Version	Fields
v1 / v2c	Community string (e.g. `public`)
v3	Username, auth protocol (SHA/SHA256/SHA512/MD5) and password, privacy protocol (AES/AES192/AES256/DES) and password

Read-only access is sufficient. SNMP provides the device name, description, contact and location, vendor and model, serial number, firmware version and MAC address. It's used to identify switches, routers, firewalls, access points, printers, UPS and NAS devices.

IP cameras (ONVIF)#

For IP cameras and video recorders that support ONVIF, the camera industry's standard interface: Amcrest, Hikvision, Dahua, Axis, Reolink, Hanwha, Uniview and most others. Many cameras (Amcrest, for example) don't offer SNMP, so ONVIF is how Census inventories them.

Field
Camera user name / password	A camera account. *Use a separate account with user* or operator rights**, not the camera's admin.
Connection	HTTP (default; the camera's web port 80, 8000, 8080, 8899 or 2020) or HTTPS (443). A self-signed certificate on the camera is accepted: Census only reads.
Port	Only when the camera answers ONVIF on another port.

Some cameras need ONVIF turned on, or an ONVIF user added, in their own settings first (often under Network › ONVIF or Integration). Camera accounts live on each camera: create the same account, with the same password and rights, on every camera. Amcrest and Dahua: add the account under Setup › System › Account (or Manage Users) with enough rights for ONVIF; Census also handles their login variants (HTTP Digest, a different timestamp format).

Camera view: at each scan Census also takes a still image from the camera and shows it as Camera view on the camera's page (only to people with the Screenshots permission; only the latest image is kept). Turn it off under Configuration › General settings.

What Census reads: manufacturer, model, serial number, hardware and firmware version, host name, network settings (MAC, DHCP or fixed, DNS), the camera's clock (how far it's off, time zone, NTP servers), its video streams (codec, resolution, frame rate) and its accounts (names and levels only; ONVIF never reveals passwords). Some cameras only list accounts to an administrator; the Camera panel then says so. v0.52.0 adds the ONVIF version and profiles, location, sensor resolution and image settings (day/night, wide dynamic range, backlight compensation), features (PTZ, microphone, speaker, analytics, recording), detection types (motion, tamper, line crossing…), alarm inputs and relay outputs, audio, stream bit rates and key frame intervals, the network services and their ports (HTTPS off is pointed out), gateway and link speed, and for Amcrest/Dahua the memory card (state, size, used; read through the camera's own web API with HTTP Digest). It all shows in the Camera, Camera network, Storage and Video streams panels on the asset's Summary tab, in the reports under Cameras (IP cameras, Cameras on older firmware, Cameras with a wrong clock or no time sync, Camera accounts to review), and in the asset's history (firmware updates, accounts added or removed).

Security: the password is never sent: ONVIF sends a one-time hash of it. Someone capturing plain-HTTP traffic could still try to crack that hash offline, as with Windows logins, which is why a separate low-rights camera account is recommended. Census only sends the login to devices that first answer as an ONVIF camera, so other web servers never receive it.

When a camera refuses the login, its page shows The last scan couldn't log in with the camera's answer to each way Census tried: WS-Security (the ONVIF standard), the same with the Dahua/Amcrest timestamp format, and HTTP Digest (only tried on devices with RTSP port 554 open, or over HTTPS). Typical causes, especially when the same account works in the camera's web page:

some cameras (seen on Amcrest/Dahua firmware) only accept the admin account over ONVIF, even when another account works in their web page. If no other account works on a camera, use a credential with its admin account and map it to that camera only (Scanning credentials… on its page). Such cameras may answer You still have 0 attempt(s) although nothing is locked;
ONVIF or its login check is switched off or set differently on that camera (Setup › Network › Platform Access or Connection);
the camera locked the account, or the scanner's address, after several wrong passwords (usually for about 30 minutes): wait or restart the camera, fix the password, then rescan once. Census reads that count and never uses up the last attempt itself;
the password was typed differently on that camera: set it again on the camera, or give that camera its own credential with Port if it answers ONVIF on another port.

Server management controllers (Redfish)#

For the management controllers of servers: HPE iLO, Dell iDRAC, Lenovo XClarity Controller, Supermicro, Cisco CIMC and other Redfish controllers. Census reads the server's hardware health, fans, temperatures, power supplies, drives, firmware and hardware log.

Field
Controller user name / password	A read-only account on the controller (iLO: Login privilege only; iDRAC: Read Only; XClarity Controller: Read-only).
HTTPS port	Only when the controller doesn't answer on 443.

The password is only sent over HTTPS, to devices that first answer as a Redfish service, and only while the controller shows the certificate it showed at the first scan. Details in Server hardware health.

Active Directory (LDAP)#

Used for Active Directory sync. Any domain user works, since reading the directory needs no admin rights.

Field	Example
Bind account	`svc-census@corp.local` or `CORP\svc-census`
Password
Skip TLS verification	Enable if your domain controller uses a certificate from an internal CA the server doesn't trust

Device test#

Scanning › Device test (administrators) tries credentials on one device and shows what each login gets, without changing the inventory. Use it when a device isn't inventoried, a scan says "login failed", or before mapping a new credential.

Enter the IP address or host name. On an asset's page, Test credentials on it opens the test for that asset.
Leave the credentials unticked to try the ones a scan would use for that address, in the same order (mapped ones first, then global ones); or tick the ones to try.
Click Test.

Census first checks whether the device answers and which ports are open, then logs in with each credential: WinRM shows the computer name, Windows version, the account and whether it is an administrator; SSH shows the host name, OS, user and whether it is root or can use sudo without a password; SNMP shows the device's name, description and object ID; ONVIF shows the camera model, serial number and firmware. Failures show what the device answered. Credentials whose port is closed are listed as not tried.

Nothing is stored, except an SSH host key seen for the first time (like a scan). Remote-site devices are tested by their remote scanner when you rescan them: this server never logs in to them itself. Every test is in the audit log.