net/freeradius: restore EAP-TTLS-GTC support and fix EAP-GTC against directories that do not expose passwords (#2421) - #5692
Open
clanto007 wants to merge 3 commits into
Conversation
…urable (opnsense#2421) The inner EAP method was hardcoded to md5, so EAP-TTLS-GTC could not be used. Support was added in 1.9.9 as a "ttls-gtc" value of the outer default_eap_type, which radiusd rejected with "No dictionary definition for default EAP method 'ttls-gtc'"; 1.9.20 removed the option again and left the template branch testing for it unreachable. Add a separate default_eap_ttls_type field holding a real EAP method and use it inside the ttls block, replacing the dead branch. Non-EAP inner methods such as PAP are handled by the inner-tunnel virtual server and are deliberately absent from the option list, as radiusd fails to start on a non-EAP value. The field defaults to md5, keeping existing configurations unchanged, and is hidden unless TTLS is the outer type.
…expose passwords rlm_eap_gtc places the password in the request and calls the Auth-Type section directly, without re-running authorize. The section ran pap unconditionally, which needs a known good password in the control list. Directories that never reveal one, such as Google Workspace Secure LDAP, therefore always failed with "EAP sub-module failed". Bind against LDAP instead when no password is available, keeping pap for the local users file so both backends can be used at the same time. The change only applies when LDAP is enabled in the inner tunnel.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important notices
Describe the problem
Two separate problems, both preventing EAP-TTLS-GTC from working.
The EAP method used inside the EAP-TTLS tunnel is hardcoded to
md5, so GTC cannot be selected. Support was added in 1.9.9 as attls-gtcvalue of the outerdefault_eap_type, which is not a valid EAP method: radiusd refused to start withNo dictionary definition for default EAP method 'ttls-gtc'([Freeradius] Support for EAP-TTLS-GTC is broken #2421). 1.9.20 removed the option from the model instead of correcting the implementation, leaving the template branch that tests forttls-gtcpermanently unreachable and the inner method fixed atmd5.Even with GTC available, authentication fails against any directory that does not reveal password material.
rlm_eap_gtcputs the password in the request and calls theAuth-Typesection directly, without re-runningauthorize; that section ranpapunconditionally, andrlm_papneeds a known good password in the control list. With Google Workspace Secure LDAP, which only supports bind-based authentication, every request ends inEAP sub-module failed.Describe the proposed solution
Three commits.
Add a
default_eap_ttls_typefield holding a real EAP method and use it inside thettlsblock, replacing the dead branch. Non-EAP inner methods such as PAP and MSCHAPv2 are handled by the inner-tunnel virtual server and are deliberately absent from the option list, since a non-EAP value makes radiusd fail to start — this is what went wrong in 1.9.9. The field defaults tomd5, so existing configurations render byte-identical output and no model migration is needed, and it is hidden in the GUI unless TTLS is the selected outer type.In the inner tunnel, bind against LDAP when no password is available, keeping
papwheneverCleartext-Password,Password-With-HeaderorNT-Passwordis present. Local users therefore keep the existing code path and LDAP users gain a working one, so both backends can be used at the same time. Guarded by the existing "LDAP in inner-tunnel" setting, so installations without it are untouched.Version bump and changelog.
Tested on a live instance: EAP-TTLS-GTC from a real access point against Google Workspace Secure LDAP,
Login OK ... via TLS tunnel, and local users accepted from the same configuration.Related issue
#2421