TEAP Chaining and Partial Success Policies

[Alan DeKok]

On Dec 9, 2025, at 2:15 PM, Jan Kříž <jan.kriz1867 at gmail.com> wrote:
> To give a bit more context on why I went down this rabbit hole: I was
> researching options for handling "partial failures", specifically the
> "chicken and egg" scenario where a user certificate is missing on a
> freshly provisioned device.

  The situation of *skipping* user authentication is very different from allowing *failed* user authentication.

  TEAP explicitly allows the server to say certain kinds of authentication are allowed (but not required), or required.

> That led me to a "Wires and Wi-Fi" blog
> post describing how TEAP is based on EAP-FASTv2 and how EAP chaining
> allows the server to make decisions based on combined states,
> including "User Failed and Machine Succeeded"
> (https://www.wiresandwi.fi/blog/windows-network-authentication-sequence).
> 
> According to that explanation, Windows can perform machine-only
> authentication during startup, even when the user certificate does not
> exist yet, and the RADIUS server can return an Access-Accept with a
> restricted authorization profile. This gives the device enough limited
> network access to reach the PKI and enroll the missing user
> certificate.

  Yes, that's explicitly allowed.  FreeRADIUS supports this with a bit of manual configuration.  I'm working on patches to make that easier.  They should be available in January.

> I also found a Cisco ISE guide showing this workflow in practice, with
> explicit rules for "Machine authenticated, User not" that grant
> reduced access, distinct from the full "User and Machine" success
> state. (https://www.ise-support.com/2020/05/29/using-teap-for-eap-chaining/).
> 
> Based on these examples, it appears that several commercial platforms
> intentionally treat the session as successful overall (sending
> Access-Accept), even when one inner method fails,

  Again, you have to double / triple check the difference between "not doing user authentication", and "did user authentication, but it failed".

  Many people confuse the two, which isn't good.

> Given that this "partial success with restricted access" behavior
> seems to have become a de facto standard method for handling similar
> scenarios, I wanted to ask whether FreeRADIUS would consider
> supporting this mode?. Or is the project's stance that FreeRADIUS
> should follow the RFC strictly until the specification explicitly
> allows this behavior?

  The server allows this today, with a manual / complex configuration.  It should be easier in a few weeks when I push some tweaks back.

  What it doesn't support is "user tried to authenticate, and got a reject.  We still allow the overall TEAP authentication to succeed".  The TEAP specs don't envision this workflow.  I would be surprised if anything supported it.

  Alan DeKok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20251209/0d38cc59/attachment-0001.sig>