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.

The Portnox LDAP Broker should be treated as a Tier 0 asset; access should be restricted to Tier 0 admins using PAWs and governed by Tier 0 network and security policies due to its direct interaction with Active Directory and authentication processes.

The required privilege level for the broker's AD user account depends on your authentication configuration. If you enable the NTLMv2 option, the service account requires very sensitive privileges in Active Directory. Even in the default configuration, the service account only requires read-only access, but that still grants broad read access to the entire directory structure. The Tier 0 classification therefore applies regardless of which authentication mode is in use.

Some customers, especially those subject to GDPR or other privacy regulations, prefer to minimize personally identifiable information (PII) stored in integrated systems. In Portnox Cloud, the only PII stored are user account names or device names that connect to Portnox Cloud services.

A common way to achieve this is by configuring user accounts in your identity provider, such as Entra ID, Google Workspace, or Okta, so that the User Principal Name (UPN) is a non-identifiable random string. You can associate an email alias with the UPN containing the actual user name for convenience. When Portnox Cloud synchronizes authentication data, it receives the obfuscated UPN instead of a name-based identifier. This ensures that even if authentication data is synced, Portnox Cloud only stores anonymized identifiers rather than real names. Note that this configuration is done entirely in your identity provider, not within Portnox Cloud.

If concerned about the security of your PII, please note that Portnox Cloud data is hosted on Azure infrastructure, similar to services like Entra ID, so any PII already present in your identity provider benefits from comparable infrastructure-level protections.

Cloud RADIUS is the recommended authentication service. We additionally recommend deploying one or more local RADIUS servers for environments where local network access must remain available during Internet outages. Without local RADIUS, any device that is not already connected will fail to authenticate during an outage, because authentication requests cannot reach the Cloud back-end. If all resources are cloud-based and the local network exists solely to provide Internet access, Cloud RADIUS alone is sufficient, and the complexity of the deployment is greatly reduced.

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. A cloud-hosted local RADIUS server will be unreachable during an Internet outage along with all other cloud services, which completely eliminates its primary advantage over Cloud RADIUS alone. Running local RADIUS in a cloud environment also does not improve security, because communications between the local RADIUS and the Cloud back-end are already secured with TLS.

Most customers use RADIUS without RadSec when using secure EAP methods such as EAP-TLS and EAP-TTLS because with these EAP methods, sensitive information is already sent using a TLS tunnel. RadSec is recommended only if using less secure credential-based methods such as PEAP. The main drawback of RadSec is increased configuration complexity. Note that deploying a local RADIUS server also addresses concerns about unencrypted RADIUS traffic traversing the Internet, as it communicates with the Cloud back-end over HTTPS rather than sending RADIUS packets over the Internet, while additionally providing outage resilience that RadSec cannot offer.

There are four main configurations for assigning RADIUS server priority on NAS devices. Each has trade-offs, and the right choice depends on your environment and priorities – whether that is simplicity, outage resilience, fast reconnections, or redundancy against local infrastructure issues. Review the options below and decide based on what matters most to your deployment.

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. Use your own certificate authority only if you already use this authority for other purposes. However, be aware that if your CA's private key is compromised, you will need to upload a new CA certificate and regenerate all supplicant certificates verified by Portnox.

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.