ISE – TEAP Authentication without Agent

[camilosilva]

Good morning, Experts,

I’m currently working on implementing an ISE deployment that will operate solely as a RADIUS server for both WLAN and LAN authentication. The authentication process must meet the following requirements:

• VLAN Assignment:
  The client is coming from a fully wired model (since Wi-Fi has been deemed unreliable due to several issues that are being addressed in the new implementation). Therefore, Active Directory groups have been created so that, depending on the group a user belongs to, the corresponding VLAN is assigned regardless of the connection medium (LAN/WLAN).

• Secure Authentication:
  To enhance authentication security, we proposed using certificate-based chained authentication with TEAP (EAP-TLS), validating both user and machine certificates.

At the moment, I have a few doubts regarding the system’s behavior — some things are working but not in a way that aligns with the theory, and others aren’t working at all (though I’m not sure if they’re actually required).

Due to legal restrictions, I can’t share configuration screenshots, so I’ll describe everything as clearly as possible using [ ] notation.

---

Authentication Policy

• This section is standard — validating certificates + AD sequence.

Authorization Policy

• [Technology] [(Member of “Technology” AD group) AND (Both user and machine authentication succeeded)] → [Assign VLAN 10]

• [Development] [(Member of “Development” AD group) AND (Both user and machine authentication succeeded)] → [Assign VLAN 11]

• [Sales] [(Member of “Sales” AD group) AND (Both user and machine authentication succeeded)] → [Assign VLAN 12]

If none of the above conditions are met, deny access.

---

Questions:

1. Documentation indicates that an authorization policy must exist to allow machine-only authentication (for example, when user authentication fails but the machine is successfully authenticated).
   However, when I add this policy, machines authenticate but do not get assigned to any VLAN, resulting in no IP address — they remain stuck in that state.
   When I remove that policy, user authentication works properly, and I can see both user and machine certificates in the logs.
   → Is it redundant to include that machine-only authorization rule?

2. I understand that ISE uses the RADIUS CoA (Change of Authorization) extension to trigger VLAN changes. However, when checking the communication between ISE and the switches/APs, I don’t see any traffic on UDP port 1700.
   → What could be causing this behavior?

3. The IT group connects remotely to office PCs via RDP, and I’ve observed that when I enable the machine-only authorization policy this stops working — but if I remove that policy, RDP works without issue. I understand that the recommended approach for this scenario is to use the Network Access Manager (NAM) agent, but initially I would like to understand why this behavior occurs.

   I’d like to thank everyone in advance for any guidance or insight you can provide.

[Rodrigo Diaz]

Greetings @camilosilva , below my thoughts related to your post: 

1.- Given the environment and scenario you are providing the answer is yes, the policy for machine only auth is something redundant.

The TEAP/eap chaining is going to depend here mostly in how your supplicant is handling the authentication, in some scenarios the supplicant is going to send credentials for machine authentication first or in a similar way in which you mention it where both machine and user authentication happens simultaneously, that is the reason a policy for machine only with certain level of access is suggested so the following authentication for the user can occur to complete the chaining. 

2.- Related to that question, the CoA can be generated not only during a eap chaining flow but for other flows such as profiling/posture and so on, so I would review if CoA traffic is generated  first through livelogs/captures from ISE , if traffic CoA from ISE is triggered there but you don't see changes on the radius sessions on NAD, it can be some other problem related to configuration/communication on UDP 1700. 

3. To provide you some understanding of that particular flow , this may require some analysis of the scenario you are facing alongside logs and your configurations, I would encourage you to open a TAC ticket for this one . 

Please rate and comment if that helps. 

[Dustin Anderson]

So, we ran into a similar issue with RDP, and can tell you with I think it was Windows 8 and on, RDP is not treated as a user login, so it will only do machine auth. As such, your rules will not hit with the default windows authentication.

As for why it didn't work, it would depend on what your rules were. If you move to a restricted vlan or such then you will have issues with an IP change. Best is if you have a restricted vlan, star the device on it so it doesn't move vlans after authentication for RDP.