Troubleshooting access to networks protected by Portnox Cloud

In this topic, you will learn how to address the most common issues when connecting to networks protected by Portnox™ Cloud.

Why do Windows devices fail 802.1x authentication after upgrading to Windows 11 version 22H2 or later?

After upgrading to Windows 11 version 22H2 or later, some Windows devices fail to authenticate using 802.1x. These devices can still connect to the network when 802.1x is not required. In the AAA logs, the only error shown is EAP FAILED (EXPIRED) during the PEAP Phase 2 initialization.

This issue affects devices that use 802.1x for wireless or wired network access, RDP, or VPN connections that rely on insecure, password-based authentication protocols. When Credential Guard is enabled, users cannot use Single Sign-On (SSO) and must manually enter credentials for each new Windows session.

Any device with Credential Guard enabled can encounter this issue. Starting with Windows 11 version 22H2 and Windows Server 2025 (preview), Credential Guard is enabled by default on eligible devices unless it was explicitly disabled. This applies to Enterprise (E3 and E5) and Education licenses, and to some Pro licenses, as long as the device meets the minimum hardware requirements.

The root cause is that Credential Guard blocks insecure authentication protocols that use password-based authentication, because these protocols can expose passwords on the client or server. Affected protocols include Kerberos unconstrained delegation, Kerberos with PKINIT using RSA instead of Diffie-Hellman, MS-CHAP, WDigest, and NTLM v1. For MS-CHAP, WDigest, and NTLM v1, only SSO is blocked, and users can still authenticate by manually entering credentials.

Microsoft recommends moving away from MS-CHAPv2-based methods such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, and using certificate-based authentication instead, such as PEAP-TLS or EAP-TLS. Credential Guard does not block certificate-based authentication.

As a temporary but less secure workaround, you can disable Credential Guard. Credential Guard does not support per-protocol or per-application settings, so it must be fully enabled or disabled. Disabling it increases the risk of stored domain credentials being stolen.

This information is based on Microsoft documentation titled Considerations and known issues when using Credential Guard. Third-party information is provided for reference only and should be independently verified. Use of such information is at your own risk.

Why are devices not assigned to the fallback VLAN when using MSCHAPv2 authentication?

When using MSCHAPv2 authentication, devices that fail authentication are rejected instead of being assigned to the fallback VLAN. This occurs even if the fallback VLAN is properly configured and works correctly with other authentication methods. This behavior has been observed on Ubiquiti access points but can also happen on other network devices.

The reason is that MSCHAPv2 handles authentication strictly. It verifies a user’s password by generating a special code called the NTKey. If the password is incorrect or the account does not exist, the authentication process fails, and the device stops communicating with the network entirely. Since the device loses connectivity during this failure, the network cannot assign it to a fallback or quarantine VLAN.

Because MSCHAPv2 enforces this strict behavior for security reasons, there is no workaround to enable fallback VLAN assignment for devices using this authentication method. The only solution is to use an alternative authentication method that supports fallback VLANs.

If you use Portnox Cloud to create a new, secure Wi-Fi network (SSID), but your Windows clients already have another network set to Connect automatically, those clients may be connecting to the old, insecure SSID, instead of the new, secure one. How to make sure that Windows prioritizes the new secure Wi-Fi network?

If Windows finds several Wi-Fi networks with the Connect automatically option turned on, the priority when attempting to connect to Wi-Fi depends on many factors such as signal strength and whether the network was accessed before. However, you can also assign manual priorities to specific Wi-Fi networks.

To do this, execute the following command on the Windows client, or use your GPO or UEM software to execute a script automatically:

netsh wlan set profileorder name="SSID_NAME" interface="Wi-Fi" priority=1

where SSID_NAME is the name of the secure Wi-Fi network that you want to connect to with highest priority.

macOS: If you reset your Mac password through Recovery Mode, you can lose access to keychains, certificates, and network profiles.

macOS encrypts the keychain with your login password. When you reset your password in Recovery Mode, the old keychain cannot be unlocked, and macOS creates a new empty keychain. Certificates stored in the old keychain become inaccessible, and services like Wi-Fi, VPN, or device management tools may stop working. Installed configuration profiles may also rely on these certificates and may fail to function.

The old keychain file usually remains in ~/Library/Keychains but is still encrypted with your previous password. If you know the old password, you can try to access the old keychain using Keychain Access to recover certificates and other data.

If the old keychain cannot be accessed, you need to redeploy the necessary certificates, configuration profiles, and Portnox AgentP if used. Follow the standard onboarding procedures for agent-based or agentless devices to restore access.

Does a change in the WAN IP affect Portnox Cloud, and what is required to keep services working?

A change in your WAN IP can affect Portnox Cloud if the tenant uses IP address restrictions for access control. This happens when the old WAN IP addresses are configured for whitelisting. You can verify this setting in Settings > Services > CLOUD RADIUS SERVICE > Cloud RADIUS Instance > Restrict access to Cloud RADIUS service. If Allow only the listed IP addresses is enabled, update the list with the new WAN IP addresses.

Apart from IP restrictions, Portnox Cloud does not require a customer WAN IP address for normal operation.

Note:
Some switches require an explicitly configured source IP address for RADIUS communication. This is usually a LAN IP address. In cases where the switch performs Layer 3 routing or operates in a DMZ, the source IP may be an external IP. Verify the NAS or switch configuration to ensure it uses the correct source IP address.
How to avoid device identification issues when using docking stations?

When a laptop connects to the network through a USB-C or Thunderbolt docking station, the dock is very likely to use its own network adapter’s MAC address instead of the laptop’s native MAC address. This may cause misidentification and other issues, for example, it may prevent anti-spoofing because the MAC address will be the same for devices with different DHCP signatures.

Some docking stations, including most Dell models, support a feature called MAC Address Pass-Through (MAPT). When enabled, MAPT ensures the dock passes the laptop’s MAC address through to the network, maintaining a consistent device identity. This eliminates the issues described above.

Example steps to enable MAC Pass-Through on a Dell laptop and dock:

  1. Restart the laptop and press F2 or F12 at the Dell splash screen to enter the BIOS.

  2. Navigate to: System Configuration > Integrated NIC > MAC Address Pass-Through > System Unique MAC Address, set this option to Enable, save changes, and restart the laptop.

  3. If MAC Address Pass-Through is enabled in BIOS but not reflected in the OS, update the BIOS and the dock’s network driver (e.g., Realtek Gigabit Ethernet) with the help of Dell Support.

  4. As a last resort in Windows, manually override the dock’s NIC MAC address:

    • Open Device Manager and expand Network adapters.
    • Right‑click the dock’s Ethernet adapter (often Realtek) and select Properties > Advanced.
    • Choose the Network Address or Locally Administered Address property.
    • Enter the laptop’s MAC address (12 hexadecimal characters, no colons or dashes, e.g., AABBCCDDEEFF).
    • Click on OK. For the change to take effect, restart the laptop or disable/enable the adapter.
Why does RDP access fail and wired ports get quarantined when using 802.1X user authentication?

In environments where 802.1X authentication is required on wired connections, customers may observe that users attempting to establish a Remote Desktop Protocol (RDP) session to a workstation or laptop are immediately disconnected. When this happens, the switch port to which the workstation is connected can be reauthenticated and moved from its original VLAN (for example, VLAN 111) to a quarantine or fallback VLAN (such as VLAN 255). As a result, RDP access is denied, even though the Portnox Cloud policy applied to the wired port does not explicitly reference RDP.

This behavior can be confusing, especially because RDP connections to the same devices work correctly when users connect over Wi-Fi. The issue is not related to a specific Portnox Cloud policy action against RDP traffic, but rather to how 802.1X user authentication behaves during remote desktop sessions.

The root cause is that when 802.1X is configured for user authentication on a wired connection, the supplicant is unable to properly query or validate the user credentials during an RDP (Remote Desktop Services) session. This authentication failure causes the switch to treat the endpoint as unauthenticated, which triggers a port reauthentication and results in the port being placed into a fallback or quarantine VLAN.

Microsoft documents this limitation and explains that 802.1X user authentication may fail for RDS/RDP scenarios. As a result, Microsoft recommends configuring 802.1X authentication mode to computer or user or computer authentication instead. These modes allow the device to remain authenticated at the network level even when the interactive user session changes.

For more details, refer to relevant the Microsoft support article.

Why does a reimaged PC fail MAB authentication when IoT fingerprinting is enabled?

When a PC authenticates using MAC Authentication Bypass (MAB) and is later reimaged, it may fail to authenticate even though its MAC address has not changed. This can occur when IoT fingerprinting is enabled in Portnox Cloud.

Portnox Cloud uses IoT fingerprinting to identify devices not only by their MAC address, but also by their DHCP fingerprint. Reimaging a PC can change its DHCP fingerprint. If this happens, Portnox Cloud will treat the device as an impersonating endpoint, causing MAB authentication to fail.

To resolve this issue, remove the device’s MAC address from the MAB whitelist and add it again. This allows Portnox Cloud to associate the updated DHCP fingerprint with the existing MAC address and restore network access.

Why are MAB devices being automatically archived in Portnox Cloud?

MAB devices in Portnox Cloud may be automatically archived if they do not periodically re-authenticate. This behavior is related to how Portnox Cloud manages the device lifecycle and retention. If a device does not re-authenticate within the expected timeframe, it may be considered inactive and archived.

The most common cause is missing periodic re-authentication configuration on the switch port. If the switch is not configured to trigger re-authentication, MAB devices can remain silently connected at Layer 2 without generating new authentication events, preventing Portnox Cloud from refreshing their state.

To prevent this, periodic re-authentication must be enabled on the switch ports where MAB devices are connected. The exact commands vary by vendor. The following are example commands to use for this purpose:

  • Aruba/HPE: aaa authentication port-access mac-auth reauth and aaa authentication port-access mac-auth reauth-period
  • Cisco IOS/IOS-XE: authentication periodic and authentication timer reauthenticate
  • Arista EOS: dot1x reauthentication and dot1x timeout reauth-period
  • Juniper EX / Junos: protocols dot1x reauthentication

Consult your NAS device manual for exact command syntax and usage examples.

Once periodic re-authentication is enabled, MAB devices will regularly refresh their authentication state, preventing unintended archival in Portnox Cloud.

Why does an IoT device such as a printer fail authentication with an EAP-TLS error?

This issue can occur when the system time on the IoT device is incorrect. If the device clock is set far in the past or future, the certificate presented by the device may appear outside its validity period, causing the RADIUS server to reject it during the TLS handshake.

Correct and synchronize the device’s system time with the current date and time. After the time is updated, the device should successfully reauthenticate and the authentication errors should no longer appear.

Why does a device authenticated using MAB keep being assigned to the same VLAN after being added to another group?

Portnox Cloud does not prevent the same MAC address from being added to multiple groups. If a MAC address exists in more than one group, Portnox Cloud applies the policy from the first matching group based on group priority. As a result, the device may continue receiving the original VLAN even after being added to a different group.

Why do MAB-authenticated IP phones remain in an unauthorized state after reauthentication events?

IP phones may authenticate successfully via MAB in Portnox Cloud, but remain in an unauthorized state after switch reloads, power interruptions, link flaps, or when the device is replugged. This typically occurs when voice and data devices share the same VLAN and no voice VLAN is configured on the access port, while the RADIUS server classifies the device as a voice endpoint.

Symptoms of this issue include:

  • IP phones authenticate successfully via MAB in Portnox Cloud.
  • Switch output shows mab Authc Success with Domain: VOICE and Status: Unauthorized.
  • Phones may initially work but fail after switch reboot, power outage, link flap, or device replug.
  • Data devices on the same port continue to function normally.

The root cause is that when voice and data share the same VLAN without a configured voice VLAN, the switch has no explicit authorization action for the VOICE domain. Even though MAB authentication succeeds, the switch cannot complete authorization, leaving the session in an Unauthorized state. This becomes visible during reauthentication events when sessions must be rebuilt.

To resolve the issue, configure a voice VLAN on the access port, even if it is the same VLAN used for data traffic. This provides the switch with an explicit authorization target for VOICE sessions and allows MAB-authenticated phones to transition to an authorized state reliably.

Why is the manufacturer of some of my IoT devices not recognized (Unknown Vendor)?

Some IoT devices use MAC addresses with unregistered or unknown OUI prefixes (for example, 98:3F:00). Portnox Cloud uses the IEEE OUI registry to identify vendors, so these prefixes cannot be matched automatically to a MAB account based on OUI. Because of this, these devices do not get the correct MAB policy and must be authorized either manually or with automatic onboarding. Only the device manufacturer can register an official OUI with the IEEE. Until then, Portnox labels the prefix as Unknown Vendor.

You can onboard devices with unregistered OUIs using one of these methods:

  • Manual import into an existing MAB account (best for large batches): Upload a list of MAC addresses directly into the MAB account under Allowed MAC Addresses. This is the fastest method if the vendor can provide a full MAC list.

  • Whitelist devices from alerts (best for small batches): When a device connects, it triggers a MAC bypass denied alert. In the alert, click on Add MAC(s) to new or existing account and select your MAB account.

  • Use automatic MAB onboarding: See the topic Onboard IoT devices by creating MAC-based accounts automatically.

  • Contact the device vendor: Ask them to confirm MAC ranges or, better, register the OUI with the IEEE Registration Authority.