From: Alan T. DeKok Date: Fri, 14 May 2021 12:48:52 +0000 (-0400) Subject: rerun "make asciidoc" X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1d30acb57073d469540469e42eecc3ee00dbfa42;p=thirdparty%2Ffreeradius-server.git rerun "make asciidoc" --- diff --git a/doc/antora/modules/raddb/pages/dictionary.adoc b/doc/antora/modules/raddb/pages/dictionary.adoc index 84628e016d2..0dd426a06c8 100644 --- a/doc/antora/modules/raddb/pages/dictionary.adoc +++ b/doc/antora/modules/raddb/pages/dictionary.adoc @@ -47,10 +47,73 @@ required, or add your own. + +## v3 Compatible names. + +All of the attributes have been renamed from v3. This change was +necessary in order to support new funtionality in v4. The +unfortunate side effect of this change is that all of the names in +SQL, LDAP, and the "files" module are incompatible with v4. + +We recognize that is is difficult to change every entry in a +database, especially when there's no clear mapping between the +"old" and "new" names. This renaming is made more complex because +the "new" names need to be grouped and arranged in ways that the +old ones were not. + +The "old" names were all in flat lists, so that User-Name appeared +next to Cisco-AVPAir. This organization was simple enough to work +for 20 years, but its time has come. The new names are +hierarchical, so that the organization is nested by definition. + +For v4, the Cisco-AVPair attribute is called "AVPair", and it lives +inside of the "Cisco" namespace, which in turn lives inside of the +"Vendor-Specific" namespace. So the new name for Cisco-AVPair is +Vendor-Specific.Cisco.AVPair. + +This process continues for many thousands of vendor-specific +attributes. + +Happily, it is possible to (mostly) use the old names with v4. +There are limitations, but it will mostly work. The main reason +for enabling the old names is to try out v4 with a database that is +also used by v3. This lets you test that v4 works, without going +through a complex "upgrade everything" process. + +The old v3 names are in "alias" dictionaries, in the ${dictdir} +directory. To find out where this directory is on your local +system, run "radiusd -h" or "radclient -h". Then look for the "-D" +command-line option, and it will tell you where the dictionary +files are located. + +The v3 names are in ${dictdir}/radius/alias/alias.VENDOR where +VENDOR is the name of the vendor, which is taken from the VENDOR +definition in the v3 dictionaries. + +You will need to add a $INCLUDE line for each vendor-specific +dictionary which is used by your local system. The default v4 +dictionaries do not enable all of v3 compatibilty names. + +Yes, we recognize that this process is a bit of work. However, we +wish to encourage everyone using v4 to upgrade to using the new v4 +features. Our experience shows that if we automatically enable +"compatibility functions", then those compatiblity functions will +be used for a decade. So we need to find a balance between +upgrades and ongoing support. Easy upgrades will mean complex +ongoing support. Complex upgrades make ongoing support easier, but +also make it less likely that people will upgrade. + + +All of the v3 compatibility names are in the RADIUS namespace. + + == Default Configuration ``` #ATTRIBUTE My-Local-String 3000 string #ATTRIBUTE My-Local-IPAddr 3001 ipaddr #ATTRIBUTE My-Local-Integer 3002 integer +BEGIN-PROTOCOL RADIUS +#$INCLUDE ${dictdir}/radius/alias/alias.cisco +END-PROTOCOL RADIUS ``` diff --git a/doc/antora/modules/raddb/pages/mods-available/eap.adoc b/doc/antora/modules/raddb/pages/mods-available/eap.adoc index 0508447be2a..751beb930d6 100644 --- a/doc/antora/modules/raddb/pages/mods-available/eap.adoc +++ b/doc/antora/modules/raddb/pages/mods-available/eap.adoc @@ -20,6 +20,28 @@ then cannot use ANY other authentication method. ## Configuration Settings +require_identity_realm:: Require the the EAP Identity provided contains +a realm. + +If `require_identity_realm` is `nai`, the EAP identity provided must +end with `@.[.]`, i.e. an '@' followed by at least +two DNS labels. + +If `require_identity_realm` is `yes`, the EAP identity provided must +either match the NAI format described above, or a `Stripped-User-Domain` +attribute must be present in the request list. +This validation mode is intended to be user where Windows machine +authentication is intermixed with user authentication. + +If `require_identity_realm` is `no`, no identity format checks are performed. +It is NOT recommended to use this value. Future security standards will +key off the NAI realm to validate the certificate we (the EAP server) present. +If you do not require an NAI realm be present in the EAP identity string, +your users will not be able to take advantage of this added security when +it is enabled by OS and device vendors. + + + default_eap_type:: The default EAP submodule to invoke when an `EAP-Identity` response is received. @@ -1581,6 +1603,7 @@ TODO ``` eap { +# require_identity_realm = nai # default_eap_type = md5 ignore_unknown_eap_types = no type = md5