Troubleshooting miscellaneous issues related to Portnox Cloud risk assessment

In this topic, you will find troubleshooting information for common issues related to Portnox Cloud risk assessment.

How does Portnox Cloud check and report risk assessment policy attributes?

AgentP monitors the attributes defined in the risk assessment policy. Most attributes do not follow a fixed schedule. Some changes are detected within a minute of occurrence, such as process, service, or antivirus changes. Some attributes, like registry keys, are checked approximately once every hour.

There is no specific order for attribute checks. The overall risk score is calculated from all attributes as soon as the data is available. Devices are blocked immediately when the risk exceeds the defined threshold.

If you have software that monitors local account login attempts, and use Portnox Cloud with AgentP and risk assessment policies, you may notice that machines with AgentP get locked out because of an excessive number of local account login attempts or because of password quality problems. This behavior was observed, for example, with Defense Storm software. What is causing these lockouts?

There is a risk attribute in Portnox Cloud that involves testing local account password quality. To access it, go to: Policies > selected_policy > Edit > Agent-based (AgentP) > Windows > Log-in and accounts.

If this risk attribute has a non-zero risk score, AgentP will make many attempts to log in to the local user account using well-known weak passwords. To avoid this problem, set the Risk score of this policy to zero (checks are performed as long as the weight of the policy is non-zero, even if the Each user account on the device has a non-blank, strong password checkbox is inactive) or adjust your alarm limits in your third-party security software. There is no workaround, because to test for weak passwords, AgentP must make many such attempts.

Why do some devices fail to correlate correctly with SentinelOne?

Portnox Cloud correlates a device with its SentinelOne record using the device’s hardware serial number. If a serial number is missing, not found in SentinelOne, or shared by more than one device, this correlation fails and SentinelOne-based risk attributes cannot be evaluated reliably for that device.

The most common cause of duplicate serial numbers is imaging: when multiple devices are built or re-imaged from the same template or golden image, they can end up reporting the same SMBIOS/BIOS serial number, including placeholder values such as To Be Filled By O.E.M. or System Serial Number that were never set to a unique value. SentinelOne reports this firmware value as-is and cannot correct it through its Console, Agent, or API, so the fix has to happen at the hardware/firmware or imaging-template level, by ensuring each device gets a unique serial number during provisioning.