Commit Confirm

Juniper Champions Summit Test Post

Jimmy Taylor — Tue, 15 Apr 2025 00:00:00 +0000

This is a test post. I need a test post, so this is what I’m writing.

I have no idea why I look bad in this photo. Probably because I asked a random stranger to take the photo.

Glad to finally get this domain and running.

Juniper Mist Dot1x User Authentication Issue

Jimmy Taylor — Tue, 15 Apr 2025 00:00:00 +0000

It was a December holiday break, and I was working away, preparing for a coming project, but something stirred in the air; something was wrong.

The beacons are lit!

$customer calls for aid!

And Jimmy will answer.

It appears that $customer is having a problem with dot1x-hotdesking (same device, multiple users) on Juniper switching with new users. Cisco switching is working fine, but something is up on the Juniper side. If a user’s profile has been provisioned already, it works fine; AD-joined Windows devices are working fine as well.

The cause and solution to this dot1x-hotdesking issue were both fascinating to discover, and the research that I had to perform for this problem really helped me understand what the heck is going on between network switch supplicants, authenticators, and network access control systems. Below is a compilation of my research and what I figured out.

tl;dr

Problem

Network connectivity fails for new Windows users in hot-desking scenarios (multiple users sharing same system) due to dot1x authentication failure.
User profile is missing certificate from internal PKI due to network disconnecting after authentication, and therefore fails dot1x authentication.
Machine and user certificate authentication, on their own, are working normally.

Below is a brief demonstration of normal authentication and the problem this customer had on Juniper switches.

Normal 802.1x Authentication

Right-click and open image in new tab for full size

802.1x - User Cert Missing

Right-click and open image in new tab for full size

Solution

There are actually a few different solutions to this problem, and some of those are in the links at the bottom.

This particular solution works by adjusting switch port dot1x timers to fail quickly and move on to MAC authentication. This works by leveraging the machine’s previous successful authentication and registration within the NAC (within an endpoint identity group in ISE, for this case), which authorizes the port before the Windows timer resets and tries dot1x authentication again.

Below are the configurations for this.

Juniper Mist Switch Configuration

Juniper switch needs the following dot1x configurations.

Allow multiple supplicants
MAC authentication
Adjust RADIUS timers and retries to fail to MAC authentication before 60 seconds.

In Juniper Mist:

Port profile, enable the following:
- ✅ Allow multiple supplicants
- ✅ Mac authentication
- ✅ Port Network (Untagged/Native VLAN) needs to be a network that the user’s account can communicate with PKI and obtain a certificate (or you receive a dynamic VLAN from the NAC that accomplishes the same thing)

RADIUS server profile:
- ✅ Enhanced Timers

The end effect here is that you are causing the dot1x process on the Juniper switch port to fail quickly and move to MAC authentication.

NAC Configuration

In addition, the NAC solution needs to be configured to allow the MAC address of the endpoint device to authenticate on the port, optionally also sending a tunnel-group-id/VLAN that is within a network that allows the user’s account to communicate with the PKI in order to obtain a user certificate.

That’s it.

In the Weeds

Alright nerds and AI bots, it’s our time. Here’s the basic structure of how I put this together.

First off, let me remind you that this is just one solution of many for the Windows dot1x-hotdesking issue, but going through this problem and solution really helps understand the process that happens all the time across vendors.

Here’s how this is broken down:

Discuss the whole hotdesking problem and briefly show how dot1x works on Windows devices. Or link to someone who already has.
Go through a sequence diagram of the problem itself, explaining where the missing user certificate appears during the process and how all the components in the system are part of the process.
Go through the switch configurations for both Cisco and Juniper, because it worked on Cisco, so why not Juniper?
Another sequence diagram, but this one explaining and showing how successful machine-to-user-login dot1x authentication works.
Explain how the network access control (NAC) server (ISE, in this case) acts as part of the whole process, and how group membership works with MAB to assist the Windows machine in getting a server.
Give my final thoughts on how to improve the security posture, but at the cost of adding more complexity.

Breakdown of the Problem and How Windows 802.1x Works

The essential problem of 802.1x authentication in hot desk scenarios on Windows machines is that typically the user profile hasn’t been provisioned, let alone the profile provisioned/enrolled with a user certificate.

To see why, we need to see how the process works. Here’s a high-level diagram explaining the process by Jacob Fredriksson. Fredriksson breaks it down in detail on their website .

Right-click and open image in new tab for full size

As they explain, the user certificate enrollment process begins after a user logs-in for the first time on a machine, which results in an authentication failure because the supplicant has no certificate to send to the NAC, so it sends a null/blank certificate, and of course the NAC will reject the authentication attempt.

Example: User Certificate Missing, Authentication Rejected

Note

For all images below, image sizes have been reduced for appearance. Right-click on images and open in new tab for full size.

Yes, I haven’t configured any CSS-javascript magic to do it for you when you click on it.

Below is an example of this failure scenario that encountered with the following setup:

Windows 11 Desktop
Juniper EX 4100 Switch
Cisco ISE 3.1… 0. We assume machine authentication has succeeded (see above) and/or machine network connectivity is functioning normally.

A new user to the machine logs into Windows device and begins user authentication processes.
Wired-AutoConfig restarts the authentication process and ends the EAP session due to the user logging into the device.
The NDIS authorization state changes from ‘Authorized’ to ‘Unauthorized’.
Wired-AutoConfig starts, but because the user does not have a client certificate yet, the Wired-AutoConfig service sends a null/blank certificate list to the NAC.
Switch forwards the EAP authentication message to the NAC.
NAC immediately denies the authentication session due to a blank certificate and sends an ‘Access-Reject’ to the switch because of blank certificate.
Switch receives ‘Access-Reject’ and puts port in unauthorized state, forwarding response to machine.
Wired-AutoConfig receives EAP failure and immediately suspends any authentication services for 60 seconds.
Wired-AutoConfig goes to unresponsive state due to timeout. Switch has failure of response from device and waits 30 seconds (by default) before trying again.
Before switch can retry authentication, the Wired-AutoConfig service timeout expires and Wired-AutoConfig tries authentication again with blank certificate.
Steps 5-8 is performed again, and Wired-AutoConfig service re-enters 60 timeout. Steps 9-10 are then performed again, and entire process repeats itself indefinitely until user logs out or receives a certificate.

Full version of this here:

Switch Configurations

The customer notified me that dot1x authentication was working on Cisco switches when users had not yet logged onto the machine. Of course that seems crazy to me because the process is the same on Windows or Juniper, so what’s different?

Cisco IOS Config

On the Cisco switch side of things, these are the crucial configurations that made authentication work.

interface GigabitEthernet0/0/1

 ! This line tells the switch to try the next auth method,
 ! MAB in this case, if the first one fails
 authentication event fail action next-method
 
 ! Allows multiple supplicants to auth from the same port
 authentication host-mode multi-auth
 
 ! This sets the authentication order, and is crucial in
 ! for this hot desk scenario
 authentication order dot1x mab
 
 ! This allows the user certificate auth to override the MAB
 ! auth once authentication happens
 authentication priority dot1x mab
 
 ! Gotta enable MAB
 mab
 
 ! Gotta enable dot1x
 dot1x pae authenticator
 
 ! This is secret sauce, because it gives a maximum reauth
 ! attempt at 10 seconds, and IOS will try, by default, 3 times
 ! before moving on to the next auth method
 dot1x timeout tx-period 10

Juniper Configuration

There are two places to see the Juniper configuration. I’ll show both places: Juniper Mist Wired Assurance, and in Junos CLI.

Juniper Mist

Junos breaks down configurations into different protocol components, so unlike Cisco, the configuration is made in a few different locations. In Mist, this configuration happens in both the ‘Authentication Servers’ configuration, and the ‘Port Profile’.

Authentication servers configuration is here:

The ‘Enhanced Timers’ configuration makes the following changes:

Note

Juniper Mist changed how you can see the configuration changes for items like ‘Enhanced Timers’, and I think it’s for the worse. Above is the delta/change output back in November 2024. As of April 2025, it now looks like this:

The port profile equivalent in Juniper Mist Wired Assurance is below:

Junos CLI

Dot1x settings are centrally located in Junos configurations under Protocols > dot1x. The process involves creating a profile with dot1x settings and adding interfaces to that profile. In this case, the logical interface-range interface dot1x-testing is added to the profile ‘dot1x’.

authenticator {
    authentication-profile-name dot1x;
    interface {
        dot1x-testing {
            supplicant multiple;
            retries 3;
            quiet-period 2;
            transmit-period 2;
            mac-radius {
                authentication-protocol {
                    eap-md5;
                }
            }
            reauthentication 65000;
            supplicant-timeout 10;
            maximum-requests 3;
            server-fail use-cache;
        }
    }
}

Junos set commands showing the same thing:

set protocols dot1x authenticator authentication-profile-name dot1x
set protocols dot1x authenticator interface dot1x-testing supplicant multiple
set protocols dot1x authenticator interface dot1x-testing retries 3
set protocols dot1x authenticator interface dot1x-testing quiet-period 2
set protocols dot1x authenticator interface dot1x-testing transmit-period 2
set protocols dot1x authenticator interface dot1x-testing mac-radius authentication-protocol eap-md5
set protocols dot1x authenticator interface dot1x-testing reauthentication 65000
set protocols dot1x authenticator interface dot1x-testing supplicant-timeout 10
set protocols dot1x authenticator interface dot1x-testing maximum-requests 3
set protocols dot1x authenticator interface dot1x-testing server-fail use-cache

How does it work? Successful Machine-to-User Authentication

Ok, so we’ve got this hack on the switch side of things to leverage the 60 second timer on the Windows side of things and quickly fail dot1x over to MAB. But how does it actually work?

… I’m no Veritasium , but here’s the breakdown of how this whole thing works. Prepare your eyes for this eye chart.

We assume machine authentication has succeeded (see above) and/or machine network connectivity is functioning normally.
A new user to the machine logs into Windows device and begins user authentication processes.
Wired-AutoConfig restarts the authentication process and ends the EAP session due to the user logging into the device.
The NDIS authorization state changes from ‘Authorized’ to ‘Unauthorized’.
Wired-AutoConfig starts, but because the user does not have a client certificate yet, the Wired-AutoConfig service sends a null/blank certificate list to the NAC.
Switch forwards the EAP authentication message to the NAC.
NAC immediately denies the authentication session due to a blank certificate and sends an ‘Access-Reject’ to the switch because of blank certificate.
Wired-AutoConfig receives EAP failure and immediately suspends any authentication services for 60 seconds.
Note: NDIS is not dependent on an 802.1x success to be operational and will maintain a DHCP lease if it has one.
Because Juniper switch is configured with 3 retries and a supplicant timeout of 10 seconds, the switch will fail the dot1x process due to having 3 failures and will move to MAC authentication.
The switch forwards the Windows machine MAC address to the NAC for MAC authentication.
The NAC will search its endpoint identity groups. In this instance, it looks up ‘internal endpoints’ for membership, authenticates and authorizes the endpoint based on policies and sends an ‘Access-Accept’.
Switch marks the port as authorized and maintains the device’s active network state.
Because the network connectivity is functional the machine can communicate with the internal PKI, the user enrolls and obtains a client certificate.
The Wired-AutoConfig 60 second timer expires and the service tries to authenticate the user with a client certificate from the user. The user has a certificate at this point and so the Wired-AutoConfig service sends the certificate to the NAC.
Switch receives dot1x authentication for the port and forwards this to the NAC.
NAC will check the certificate for authentication, and then will check for authorization of the device. At this point, ISE will either send an ‘Access-Accept’ or ‘Access-Reject’. We’re assuming an accept here.
Switch restarts EAP session with an authorization and forwards the EAP success to the machine.
The user’s session enters an authenticated and authorized state, and the NDIS Auth State transitions to ‘Authorized’.
Windows machine then proceeds forward with DHCP discovery or normal network connectivity.

The HUGE version of this can be found here:

NAC MAB Group

The solution used in this post relies on the built-in Cisco ISE local endpoint identity group called ‘internal endpoints’. For this solution, when a machine authenticates to the network, the device gets identified and a general ISE profile is made of the device, which by default adds the device to the group ‘internal endpoints’, which is how MAB/MAC authentication works when RADIUS fails during the 60 second timeout by WiredAuthconfig on the Windows machine.

Generally speaking, this works, but the issue with the ‘internal endpoints’ group is that it includes any device with a MAC address that connects – all devices that connect are added to the group.

If your risk tolerance is high, this solution may not work. I have not confirmed this, but I believe a solution for this is to create a specific endpoint identity group for these hotdesk devices. Doing this in an automated fashion on ISE would require the posture licensing, so that may be out of the mix…. The other approach would be to just manually account for these hotdesk devices and statically assign the devices to this group. However, this adds to the already complex configuration that exists here.

I believe the risk here is small, so I think internal endpoints works fine.

Final Thoughts on Process

Simplicity vs. Complexity

I think the solution identified here is pretty slick for the dot1x-hotdesking issue because it maintains an EAP-TLS configuration and doesn’t require extra configuration on the Windows devices, or require reboots on devices, etc.

However, I think this solution comes at the cost of complexity. Some might consider this a bit of a ‘Mouse Trap’ solution, but the problem itself is complicated. As a result, the entire solution needs to be properly documented and diagrammed to understand the interdependency that exists within the system, which is really no more complicated than any other zero trust security framework.

If this or any other complex system with many interdependencies isn’t properly documented, it becomes too much of a snowflake, and the institutional knowledge that someone may have about how it all works becomes a huge risk (aka, the bus factor).

Improving Network Security of MAB Solution

I think the security of this solution could be improved by assigning VLANs/Tunnel-Group-IDs and sending these in the Access-Accept to the switch so that the MAB device that has some kind of firewalling/access control list in-place to allow the Windows device to perform for just certificate enrollment and any other login services that may be needed.

Bonus Information

Windows Details

A lot of my time during the initial phase was breaking down the logs used in Windows. Below is some of those notes and research I did.

Windows Event Viewer IDs in the Wired-AutoConfig Log

The ‘Wired-AutoConfig’ log can be found in the following location:

Event Viewer > Applications and Services Logs > Microsoft > Windows > Wired-AutoConfig

Note

Windows has a wireless version of this log called ‘WLAN-AutoConfig’, but the event IDs are completely different.

Below is a list of event IDs from the Wired-AutoConfig log.

Event ID Reference Table

Event ID	Description
14001	Logged when an existing wired group policy is applied to a computer
14002	Wired policy is removed from the computer
15500	Logged when a network adapter has been unplugged
15501	Logged when a network adapter has been connected
15502	Logged when a profile is applied on a network adapter (contains details about profile type and content)
15504	Logged when Wired 802.1X Authentication was restarted (includes network adapter details, interface GUID, connection ID, and restart reason)
15505	Logged when Wired 802.1X Authentication succeeded (includes network adapter details, peer/local addresses, connection ID, identity, and authentication results)
15506	Logged when network authentication attempts have been temporarily suspended on a network adapter (includes reason code and length of block timer in seconds)
15508	Logged when there has been an NDIS port state change on a network adapter (shows control state and authorization state)
15511	Logged when the Wired AutoConfig service entered the running state
15514	Logged when 802.1X authentication fails (includes failure reason, such as “internal authentication error” or “the authenticator is not present”)
15515	Logged when the Wired AutoConfig service is starting

Generally speaking, the event IDs can have mixed messages in them. For example, 15508 indicates an NDIS Port State change, but that can mean the port is authorized or unauthorized. For example, see below:

Event 15508 - NDIS Auth State: Unauthorized

Event 15508 - NDIS Auth State: Authorized

Warning

The event IDs, to the best of my knowledge and searching, are not found in a single location from Microsoft. Working with Perplexity to search for these event IDs, they appear to be in various discontiguous locations.

For example:

15506 can be found here
15500 can be found here

It’s a hot mess:

Windows-Juniper EX-ISE Authentication Process

Below is baseline to understand and see how the process works. Yes, some of the images are an eye chart, but I’m trying to compress a lot of data and detail from the whole 802.1x process.

This is showing a successful machine authentication process, but it looks the same for users (more or less).

Windows machine powers on and eventually the ‘Wired-AutoConfig’ service and authentication process starts.
Machine/user applies group policy objects and any other policies relating to 802.1x authentication. As a result of the policies for this machine, 802.1x is enabled, but not enforced on network interface (enforcement corresponds to NDIS control state).
Machine/user starts dot1x authentication and begins EAP-TLS authentication, sending certificate to NAC through the switch.
The switch (Juniper EX in this case), acts as the network access server and forwards certificate to NAC.
NAC (ISE in this case) will check the certificate for authentication, and then will check for authorization of the device. At this point, ISE will either send an ‘Access-Accept’ or ‘Access-Reject’. We’re assuming an accept here.
The switch transitions the port to an authorized state and sends an EAP-Success to the Windows machine.
Machine enters an authenticated and authorized state, and the NDIS Auth State transitions to ‘Authorized’.
Windows machine then proceeds forward with DHCP discovery or normal network connectivity.

Full version of the diagram:

Links for Further Reading

Juniper Mist Teleworker Wired Port Tunneling and Dot1x

Jimmy Taylor — Tue, 15 Apr 2025 00:00:00 +0000

In this post, I’m going to get straight to the point and answer three questions I had about the Juniper teleworker solution that I eventually solved through trial and error. This is focused on configuring the additional wired ports available—at the time of writing—on AP12, AP41, AP43, AP45, and AP47.

The three questions:

How are tunnels established between the additional wired ports on APs that have eth1+ (i.e., eth1-4)?
What are the differences between creating a device profile in the Mist UI and creating one via the API?
How can an API call be made to create or modify a device profile that also configures RADIUS/802.1x on AP wired Ethernet ports?

(Mist Teleworker Solution Amended with Wired Teleworker Connection (Click for larger version))

How are tunnels established between the additional wired ports on APs that have eth1+ (i.e., eth1-4)?

The official documentation on wired port configuration is not entirely clear on this question. At best, it says:

Note

Use the additional wired ports to extend a tunneled VLAN to a wired port.

The problem with this is: I’m an idiot, so I need something a bit more clear and detailed that explains the why of a configuration.

Here’s what I learned about device profiles and/or the configuration of these AP Ethernet ports in my own words:

On port eth0, this is your main uplink and it is a trunk (see item ‘A’ on the diagram). The default VLAN is ‘1’ on this port, and this should pretty much be left alone on teleworker APs, so keep this port configured with VLAN 1.
If you configure other VLANs on the eth0 trunk (item ‘A’), ensure the VLANs on the trunk do not match the VLAN IDs on the other wired Ethernet ports (eth1-4, item ‘B’) because the AP will then trunk those VLANs to port eth0.
(Important) If the VLAN IDs on ports eth1-4 (item ‘B’) match the VLANs on a Mist tunnel configured on a Mist Edge (item ‘E’), the Mist AP will establish a tunnel (item ‘C’) for those ports.
(Important) The tunnel used will be the same tunnel configured for wireless SSID tunneling (aka, ‘wxtunnel’ in the API, item ‘D’). If you do not configure a tunnel for a wireless SSID (‘Custom Forwarding’ in the WLAN configuration), I can only infer—but have not validated—that you will need to use API calls because there are no configuration options in the Mist UI for tunnels to select. (I say this because dot1x configuration is not in the UI, and is also only configurable in the API, but more on that later.)

See the following tunnel configuration from a Mist Edge configuration.

If VLANs 800 and 900 are on the tunnel (in my hypothetical) in the Mist Edge configuration, and if the VLANs are configured on the ports (see below), then tunnels will be established.

In summary, items ‘B’ on the main teleworker diagram need to exist on items ‘E’ in the Mist Edge tunnel configuration for the wired ports to tunnel back to the Mist Edge.

What are the differences between creating a device profile in the Mist UI and creating one via the API?

Mist UI

For the APs, the Mist UI has device profile options that probably meet 90%+ of the use cases needed.

On the API side of things, the Mist UI configures the following:

{
    "poe_passthrough": false,
    "disable_eth1": false,
    "disable_eth2": false,
    "disable_eth3": true,
    "disable_module": true,
    "radio_config": {},
    "mesh": {
        "enabled": false,
        "role": "base",
        "group": null
    },
    "ip_config": {
        "type": "dhcp",
        "mtu": 0
    },
    "ble_config": {
        "power_mode": "default",
        "beacon_enabled": true
    },
    "switch_config": {
        "enabled": true,
        "eth0": {
            "vlan_ids": [
                1
            ],
            "port_vlan_id": ""
        },
        "eth1": {
            "vlan_ids": [
                800
            ],
            "port_vlan_id": ""
        },
        "eth2": {
            "vlan_ids": [
                900
            ],
            "port_vlan_id": ""
        },
        "eth3": {
            "vlan_ids": [],
            "port_vlan_id": ""
        },
        "module": {
            "vlan_ids": [],
            "port_vlan_id": ""
        },
        "wds": {
            "vlan_ids": [],
            "port_vlan_id": ""
        }
    },
    "esl_config": {
        "enabled": false,
        "type": "imagotag",
        "host": "",
        "channel": null,
        "vlan_id": 1
    },
    "aeroscout": {
        "enabled": false,
        "locate_connected": false,
        "host": "",
        "port": 1144
    },
    "uplink_port_config": {
        "dot1x": false
    },
    "centrak": {
        "enabled": false
    },
    "vars": {},
    "id": "00000000-0000-0000-0000-000000000000",
    "name": "dummy-profile",
    "org_id": "00000000-0000-0000-0000-000000000000",
    "created_time": 1748479960,
    "modified_time": 1748479960,
    "type": "ap"
}

Note

I’m using the Mist API Extension to quickly gather this information:

GitHub - Mist-Automation-Programmability/mist_browser_extension

This is a web browser extension for Mist Developers to provide quick access to Mist APIs. The application analyzes the URL of the current tab to provide the org_id, site_id (if any), object_id (if any), and quick access to the main API calls for this page. It can also be used to manage and generate User and Org API Tokens.

The Mist UI configures default device profile options using the ‘switch_config’ property in the API.

If you look at the configuration, though, there are actually very few options:

If you use the API, though, there are far more options. See below.

Mist API

The Mist API has a property option not available in the UI: port_config.

Ap Port Config - Mist API Reference

This property contains options for dot1x, MAC auth, Mist NAC, and more, providing much more versatility than the switch_config property. In fact, in the older Mist API documentation* , it makes the following note:

// eth0 is not allowed here
// if specified, this takes precedence over switch_config (deprecated)

Which, as it turns out, means port_config takes precedence over switch_config. However, port_config options are not available in the Mist UI, only in the API.

Note

For the older Mist documentation, the link they state doesn’t appear to work.

https://api.mist.com/api/v1/docs/home

You’ll need to append the URL with your instance; e.g., my demo lab is in Global 3, so my old API link is:

https://api.ac2.mist.com/api/v1/docs/home

How can an API call be made to create or modify a device profile that also configures RADIUS/802.1x on AP wired Ethernet ports?

I’m doing this the easy way: Postman.

Mist Cloud APIs 2505.1.1 Documentation

I’ve made the following API call:

createOrgDeviceProfiles or updateOrgDeviceProfiles

Using port_config, we have options to configure MAC-based authentication, dot1x-based authentication, and other options. For the problem I was trying to solve, I used the following body statement to configure dot1x ports with Mist Access Assurance.

{
  "led": {
    "brightness": 255,
    "enabled": true
  },
  "name": "Teleworker-AP",
  "type": "ap",
  "port_config": {
    "eth1": {
      "disabled": false,
      "enable_mac_auth": true,
      "mac_auth_protocol": "eap-md5",
      "forwarding": "mxtunnel",
      "mxtunnel_id":"00000000-0000-0000-0000-000000000000",
      "mac_auth_preferred": false,
      "mist_nac": {
        "enabled": true
      },
      "port_auth": "dot1x",
      "vlan_id": 900,
      "vlan_ids": [
        900
      ]
    }
  }
}

In this configuration:

I’m configuring MAC-based authentication (enable_mac_auth)
Configuring the tunnel to use, which is the same tunnel being used by the WLAN profile (mxtunnel_id)
- Note: You cannot use different tunnels on wired and wireless ports; i.e., you cannot have wxtunnels and mxtunnelsj with different tunnel IDs. The AP establishes only one tunnel at a time.
Using Access Assurance (mist_nac, and be sure to also enable it with "enabled": true)
Doing dot1x port authentication on the wired ports (port_auth)

That’s the gist of it.

Hope that helps.