TEAP Chaining and Partial Success Policies

[Jan Kříž]

> 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.

Oh I see, I misunderstood it completely. Thank you for pointing this out.

> 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.

This is exactly what I tried to set up in FreeRADIUS some time ago,
but I must have misconfigured something and if you say the
configuration for this is complex, I most likely just did it wrong.
Looking forward to those patches and thank you very much for
clarifying this to me.

On Tue, Dec 9, 2025 at 8:57 PM Alan DeKok <alan.dekok at inkbridge.io> wrote:
>
> 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.
>