Portnox Cloud best practices

Most of our customers use automatic provisioning. We recommend starting with automatic provisioning. If it does not meet your requirements, you can remove it and switch to manual provisioning.

The choice between automatic and manual provisioning is available only for the Entra ID authentication repository. For Google Workspace, only automatic provisioning is supported, while Okta always requires manual provisioning using the REST API or LDAP.

Yes, you can configure Portnox Cloud to work with both Entra ID and Active Directory. However, by default, Entra ID takes precedence. Users and devices found in Entra ID bypass synchronization with on-premises AD.

If you use AgentP with unattended enrollment, you can override this behavior by enabling the option to prefer on-premises AD over Entra ID.

We recommend deploying at least two Portnox LDAP Brokers if you use Portnox Cloud with Active Directory or an on-premises LDAP directory. If an LDAP Broker becomes unavailable for any reason, you will lose the ability to authenticate on the network and more. The LDAP Broker is lightweight and easy to deploy.

We strongly recommend treating LDAP Broker as a Tier 0 application because it requires high-level permissions in the local AD or LDAP directory to function. A compromise of the LDAP Broker could give an attacker full control over your local directory.

We recommend a hybrid setup used by most customers: deploy local RADIUS servers as primary servers on NAS devices and optionally configure Cloud RADIUS servers as secondary servers. If you configure only Cloud RADIUS servers, an Internet outage will prevent local users from logging in. We recommend this approach only if all resources are cloud-based and the local network exists solely to provide Internet access.

We recommend deploying at least two local RADIUS servers. They are inexpensive to run, and having multiple servers ensures redundancy. The number of local RADIUS servers depends on the capabilities of your NAS devices and available configuration slots.

We recommend running local RADIUS servers in Docker because it is easier to set up and uses fewer machine resources. It also supports CoA functionality (virtual machines do not). Virtual machines offer automatic updates. Docker-based deployments require the portnox-autoupdate container.

Although supported on Azure, AWS, and Google Cloud, we recommend running the local RADIUS server on-premises to ensure availability during Internet outages. This does not improve security because communications are already secured with TLS and optional RadSec.

Most customers use RADIUS without RadSec when using secure EAP methods such as EAP-TLS and EAP-TTLS. RadSec is recommended if using less secure credential-based methods such as PEAP. The main drawback of RadSec is increased configuration complexity.

We strongly recommend using certificates for authentication using EAP-TLS. Credentials should be used only when absolutely necessary and preferably only with on-premises authentication repositories. MAC-based authentication should be treated as a last resort for devices that do not support other methods.

User certificates are recommended for individual or multi-user devices. Device certificates are preferable for kiosks and devices without user accounts. Device authentication is available only with Entra ID, Active Directory, or on-premises LDAP.

We recommend using the certificate authority provided by Portnox Cloud for ease of configuration and management.

Most customers use AgentP because it simplifies device configuration and provides additional benefits. Using UEM or MDM platforms without AgentP is possible but more complex. Risk assessment without AgentP requires Intune or Jamf.

Multi-user onboarding is recommended for shared devices. Single-user onboarding is recommended for personal devices. Device-based authentication is recommended for devices without users.

We recommend distributing AgentP using existing UEM or MDM software. Users can also manually install AgentP on BYOD devices.

Outdated or unmanaged devices should be blocked first and optionally deleted later. Deleting without blocking allows re-enrollment and network access.

Configure critical authentication or critical VLAN if supported. Use monitoring mode when testing new NAS device configurations.

Keep the Default group as a catch-all with minimal access. Create only the minimum number of groups required.

Keep the number of policies to a minimum. Use sites only when necessary.

Create a parallel SSID to safely test before retiring the legacy SSID. Reusing the existing SSID is possible but carries higher risk.

1. Select the VM-based local RADIUS server to replace.

   If you have multiple VM-based local RADIUS servers, migrate them one by one: complete the full process for the first server before starting the next.

2. Change the priority of RADIUS servers in NAS device configurations so that Portnox Cloud RADIUS is the primary server, not the VM-based local RADIUS.

   Note:

   If you can’t use Cloud RADIUS servers, simply leave one VM-based local RADIUS server running while you migrate the others and use that server as your primary RADIUS during migration.
   Note:

   Optionally, you can configure NAS devices to accept Change of Authorization (CoA) packets if required by following the NAS switch documentation on CoA. This is not directly related to migration, but Docker-based local RADIUS servers give you that option.

3. Turn off the selected VM-based local RADIUS server. Do not delete it yet; keep it powered off in case you need to roll back.

4. Deploy the Docker-based local RADIUS server:

   • Create the Docker-based local RADIUS server by following the guide.

   • Assign the same IP address, ports, and shared secret as the VM-based server. This minimizes NAS configuration changes and reduces the risk of errors.

5. Confirm that the Docker-based local RADIUS server shows as Active in the Portnox Cloud portal.

6. Update NAS device RADIUS server priority to point to the Docker-based local RADIUS instance as the primary server.

   Note:

   If you kept the same IP, ports, and shared secret, you can revert to the previous configuration if your NAS devices give you such an option. Otherwise, simply adjust the priority again.

7. Repeat this process for each remaining VM-based local RADIUS instance.

1. Planning

   1. Inventory current SSIDs, VLANs, ACLs, DHCP scopes, and related components.

   2. Document existing authentication and segmentation policies.

   3. Define migration goals.

2. Lab testing and pilot roll-out

   1. Create a test SSID using Cloud RADIUS.

   2. Validate authentication across device types.

   3. Confirm VLAN assignment and fallback behavior.

   4. Enable monitoring mode.

   5. Start with early adopters.

   6. Monitor results in Devices and Alerts.

3. Staged deployment

   1. Expand migration gradually.

   2. Ensure certificates or AgentP are deployed.

   3. Whitelist MAC addresses if needed.

4. Validation

   1. Confirm RADIUS redundancy.

   2. Validate certificate workflows.

   3. Verify VLAN and policy assignments.

5. Legacy SSID retirement

   1. Disable old SSIDs after full coverage is confirmed.

   2. Ensure fallback VLAN exists.

6. Post-migration cleanup

   1. Disable monitoring mode.

   2. Remove obsolete SSIDs.

   3. Audit NAS devices.

   4. Update internal documentation.