TEAP Chaining and Partial Success Policies
Hello everyone, I'm following up on a thread from with the subject of "EAP-TEAP not doing 2nd inner Method" from December 2024 (https://lists.freeradius.org/pipermail/freeradius-users/2024-December/105155...) about TEAP and setting network policies based on partial success (e.g., Machine cert succeeds, but User cert fails). I would specifically like to ask for clarification about something Alan DeKok wrote in the mentioned thread:
Exactly. None of the implementations (even Windows) support this workflow.
I agree that the client side is a huge hurdle here, but I’m confused because some commercial platforms like Cisco ISE and Aruba ClearPass explicitly advertise and allow admins to configure different VLANs/ACLs precisely for that partial success scenario. Since the commercial vendors seem to have found a way to achieve this, are they relying on some vendor-specific extensions or a different, non-TEAP chaining method entirely? Is it possible to configure this in FreeRADIUS at all? Any insight into how FreeRADIUS could be configured to accurately process the final result and differentiate between Machine-only, User-only success and Full success would be hugely helpful. Thanks for the clarification! Best regards, Jan K.
On Dec 9, 2025, at 11:06 AM, Jan Kříž <jan.kriz1867@gmail.com> wrote:
I'm following up on a thread from with the subject of "EAP-TEAP not doing 2nd inner Method" from December 2024 (https://lists.freeradius.org/pipermail/freeradius-users/2024-December/105155...) about TEAP and setting network policies based on partial success (e.g., Machine cert succeeds, but User cert fails).
I really don't see how that is supported by anything. I've spent about 3 years going over the TEAP specifications, and the TEAP implementations. I don't see anything in them which allows that work flow. The inner authentications are bound to the outer TLS session via various crypto magic. The result is that the outer authentication succeeds only when the inner authentication succeeds. So I don't see any way in the specification which could allow machine EAP-TLS to succeed, fail at user EAP-TLS, but still allow the user online. I could very well be missing something. But if I am, then this behavior is not explicitly allowed by the specification. So it's an accidental outcome. The specification needs to be updated to mention this, and then either explicitly allow it, or forbid it.
I agree that the client side is a huge hurdle here, but I’m confused because some commercial platforms like Cisco ISE and Aruba ClearPass explicitly advertise and allow admins to configure different VLANs/ACLs precisely for that partial success scenario.
Since the commercial vendors seem to have found a way to achieve this, are they relying on some vendor-specific extensions or a different, non-TEAP chaining method entirely? Is it possible to configure this in FreeRADIUS at all?
You'll have to try it and see. I don't have time right now to test it, unfortunately.
Any insight into how FreeRADIUS could be configured to accurately process the final result and differentiate between Machine-only, User-only success and Full success would be hugely helpful.
You will have to update the "eap_teap.c" code to allow TEAP to continue when one of the inner methods fails. Right now, an inner reject results in the entire TEAP session failing. You can't edit the configuration to allow this. When the TEAP code was written, I was assuming that failure means failure. If the Windows TEAP implementation is OK with the above work flow, then that's a surprising bit of information. Alan DeKok.
Hi Alan, Thank you very much for addressing this. 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. 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. 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, and rely on the authorization layer to map that combined state to the appropriate access level. This also implies that the Windows TEAP supplicant is willing to accept a TEAP Success result even when an inner EAP conversation completed with a failure.
You will have to update the "eap_teap.c" code to allow TEAP to continue when one of the inner methods fails. Right now, an inner reject results in the entire TEAP session failing. You can't edit the configuration to allow this. When the TEAP code was written, I was assuming that failure means failure. If the Windows TEAP implementation is OK with the above work flow, then that's a surprising bit of information.
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? Best regards, Jan K. On Tue, Dec 9, 2025 at 5:14 PM Alan DeKok via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On Dec 9, 2025, at 11:06 AM, Jan Kříž <jan.kriz1867@gmail.com> wrote:
I'm following up on a thread from with the subject of "EAP-TEAP not doing 2nd inner Method" from December 2024 (https://lists.freeradius.org/pipermail/freeradius-users/2024-December/105155...) about TEAP and setting network policies based on partial success (e.g., Machine cert succeeds, but User cert fails).
I really don't see how that is supported by anything. I've spent about 3 years going over the TEAP specifications, and the TEAP implementations. I don't see anything in them which allows that work flow.
The inner authentications are bound to the outer TLS session via various crypto magic. The result is that the outer authentication succeeds only when the inner authentication succeeds.
So I don't see any way in the specification which could allow machine EAP-TLS to succeed, fail at user EAP-TLS, but still allow the user online.
I could very well be missing something. But if I am, then this behavior is not explicitly allowed by the specification. So it's an accidental outcome. The specification needs to be updated to mention this, and then either explicitly allow it, or forbid it.
I agree that the client side is a huge hurdle here, but I’m confused because some commercial platforms like Cisco ISE and Aruba ClearPass explicitly advertise and allow admins to configure different VLANs/ACLs precisely for that partial success scenario.
Since the commercial vendors seem to have found a way to achieve this, are they relying on some vendor-specific extensions or a different, non-TEAP chaining method entirely? Is it possible to configure this in FreeRADIUS at all?
You'll have to try it and see. I don't have time right now to test it, unfortunately.
Any insight into how FreeRADIUS could be configured to accurately process the final result and differentiate between Machine-only, User-only success and Full success would be hugely helpful.
You will have to update the "eap_teap.c" code to allow TEAP to continue when one of the inner methods fails. Right now, an inner reject results in the entire TEAP session failing.
You can't edit the configuration to allow this. When the TEAP code was written, I was assuming that failure means failure. If the Windows TEAP implementation is OK with the above work flow, then that's a surprising bit of information.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 9, 2025, at 2:15 PM, Jan Kříž <jan.kriz1867@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.
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@inkbridge.io> wrote:
On Dec 9, 2025, at 2:15 PM, Jan Kříž <jan.kriz1867@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.
Hi Alan, I have a implementation of EAP-TEAP from EAP-FAST which is very similar to what we have in the 3.2x where I am overriding the tls decision "TEAP-Idenity-Ordinal" (gives me its machine/user) +#define TEAP_MACHINE_CERT "1" +#define TEAP_USER_CERT "2" + #ifdef ENABLE_OPENSSL_VERSION_CHECK typedef struct libssl_defect { uint64_t high; @@ -1651,6 +1654,7 @@ static CONF_PARSER tls_server_config[] = { #endif { "ca_path_reload_interval", FR_CONF_OFFSET(PW_TYPE_INTEGER, fr_tls_server_conf_t, ca_path_reload_interval), "0" }, { "allow_expired_crl", FR_CONF_OFFSET(PW_TYPE_BOOLEAN, fr_tls_server_conf_t, allow_expired_crl), NULL }, + { "allow_cert_failure", FR_CONF_OFFSET(PW_TYPE_BOOLEAN, fr_tls_server_conf_t, allow_cert_failure), "no" }, { "check_cert_cn", FR_CONF_OFFSET(PW_TYPE_STRING, fr_tls_server_conf_t, check_cert_cn), NULL }, { "cipher_list", FR_CONF_OFFSET(PW_TYPE_STRING, fr_tls_server_conf_t, cipher_list), NULL }, { "cipher_server_preference", FR_CONF_OFFSET(PW_TYPE_BOOLEAN, fr_tls_server_conf_t, cipher_server_preference), NULL }, @@ -3145,6 +3149,23 @@ int cbtls_verify(int ok, X509_STORE_CTX *ctx) X509_STORE_CTX_set_error( ctx, 0 ); } + if (!my_ok && (conf->allow_cert_failure)) { + VALUE_PAIR *teap_ordinal_vp = NULL; + DICT_ATTR const *teap_attr = dict_attrbyname("TEAP-Identity-Ordinal"); + if (teap_attr) { + teap_ordinal_vp = fr_pair_find_by_da(request->packet->vps, teap_attr, TAG_ANY); + // If TEAP User Certificate -> override the decision to success + if (strcmp(teap_ordinal_vp->vp_strvalue, TEAP_USER_CERT) == 0) { + DEBUG("TEAP context detected - Overriding User Cert Failure!"); + my_ok = 1; + X509_STORE_CTX_set_error( ctx, 0 ); + } + } else { + // TODO: Remove this later + DEBUG("Extracting teap_ordinal something went wrong!"); + } + } I know this is deviating from the RFC but I was able to override the TLS failure if this helps Thanks, Suriya On Tue, Dec 9, 2025 at 12:40 PM Jan Kříž <jan.kriz1867@gmail.com> wrote:
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@inkbridge.io> wrote:
On Dec 9, 2025, at 2:15 PM, Jan Kříž <jan.kriz1867@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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Jan Kříž -
Suriya Shankar