General troubleshooting information for Portnox Cloud integrations

In this topic, you will find frequently asked questions, answers, and troubleshooting tips related to Portnox™ Cloud integrations with third-party solutions.

What user information does Portnox Cloud read from authentication repositories?

When integrating with an authentication repository, Portnox Cloud reads the following user information for all supported repository types:

• User ID
• User name
• Distinguished name
• Email address
• Status (active or inactive)
• Password status (whether a reset is required)
• Group membership

Note: This information is necessary for Portnox Cloud to enforce access policies, assign users to groups, and track authentication activity.

When mapping an Active Directory (AD) group to a Portnox Cloud group, are users in subgroups also mapped?

Yes, all users in all subgroups at any level are automatically mapped if the parent AD group is mapped to a Portnox Cloud group.

For example, consider the following structure:

main_group
|
+--- subgroup
|       |
|      +--- user_2
|
+--- user_1                    

If you map main_group to a Portnox Cloud group, both user_1 and user_2 are mapped, even though user_2 belongs to a subgroup that was not explicitly mapped.

If your environment is hybrid and it includes both Active Directory and Entra ID, which domain is used by AgentP when enrolling the user automatically in an unattended enrollment setup?

By default, AgentP enrolls with the domain of the user who is logged in to the machine. If the user logs in with their AD credentials/domain, AgentP enrolls using AD. If the user logs in with their Entra ID credentials/domain, AgentP enrolls using Entra ID.

To force AgentP to enroll using a specific domain, in the Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Portnox AgentP key in the registry, add a Domain value with the domain name that you want AgentP to enroll with.

Note:

If you’re using unattended enrollment, Portnox assigns higher priority to Entra ID credentials by default. If you want Portnox to use Entra ID credentials during unattended enrollment in a hybrid environment, go to Settings > Services > GENERAL SETTINGS > AgentP Enrollment Policy, and activate the When using unattended enrollment, prioritize Active Directory credentials over Entra ID checkbox.

You have a third-party security solution and you want to send information to this solution about user logins through Portnox Cloud, including user names and local IP addresses. How can you send such information to a third-party solution?

1. To be able to receive information about local IP addresses in Portnox Cloud, your NAS devices must be configured to use a local RADIUS server. If they use the cloud RADIUS servers, you will not be able to obtain local IP addresses. Deploy a local RADIUS server and configure it in your NAS devices.

   Related guides:

   • Run the local RADIUS server in a container or Set up a local RADIUS server using a virtual machine

   • Configure Ethernet devices to work with Portnox Cloud or Configure wireless devices to work with Portnox Cloud

2. Integrate your Portnox Cloud with an on-premises SIEM solution that includes a syslog listener. You will send Portnox Cloud alerts to this on premises solution, so that you can parse the syslog and deliver suitable information to your third-party security solution.

   Related guides:

   • Integrate with NXLog

   • Integrate with Kiwi Syslog Server

3. Consult your syslog collector documentation and your third-party security solution documentation on how to send information from your on-premises syslog to your security solution.

Why do some SIEM platforms merge multiple events into a single message, split a single event into multiple messages, or show unexpected trailing characters (for example, #015) at the end of events?

By default, the portnox-siem Docker container appends a Windows-style line ending (\r\n, also known as CRLF) after every event before forwarding it to your SIEM or syslog server. Most SIEM platforms expect this delimiter to split a continuous stream of syslog data into individual events. However, some SIEM platforms or log-processing pipelines are sensitive to the exact line-ending characters used and may not parse events correctly if the delimiter does not match what they expect.

If you observe this behavior, add the optional EVENTS_DELIMITER environment variable to the docker run command that you use to start the portnox-siem Docker container, and set it to one of the following values:

Table 1.

Delimiter	Escape sequence	Value	Docker run flag	Comment
Carriage Return + Line Feed	\r\n	Default	-e EVENTS_DELIMITER=Default	Both values produce the same result. Default is used when EVENTS_DELIMITER is not set; CrLf sets it explicitly.
		CrLf	-e EVENTS_DELIMITER=CrLf
Carriage Return	\r	Cr	-e EVENTS_DELIMITER=Cr	Carriage return only.
Line Feed	\n	Lf	-e EVENTS_DELIMITER=Lf	Line feed only, Unix-style.
None	None	None	-e EVENTS_DELIMITER=None	No delimiter appended.

Note:

Consult your SIEM platform's documentation to determine which line-ending format it expects.

For example, to force the container to use a Unix-style line feed instead of the default CRLF delimiter, add the EVENTS_DELIMITER flag to the command that you copy from the Cloud portal:

docker run -d --name portnox-siem --restart=on-failure --pull always \
  -e APIUSER=b2973887-1274-45c4-91d0-4a342a861c76 \
  -e APIKEY=********* \
  -e GWID=0fed395a-84c6-42ff-a62c-3a24b30c29d8 \
  -e EVENTS_DELIMITER=Lf \
portnox/portnox-siem:latest

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.