How to troubleshoot typical device onboarding issues

In this topic, you will learn how to address the most common issues when onboarding devices onto a network managed by Portnox™ Cloud.

If you cannot connect your device to the network managed by Portnox Cloud, go to the Cloud portal, select Alerts in the top menu, and look at the most recent alerts. To make it easier to find relevant alerts, you can filter them by account name, NAS device, or other parameters. These alerts will inform you about the causes of authentication failures or will confirm successful authentication.

Here are some typical reasons for connection failures:

  • Check if your group settings allow authentication with the selected method (credentials, certificates, etc.) for the network you’re trying to connect to. See the topic: Create a group.

  • Check if the account you are using is a member of the group that you have configured for the network you’re trying to connect to. See the topic: Manage members of a group.

  • Check if the number of devices per account, which is configured in group settings, has not been exceeded. For more information on setting this limit, see the topic: Edit and configure a group.

  • Check if the network in your group is set up to configure the correct authentication type. For example, if the user uses credentials and belongs to a Microsoft directory (Entra ID or AD), the group must be set up for MSCHAPv2 authentication. If the user uses credentials and belongs to a non-Microsoft directory like Google Workspace, the group must be set up for PAP authentication. If the user uses a certificate, the group must be set up for TLS authentication.

  • If you want to log in using credentials, your instance is integrated with Microsoft Entra ID, and your Entra ID access policy enforces multi-factor authentication (MFA), you need to set up a MFA bypass by following the steps in this topic: Bypass multi-factor authentication in Entra ID.

  • If you want to log in using credentials and your instance is integrated with Google Workspace, the Google Workspace administrator must turn on the following option for the organizational unit: Security > Access and data control > Less secure apps > Allow users to manage their access to less secure apps. Then, each user must turn on access to less secure apps for their own account (the administrator cannot enforce this setting) by visiting this URL.

    However, if you use multi-factor authentication, access to less secure apps is not supported and therefore you cannot use your Google Workspace credentials. Instead, you need to generate a Google app password. Then, you can use your Google email and the generated passwords as your credentials.

  • If certificate-based authentication does not work but credential-based authentication works, check if the packets are being fragmented by firewalls/routers between the NAS and the RADIUS server.

    The following are potential options to resolve this fragmentation problem:

    • For Palo Alto switches, try this solution.
    • For Cisco Internet SD-WAN connections, packet reassembly might cause the issue, which is resolved by issuing the following command on the interface level: no ip virtual-reassembly-out.
    • For Cisco switches also consider disabling jumbo frames.
    • Reduce the key size of the certificate and eliminate any unnecessary information from the certificate.
    • Use RadSec to communicate to cloud RADIUS servers.
    • Install a local RADIUS server and use it as a proxy to the cloud RADIUS servers.

  • If you’re trying to access the network without AgentP, but your account was previously activated with AgentP, check if the following setting is on: Settings > Services > CLEAR GENERAL SETTINGS > AGENTLESS ACCESS > Enable agentless access for all automatically-created accounts.

  • If your AgentP reports an error, see the following topic: How to collect AgentP logs for support