FreeRADIUS is a complex piece of software with many configuration
options. However, we have taken great care to make the default
configuration work in most circumstances. The result is that for most
-simple systems, it is trivial to install and configure the server. For
+simple systems, it is easy to install and configure the server. For
those situations, this documentation will serve to answer basic
questions about functionality, configuration, etc.
This documentation will answer those questions. The FreeRADIUS team has
put substantial effort into writing the documentation for this release.
Everything in the server is fully documented, and there are many
-`how-to` guides available.
+`Howto` guides available.
include::ROOT:partial$externaldoc.adoc[]
The documentation is split into sections by subject area, oganized by
desired outcome. At a high level, the subject areas describe:
-* xref:concepts:index.adoc[Concepts] and introduction for newcomers.
-* xref:installation:index.adoc[Install] and xref:installation:upgrade.adoc[Upgrade] FreeRADIUS.
-* The syntax of the xref:unlang:index.adoc[unlang] processing language.
-* The https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/raddb[configuration files][Configuration] files located in `/etc/raddb/`, or `/etc/freeradius/`
-* Various xref:howto:index.adoc[Howto] guides.
-* xref:developers:index.adoc[Developers] documentation.
+* xref:installation:index.adoc[Install and Upgrade] Guides.
+* xref:concepts:index.adoc[Concepts] provides an high level explanation for newcomers .
+* The syntax of the xref:unlang:index.adoc[Unlang] Policy Language.
+* The https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/raddb[configuration files] located in `/etc/raddb/`, or `/etc/freeradius/`.
+* Various xref:howto:index.adoc[Howto Guides] gives step-by-step instructions on how to complete tasks.
+* xref:developers:index.adoc[Developers] documentation outlines coding standards, raising defects, and using GitHub.
-This organization means that for example, the `ldap` module will have
+This organization means that for example, the `ldap` module has
documention located in multiple places. We feel that organizing the
-documentation by desired _goal_ is better than the alternatives.
+documentation by desired *goal* is better than the alternatives.
Within each section, the documentation is split into small pages, which
are generally no more than a few screens worth of information. We feel
that having multiple small pages with cross-links is more helpful than
having a smaller number of enormous pages. This division ensures that
-(for example) the `how-to` guides are split into a series of small
+(for example) the `Howto` guides are split into a series of small
steps, each of which can be performed quickly.
We hope that this extended documentation will address any lingering
== Changes From Earlier Versions
Administrators who have version 2 and wish to upgrade to version 3
-should read the xref:installation:upgrade.adoc[upgrading] documentation.
+should read the xref:installation:upgrade.adoc[Upgrade to v3] documentation.
That documentation explains the differences between the two versions, and
how an existing configuration can be reproduced in the latest
-release. We do _not_ recommend using version 2 configuration files
-with version 3. The configuration files are _not_ compatible across a
+release. We do *not* recommend using version 2 configuration files
+with version 3. The configuration files are *not* compatible across a
major version upgrade.
== Getting Started with FreeRADIUS
====
Administrators who are new to FreeRADIUS should read the
-xref:concepts:index.adoc[Concepts section] as it describes the concepts behind
+xref:concepts:index.adoc[Concepts] section as it describes the key components behind
FreeRADIUS. It is vital for newcomers to understand these concepts, as the rest
of the documentation assumes familiarity with them.
-A detailed xref:unlang:index.adoc[unlang] reference guide is also available.
+A detailed xref:unlang:index.adoc[Unlang] reference guide is also available.
This section describes the syntax and functionality of the keywords,
data types, etc. used in the `unlang` processing language.
All of the https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/raddb[configuration files] are available in GitHub.
-For specific problem solving, we recommend the xref:howto:index.adoc[Howto] and https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/sites-available/tls[TLS Config] and https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/sites-available/README[Virtual Server] guides. These guides give instructions for reaching high-level goals, or for configuring and testing individual https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/README.rst[modules].
+For specific problem solving, we recommend the xref:howto:index.adoc[Howto]
+guides. These guides give instructions for reaching high-level goals, or
+for configuring and testing individual https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/doc/modules[modules].
-There is also xref:developers:index.adoc[Developers]documentation. This section
-documents the APIs for developers. Most people can ignore it.
+There is also xref:developers:index.adoc[Developers] documentation. This section
+documents the APIs for developers. Most people can bypass this section.
== Debugging
list] in order to ask questions and receive answers. The developers are
not on Stack Overflow, IRC, or other web sites. While the FreeRADIUS
source is available on
-https://github.com/FreeRADIUS/freeradius-server/[GitHub, window="_blank"], questions
-posted there will not be answered.
+https://github.com/FreeRADIUS/freeradius-server/[GitHub, window="_blank"], questions posted there will not be answered.
Before posting to the list, please read the
https://www.freeradius.org/documentation/freeradius-server/3.2.8/radiusd_x.html[debugging] page. That page explains
-# How to use `radiusd -X` (debug mode)
+# `radiusd -X`
-This page explains how to read the output of `radiusd -X`.
+This page explains How to use how use `radiusd` in debug mode and how to read the output of `radiusd -X` (debug mode).
The first part of the debug output is the *startup* text. Once the server is started, it prints `Ready to receive requests`. The next part of the debug output is the *packet processing* text. Both parts need to be read (and posted to the list!) in order to solve issues.
(2) suffix: Adding Stripped-User-Name = "bob"
(2) suffix: Adding Realm = "int"
(2) suffix: Proxying request from user bob to realm int
- (2) suffix: Preparing to proxy authentication request to realm "int"
+ (2) suffix: Preparing to proxy authentication request to realm "int"
(2) [suffix] = updated
(2) [files] = noop
(2) } # authorize = updated
(2) if ("%{debug_attr:reply:}" == '') {
(2) Attributes matching "reply:"
(2) EXPAND %{debug_attr:reply:}
- (2) -->
+ (2) -->
(2) if ("%{debug_attr:reply:}" == '') -> TRUE
(2) if ("%{debug_attr:reply:}" == '') {
(2) [noop] = noop
-[WARNING]
+[NOTE]
====
-Some of the following information on this page is located on other external sites. You may be redirected to https://github.com/FreeRADIUS[FreeRADIUS Project] Github or the https://github.com/FreeRADIUS[FreeRADIUS] website.
+Some of the information on this page is located on external sites. You may be redirected to https://github.com/FreeRADIUS[FreeRADIUS Project GitHub], https://www.freeradius.org/[FreeRADIUS org], or the https://www.inkbridgenetworks.com/[InkBridge Networks] websites. Other external references may also be used such as vendor or technical sites.
====
--- /dev/null
+Please see the following for a description of the FreeRADIUS mailing lists. For normal discussion of the server and how to use it, subscribe to the FreeRADIUS user-list. Only subscribe to the development list if you are interested in writing software for the new server.
+
+
+[cols="1,3"]
+|===
+|Mailing List|Description
+
+|mailto:freeradius-announce@lists.freeradius.org[freeradius-announce]
+|Announcements about FreeRADIUS, including new versions and security issues, are made here.
+
+|mailto:freeradius-users@lists.freeradius.org[freeradius-users]
+|This list is for all users of FreeRADIUS and deals with general questions related to FreeRADIUS.
+
+|mailto:freeradius-devel@lists.freeradius.org[freeradius-devel]
+|This list is for developers who are writing code for FreeRADIUS. The content is highly technical and is not suited to the average user. If you looking to contribute code, please join this list.
+
+|https://lists.freeradius.org/pipermail/freeradius-users/[User Mailing List Archive]
+|An archive of all previous posts and emails from the users' email list.
+
+|https://lists.freeradius.org/pipermail/freeradius-devel/[Developer Mailing List Archive]
+|An archive of all previous posts and emails from the developement users' email list.
+|===
--- /dev/null
+<?xml version="1.0" encoding="utf-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xl="http://www.w3.org/1999/xlink" version="1.1" viewBox="47 152 1052 514" width="1052pt" height="514pt" xmlns:dc="http://purl.org/dc/elements/1.1/"><metadata> Produced by OmniGraffle 6.2 <dc:date>2015-04-15 01:50:58 +0000</dc:date></metadata><defs><font-face font-family="Helvetica" font-size="10" units-per-em="1000" underline-position="-75.683594" underline-thickness="49.316406" slope="0" x-height="522.94922" cap-height="717.28516" ascent="770.01953" descent="-229.98047" font-weight="500"><font-face-src><font-face-name name="Helvetica"/></font-face-src></font-face><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker" viewBox="-1 -4 10 8" markerWidth="10" markerHeight="8" color="#00c0c0"><g><path d="M 8 0 L 0 -3 L 0 3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker><font-face font-family="Helvetica Neue" font-size="14" panose-1="2 0 5 3 0 0 0 2 0 4" units-per-em="1000" underline-position="-100" underline-thickness="50" slope="0" x-height="517" cap-height="714" ascent="951.99585" descent="-212.99744" font-weight="500"><font-face-src><font-face-name name="HelveticaNeue"/></font-face-src></font-face><font-face font-family="Helvetica" font-size="10" units-per-em="1000" underline-position="-75.683594" underline-thickness="49.316406" slope="-1200" x-height="522.94922" cap-height="717.28516" ascent="770.01953" descent="-229.98047" font-style="italic" font-weight="500"><font-face-src><font-face-name name="Helvetica-Oblique"/></font-face-src></font-face><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker_2" viewBox="-1 -4 10 8" markerWidth="10" markerHeight="8" color="#6c0"><g><path d="M 8 0 L 0 -3 L 0 3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker_3" viewBox="-1 -4 10 8" markerWidth="10" markerHeight="8" color="#b70000"><g><path d="M 8 0 L 0 -3 L 0 3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker_4" viewBox="-9 -4 10 8" markerWidth="10" markerHeight="8" color="#6c0"><g><path d="M -8 0 L 0 3 L 0 -3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker_5" viewBox="-1 -4 10 8" markerWidth="10" markerHeight="8" color="#d39925"><g><path d="M 8 0 L 0 -3 L 0 3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker><font-face font-family="Helvetica Neue" font-size="9" panose-1="2 0 5 3 0 0 0 2 0 4" units-per-em="1000" underline-position="-100" underline-thickness="50" slope="0" x-height="517" cap-height="714" ascent="951.99585" descent="-212.99744" font-weight="500"><font-face-src><font-face-name name="HelveticaNeue"/></font-face-src></font-face><font-face font-family="Helvetica Neue" font-size="16" panose-1="2 0 5 3 0 0 0 2 0 4" units-per-em="1000" underline-position="-100" underline-thickness="50" slope="0" x-height="517" cap-height="714" ascent="951.99585" descent="-212.99744" font-weight="500"><font-face-src><font-face-name name="HelveticaNeue"/></font-face-src></font-face><marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker_6" viewBox="-1 -4 8 8" markerWidth="8" markerHeight="8" color="#6c0"><g><path d="M 5.6 0 L 0 -2.1 L 0 2.1 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/></g></marker></defs><g stroke="none" stroke-opacity="1" stroke-dasharray="none" fill="none" fill-opacity="1"><title>Canvas 1</title><g><title>Railroad</title><path d="M 316.77165 279.28345 L 323.77165 279.28345 L 385.1811 279.28345 C 388.4948 279.28345 391.1811 281.96974 391.1811 285.28345 L 391.1811 396.8504 L 391.1811 405.02362 C 391.1811 408.33733 393.8674 411.02362 397.1811 411.02362 L 408.18897 411.02362 L 674.31496 411.02362 C 677.62867 411.02362 680.31496 408.33733 680.31496 405.02362 L 680.31496 396.8504 L 680.31496 321.64567 L 680.31496 314.64567" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><rect x="558.4252" y="303.30708" width="90.70866" height="30.330709" fill="#f6ffec"/><rect x="558.4252" y="303.30708" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(563.4252 312.47244)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="20.066245" y="10" textLength="40.576172">module x</tspan></text><path d="M 649.13385 355.25197 L 656.13385 355.25197 L 674.31496 355.25197 C 677.62867 355.25197 680.31496 352.56567 680.31496 349.25197 L 680.31496 321.64567 L 680.31496 314.64567" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><rect x="558.4252" y="332.50393" width="90.70866" height="30.330709" fill="#f6ffec"/><rect x="558.4252" y="332.50393" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(563.4252 341.66929)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="20.066245" y="10" textLength="40.576172">module y</tspan></text><path d="M 629.29133 505.55905 L 636.29133 505.55905 L 674.31496 505.55905 C 677.62867 505.55905 680.31496 502.87276 680.31496 499.55905 L 680.31496 321.64567 L 680.31496 314.64567" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line x1="181.41732" y1="270.28346" x2="216.87165" y2="270.28346" marker-end="url(#FilledArrow_Marker)" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(61.692913 206.75984)" fill="black"><tspan font-family="Helvetica Neue" font-size="14" font-weight="500" x=".212" y="13" textLength="51.576">server {}</tspan></text><rect x="510.23622" y="490.3937" width="119.05512" height="30.33071" fill="#b70000"/><rect x="510.23622" y="490.3937" width="119.05512" height="30.33071" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(515.23622 499.55905)" fill="white"><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="3.3947462" y="10" textLength="58.339844">Post-Proxy-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="61.187715" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" fill="white" x="80.08908" y="10" textLength="16.113281">Fail</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="96.202363" y="10" textLength="9.458008"> {}</tspan></text><path d="M 316.77165 270.28345 L 322.67165 270.28345 C 325.98536 270.28345 328.67165 272.96974 328.67165 276.28345 L 328.67165 276.7874 C 328.67165 280.10111 325.98536 282.7874 322.67165 282.7874 L 221.43307 282.7874 C 218.11936 282.7874 215.43307 285.4737 215.43307 288.7874 L 215.43307 295.46458 C 215.43307 298.77829 218.11936 301.46458 221.43307 301.46458 L 243.21811 301.46458 L 245.21811 301.46458" marker-end="url(#FilledArrow_Marker)" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1" stroke-dasharray="2,2"/><path d="M 316.77165 270.28345 L 322.67165 270.28345 C 325.98536 270.28345 328.67165 272.96974 328.67165 276.28345 L 328.67165 276.7874 C 328.67165 280.10111 325.98536 282.7874 322.67165 282.7874 L 221.43307 282.7874 C 218.11936 282.7874 215.43307 285.4737 215.43307 288.7874 L 215.43307 323.81103 C 215.43307 327.12474 218.11936 329.81103 221.43307 329.81103 L 243.21811 329.81103 L 245.21811 329.81103" marker-end="url(#FilledArrow_Marker)" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1" stroke-dasharray="2,2"/><path d="M 316.77165 270.28345 L 322.67165 270.28345 C 325.98536 270.28345 328.67165 272.96974 328.67165 276.28345 L 328.67165 276.7874 C 328.67165 280.10111 325.98536 282.7874 322.67165 282.7874 L 221.43307 282.7874 C 218.11936 282.7874 215.43307 285.4737 215.43307 288.7874 L 215.43307 352.1575 C 215.43307 355.4712 218.11936 358.1575 221.43307 358.1575 L 243.21811 358.1575 L 245.21811 358.1575" marker-end="url(#FilledArrow_Marker)" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1" stroke-dasharray="2,2"/><rect x="481.88976" y="252.28346" width="90.70866" height="119.05512" fill="#6c0"/><rect x="481.88976" y="252.28346" width="90.70866" height="119.05512" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(482.93955 265.7874)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="12.637224" y="10" textLength="65.05371">Authenticate {}</tspan></text><rect x="558.4252" y="360.8504" width="90.70866" height="30.330709" fill="#f6ffec"/><rect x="558.4252" y="360.8504" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(563.4252 370.01575)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="20.066245" y="10" textLength="40.576172">module z</tspan></text><rect x="481.88976" y="342.99213" width="90.70866" height="30.330709" fill="#dfffd1"/><rect x="481.88976" y="342.99213" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(486.88976 352.15749)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="8.9431976" y="10" textLength="30.009766">Auth-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="38.406088" y="10" textLength="33.359375">ype z {}</tspan></text><path d="M 398.44456 329.81103 L 410.34456 329.81103 L 448.2992 329.81103 C 451.19544 329.81103 453.5433 327.46317 453.5433 324.56693 L 453.5433 319.32282 L 453.5433 307.46458 C 453.5433 304.15087 456.2296 301.46458 459.5433 301.46458 L 469.98976 301.46458 L 471.98976 301.46458" marker-end="url(#FilledArrow_Marker_2)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><line x1="399.5" y1="329.81103" x2="471.98976" y2="329.81103" marker-end="url(#FilledArrow_Marker_2)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 649.13385 326.05512 L 661.03385 326.05512 L 674.61023 326.05512 C 677.76086 326.05512 680.31496 323.50102 680.31496 320.3504 L 680.31496 314.64567 L 680.31496 307.46458 C 680.31496 304.15087 683.00125 301.46458 686.31496 301.46458 L 753.45433 301.46458 L 755.45433 301.46458" marker-end="url(#FilledArrow_Marker_3)" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 216.87165 474.37795 L 214.87165 474.37795 L 204.4252 474.37795 C 201.11149 474.37795 198.4252 477.06424 198.4252 480.37795 L 198.4252 519.59055 L 198.4252 527.9055 C 198.4252 531.2192 195.7389 533.9055 192.4252 533.9055 L 182.30945 533.9055 L 170.40945 533.9055" marker-start="url(#FilledArrow_Marker_4)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 316.77165 474.37795 L 328.67165 474.37795 L 399.3307 474.37795 L 469.98976 474.37795 L 471.98976 474.37795" marker-end="url(#FilledArrow_Marker_5)" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 951.16535 252.28345 L 1024.5827 252.28345 C 1033.2669 252.28345 1040.31496 260.34745 1040.31496 270.28345 C 1040.31496 280.21945 1033.2669 288.28345 1024.5827 288.28345 L 951.16535 288.28345 C 942.48113 288.28345 935.43307 280.21945 935.43307 270.28345 C 935.43307 260.34745 942.48113 252.28345 951.16535 252.28345" fill="white"/><path d="M 951.16535 252.28345 L 1024.5827 252.28345 C 1033.2669 252.28345 1040.31496 260.34745 1040.31496 270.28345 C 1040.31496 280.21945 1033.2669 288.28345 1024.5827 288.28345 L 951.16535 288.28345 C 942.48113 288.28345 935.43307 280.21945 935.43307 270.28345 C 935.43307 260.34745 942.48113 252.28345 951.16535 252.28345" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(950.92125 264.28345)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="2.2091039" y="10" textLength="38.354492">Listener </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="40.563596" y="10" textLength="31.132812">proto a</tspan></text><line x1="827.71653" y1="270.28345" x2="925.53307" y2="270.28345" marker-end="url(#FilledArrow_Marker_5)" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 649.13385 383.59842 L 656.13385 383.59842 L 674.31496 383.59842 C 677.62867 383.59842 680.31496 380.91213 680.31496 377.59842 L 680.31496 321.64567 L 680.31496 314.64567" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 892.9134 301.46458 L 904.8134 301.46458 L 908.78464 301.46458 C 910.9779 301.46458 912.7559 299.68658 912.7559 297.49332 L 912.7559 283.46457 L 912.7559 275.67203 C 912.7559 272.696 915.16845 270.28345 918.1445 270.28345 L 923.53307 270.28345 L 925.53307 270.28345" marker-end="url(#FilledArrow_Marker_3)" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(897.83464 618.96063)" fill="black"><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="0" y="9" textLength="83.511">Author Arran Cudbar</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="83.349" y="9" textLength="23.832">d-Bell</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="0" y="20" textLength="113.706">Copyright 2014-2015 The Fr</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="113.544" y="20" textLength="53.496">eeRADIUS pr</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="166.878" y="20" textLength="19.665">oject</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="0" y="31" textLength="9.495">Cr</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="9.333" y="31" textLength="126.855">eative commons license CC BY</tspan></text><path d="M 577.55905 483.37795 L 584.55905 483.37795 L 674.31496 483.37795 C 677.62867 483.37795 680.31496 480.69166 680.31496 477.37795 L 680.31496 464.8819 L 680.31496 396.70775 L 680.31496 389.70775" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 397.93045 329.81103 L 409.83045 329.81103 L 447.5433 329.81103 C 450.857 329.81103 453.5433 332.49732 453.5433 335.81103 L 453.5433 345.82677 L 453.5433 352.15749 C 453.5433 355.4712 456.2296 358.15749 459.5433 358.15749 L 469.98976 358.15749 L 471.98976 358.15749" marker-end="url(#FilledArrow_Marker_2)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 345.82677 301.46458 L 352.82677 301.46458 L 362.50393 301.46458 C 365.81764 301.46458 368.50393 304.15087 368.50393 307.46458 L 368.50393 320.31496 L 368.50393 325.063 C 368.50393 327.68526 370.6297 329.81103 373.25197 329.81103 L 474.88976 329.81103 L 481.88976 329.81103" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 737.71653 270.28345 L 730.71653 270.28345 L 672.14173 270.28345 C 668.828 270.28345 666.14173 272.96974 666.14173 276.28345 L 666.14173 328.8189 L 666.14173 371.0118 C 666.14173 373.7754 663.9014 376.01575 661.1378 376.01575 L 656.13385 376.01575 L 649.13385 376.01575" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 649.13385 318.47244 L 656.13385 318.47244 L 661.1378 318.47244 C 663.9014 318.47244 666.14173 316.2321 666.14173 313.4685 L 666.14173 303.30708 L 666.14173 276.28345 C 666.14173 272.96974 668.828 270.28345 672.14173 270.28345 L 730.71653 270.28345 L 737.71653 270.28345" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><rect x="481.88976" y="314.64568" width="90.70866" height="30.330709" fill="#dfffd1"/><rect x="481.88976" y="314.64568" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(486.88976 323.81103)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="8.9431976" y="10" textLength="30.009766">Auth-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="38.406088" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="57.307455" y="10" textLength="5">y</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="62.307455" y="10" textLength="9.458008"> {}</tspan></text><rect x="481.88976" y="286.29922" width="90.70866" height="30.330709" fill="#dfffd1"/><rect x="481.88976" y="286.29922" width="90.70866" height="30.330709" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(486.88976 295.46458)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="8.9431976" y="10" textLength="30.009766">Auth-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="38.406088" y="10" textLength="33.359375">ype x {}</tspan></text><rect x="481.88976" y="456.37795" width="95.66929" height="36" fill="#d39925"/><rect x="481.88976" y="456.37795" width="95.66929" height="36" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(486.88976 468.37795)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="13.654958" y="10" textLength="58.359375">Post-Proxy {}</tspan></text><path d="M 92.267716 252.28346 L 165.68504 252.28346 C 174.36926 252.28346 181.41732 260.34746 181.41732 270.28346 C 181.41732 280.21946 174.36926 288.28346 165.68504 288.28346 L 92.267716 288.28346 C 83.583496 288.28346 76.535433 280.21946 76.535433 270.28346 C 76.535433 260.34746 83.583496 252.28346 92.267716 252.28346" fill="white"/><path d="M 92.267716 252.28346 L 165.68504 252.28346 C 174.36926 252.28346 181.41732 260.34746 181.41732 270.28346 C 181.41732 280.21946 174.36926 288.28346 165.68504 288.28346 L 92.267716 288.28346 C 83.583496 288.28346 76.535433 280.21946 76.535433 270.28346 C 76.535433 260.34746 83.583496 252.28346 92.267716 252.28346" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(92.02362 264.28346)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="2.2091039" y="10" textLength="38.354492">Listener </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="40.563596" y="10" textLength="31.132812">proto a</tspan></text><path d="M 737.71653 270.28345 L 730.71653 270.28345 L 672.14173 270.28345 C 668.828 270.28345 666.14173 272.96974 666.14173 276.28345 L 666.14173 328.8189 L 666.14173 342.66535 C 666.14173 345.42895 663.9014 347.66929 661.1378 347.66929 L 656.13385 347.66929 L 649.13385 347.66929" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 245.21811 505.55903 L 243.21811 505.55903 L 232.77165 505.55903 C 229.45794 505.55903 226.77165 508.24532 226.77165 511.55903 L 226.77165 518.74015 L 226.77165 527.9055 C 226.77165 531.2192 224.08536 533.9055 220.77165 533.9055 L 193.4 533.9055 L 181.5 533.9055" marker-start="url(#FilledArrow_Marker_4)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 245.21811 562.25194 L 243.21811 562.25194 L 232.77165 562.25194 C 229.45794 562.25194 226.77165 559.56565 226.77165 556.25194 L 226.77165 549.92126 L 226.77165 539.9055 C 226.77165 536.59178 224.08536 533.9055 220.77165 533.9055 L 197.40001 533.9055 L 185.50001 533.9055" marker-start="url(#FilledArrow_Marker_4)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(61.692913 167.5748)" fill="black"><tspan font-family="Helvetica Neue" font-size="16" font-weight="500" x=".124" y="15" textLength="72.304">Request fl</tspan><tspan font-family="Helvetica Neue" font-size="16" font-weight="500" x="72.428" y="15" textLength="40.272">ow Fr</tspan><tspan font-family="Helvetica Neue" font-size="16" font-weight="500" x="112.412" y="15" textLength="156.464">eeRADIUS 2.2.x-3.0.x</tspan></text><path d="M 827.71653 270.28345 L 832.6008 270.28345 C 836.47547 270.28345 839.61653 273.42451 839.61653 277.2992 L 839.61653 277.2992 C 839.61653 281.1739 836.47547 284.31496 832.6008 284.31496 L 731.40945 284.31496 C 726.6737 284.31496 722.83464 288.15403 722.83464 292.88977 L 722.83464 292.88977 C 722.83464 297.6255 726.6737 301.46458 731.40945 301.46458 L 753.45433 301.46458 L 755.45433 301.46458" marker-end="url(#FilledArrow_Marker_3)" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1" stroke-dasharray="2,2"/><rect x="765.35433" y="286.29922" width="127.559054" height="30.33071" fill="#b70000"/><rect x="765.35433" y="286.29922" width="127.559054" height="30.33071" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(770.35433 295.46458)" fill="white"><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="4.0261092" y="10" textLength="53.34961">Post-Auth-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="56.828844" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" fill="white" x="75.73021" y="10" textLength="28.344727">Reject</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" fill="white" x="104.07494" y="10" textLength="9.458008"> {}</tspan></text><rect x="737.71653" y="252.28345" width="90" height="36" fill="#d39925"/><rect x="737.71653" y="252.28345" width="90" height="36" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(742.71653 264.28345)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="13.31543" y="10" textLength="53.36914">Post-Auth {}</tspan></text><path d="M 354.3307 569.83462 L 361.3307 569.83462 L 385.1811 569.83462 C 388.4948 569.83462 391.1811 567.14833 391.1811 563.83462 L 391.1811 425.19685 L 391.1811 416.02756 C 391.1811 413.26396 393.42144 411.02362 396.18504 411.02362 L 401.18897 411.02362 L 408.18897 411.02362" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 354.3307 541.48817 L 361.3307 541.48817 L 385.1811 541.48817 C 388.4948 541.48817 391.1811 538.80187 391.1811 535.48817 L 391.1811 521.5748 L 391.1811 432.19685 L 391.1811 425.19685" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 354.3307 513.1417 L 361.3307 513.1417 L 385.1811 513.1417 C 388.4948 513.1417 391.1811 510.45542 391.1811 507.1417 L 391.1811 496.063 L 391.1811 432.19685 L 391.1811 425.19685" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 316.77165 480.37795 L 323.77165 480.37795 L 385.1811 480.37795 C 388.4948 480.37795 391.1811 477.69166 391.1811 474.37795 L 391.1811 466.3937 L 391.1811 432.19685 L 391.1811 425.19685" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 345.82677 363.2126 L 352.82677 363.2126 L 385.1811 363.2126 C 388.4948 363.2126 391.1811 365.8989 391.1811 369.2126 L 391.1811 382.67716 L 391.1811 389.8504 L 391.1811 396.8504" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 345.82677 334.86615 L 352.82677 334.86615 L 385.1811 334.86615 C 388.4948 334.86615 391.1811 337.55244 391.1811 340.86615 L 391.1811 371.33858 L 391.1811 389.8504 L 391.1811 396.8504" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 391.1811 396.8504 L 391.1811 389.8504 L 391.1811 342.99212 L 391.1811 312.5197 C 391.1811 309.20599 388.4948 306.5197 385.1811 306.5197 L 352.82677 306.5197 L 345.82677 306.5197" stroke="#b70000" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 354.3307 533.9055 L 366.2307 533.9055 L 370.20197 533.9055 C 372.39523 533.9055 374.17323 532.1275 374.17323 529.93423 L 374.17323 498.89763 L 374.17323 480.37795 C 374.17323 477.06424 376.85952 474.37795 380.17323 474.37795 L 469.98976 474.37795 L 471.98976 474.37795" marker-end="url(#FilledArrow_Marker_5)" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 481.88976 474.37795 L 474.88976 474.37795 L 380.17323 474.37795 C 376.85952 474.37795 374.17323 477.06424 374.17323 480.37795 L 374.17323 498.89763 L 374.17323 556.25194 C 374.17323 559.56565 371.48693 562.25194 368.17323 562.25194 L 361.3307 562.25194 L 354.3307 562.25194" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 481.88976 474.37795 L 474.88976 474.37795 L 380.17323 474.37795 C 376.85952 474.37795 374.17323 477.06424 374.17323 480.37795 L 374.17323 493.22834 L 374.17323 499.55903 C 374.17323 502.87274 371.48693 505.55903 368.17323 505.55903 L 361.3307 505.55903 L 354.3307 505.55903" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 345.82677 329.81103 L 352.82677 329.81103 L 405.02362 329.81103 C 408.33733 329.81103 411.02362 332.49732 411.02362 335.81103 L 411.02362 418.19685 L 411.02362 425.19685" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 345.82677 358.1575 L 352.82677 358.1575 L 362.50393 358.1575 C 365.81764 358.1575 368.50393 355.4712 368.50393 352.1575 L 368.50393 345.82677 L 368.50393 335.81103 C 368.50393 332.49732 371.19023 329.81103 374.50393 329.81103 L 474.88976 329.81103 L 481.88976 329.81103" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 316.77165 270.28345 L 326.27165 270.28345 L 405.02362 270.28345 C 408.33733 270.28345 411.02362 272.96974 411.02362 276.28345 L 411.02362 303.30708 L 411.02362 323.81103 C 411.02362 327.12474 413.7099 329.81103 417.02362 329.81103 L 472.38976 329.81103 L 474.38976 329.81103" marker-end="url(#FilledArrow_Marker_6)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(61.692913 638.80315)" fill="black"><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="0" y="9" textLength="119.331">Reject path is followed if the r</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="119.169" y="9" textLength="132.012">code set for a section when the r</tspan><tspan font-family="Helvetica Neue" font-size="9" font-weight="500" x="251.019" y="9" textLength="141.372">equest leaves, is not ok or updated</tspan></text><rect x="255.11811" y="490.39368" width="99.2126" height="30.33071" fill="#dfffd1"/><rect x="255.11811" y="490.39368" width="99.2126" height="30.33071" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 499.55903)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="1.25424814" y="10" textLength="53.8916">Pre-Proxy-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="54.598975" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="73.50034" y="10" textLength="5">x</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="78.50034" y="10" textLength="9.458008"> {}</tspan></text><rect x="255.11811" y="547.0866" width="99.2126" height="30.33071" fill="#dfffd1"/><rect x="255.11811" y="547.0866" width="99.2126" height="30.33071" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 556.25194)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="1.25424814" y="10" textLength="53.8916">Pre-Proxy-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="54.598975" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="73.50034" y="10" textLength="5">z</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="78.50034" y="10" textLength="9.458008"> {}</tspan></text><rect x="255.11811" y="518.74013" width="99.2126" height="30.33071" fill="#dfffd1"/><rect x="255.11811" y="518.74013" width="99.2126" height="30.33071" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 527.9055)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="1.25424814" y="10" textLength="53.8916">Pre-Proxy-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="54.598975" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="73.50034" y="10" textLength="5">y</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="78.50034" y="10" textLength="9.458008"> {}</tspan></text><path d="M 577.55905 474.37795 L 589.45905 474.37795 L 660.14173 474.37795 C 663.45544 474.37795 666.14173 471.69166 666.14173 468.37795 L 666.14173 371.33858 L 666.14173 276.28345 C 666.14173 272.96974 668.828 270.28345 672.14173 270.28345 L 725.81653 270.28345 L 727.81653 270.28345" marker-end="url(#FilledArrow_Marker_5)" stroke="#d39925" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><path d="M 411.02362 319.46458 L 411.02362 425.19685 L 411.02362 436.20472 C 411.02362 439.51843 408.33733 442.20472 405.02362 442.20472 L 201.25984 442.20472 L 170.40945 442.20472 C 167.09574 442.20472 164.40945 444.89101 164.40945 448.20472 L 164.40945 520.7244 L 164.40945 527.9055 C 164.40945 531.2192 167.09574 533.9055 170.40945 533.9055 L 243.21811 533.9055 L 245.21811 533.9055" marker-end="url(#FilledArrow_Marker_2)" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><rect x="255.11811" y="286.29922" width="90.70866" height="30.33071" fill="#d0e6da"/><rect x="255.11811" y="286.29922" width="90.70866" height="30.33071" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 295.46458)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="8.9431976" y="10" textLength="29.448242">Autz-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="37.844565" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="56.745932" y="10" textLength="5.5615234">a</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="62.307455" y="10" textLength="9.458008"> {}</tspan></text><rect x="255.11811" y="314.64568" width="90.70866" height="30.33071" fill="#d0e6da"/><rect x="255.11811" y="314.64568" width="90.70866" height="30.33071" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 323.81103)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="8.9431976" y="10" textLength="29.448242">Autz-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="37.844565" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="56.745932" y="10" textLength="5.5615234">b</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="62.307455" y="10" textLength="9.458008"> {}</tspan></text><rect x="255.11811" y="342.99213" width="90.70866" height="30.33071" fill="#d0e6da"/><rect x="255.11811" y="342.99213" width="90.70866" height="30.33071" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(260.11811 352.1575)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="9.2239594" y="10" textLength="29.448242">Autz-T</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="38.125327" y="10" textLength="18.901367">ype </tspan><tspan font-family="Helvetica" font-size="10" font-style="italic" font-weight="500" x="57.026694" y="10" textLength="5">c</tspan><tspan font-family="Helvetica" font-size="10" font-weight="500" x="62.026694" y="10" textLength="9.458008"> {}</tspan></text><rect x="226.77165" y="456.37795" width="90" height="36" fill="#6c0"/><rect x="226.77165" y="456.37795" width="90" height="36" stroke="#6c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(231.77165 468.37795)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="13.0444336" y="10" textLength="53.911133">Pre-Proxy {}</tspan></text><rect x="226.77165" y="252.28345" width="90" height="36" fill="#00c0c0"/><rect x="226.77165" y="252.28345" width="90" height="36" stroke="#00c0c0" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(231.77165 264.28345)" fill="black"><tspan font-family="Helvetica" font-size="10" font-weight="500" x="14.147949" y="10" textLength="51.704102">Authorize {}</tspan></text></g></g></svg>
* xref:index.adoc[Concepts]
-** General
-*** xref:aaa.adoc[AAA]
-** Modules
-*** LDAP
-**** xref:modules/ldap/authentication.adoc[Authentication]
+** xref:overview.adoc[Overview]
+*** xref:freeradius.adoc[What is FreeRADIUS?]
+*** xref:aaa/aaa.adoc[Authentication Authorization Accounting (AAA)]
+**** xref:aaa/authz.adoc[Authorization]
+**** xref:aaa/authn.adoc[Authentication]
+**** xref:aaa/acct.adoc[Accounting]
+*** xref:components/architecture.adoc[RADIUS System Components]
+**** xref:components/nas.adoc[Network Access Server (NAS)]
+**** xref:components/radius_servers.adoc[RADIUS Server]
+***** xref:components/radius_servers.adoc#policy[Server Policies]
+**** xref:components/datastore.adoc[Datastores]
+*** xref:session/radius_session.adoc[RADIUS Sessions]
+**** xref:session/radius_session_msg.adoc[Messages]
+**** xref:session/processing.adoc[Processing]
+** xref:protocol/authproto.adoc[Protocols]
+** xref:modules/ldap/authentication.adoc[Authentication with LDAP]
+*** xref:modules/ldap/password_storage.adoc[Password Storage]
+*** xref:modules/ldap/novell.adoc[Integrate Novell]
+** xref:resources.adoc[Resources]
--- /dev/null
+= Authorization, Authentication, and Accounting (AAA)
+
+RADIUS is one of a number of Authentication, Authorization, and Accounting (AAA) protocols. Other examples of AAA protocols include TACACS+ and Diameter. AAA defines an architecture that authenticates and grants Authorization to users and accounts for their activity. When AAA is not used, the network architecture is "open", where anyone can gain access and do anything, without any tracking. The open network architecture is commonly used in small businesses, where access to an office can be physically controlled. The open network architecture is poorly suited to ISPs, where access needs to be strictly controlled and accounted for.
+
+It is possible to incorporate only a portion of AAA in a system. For example, if a company is not concerned about billing users for their network usage, they may decide to both authenticate and authorise users, but ignore user activity and not deal with accounting. Similarly, a monitoring system will look for unusual user activity (accounting), but may delegate the authentication and Authorization decisions to another part of the network.
+
+Without AAA, a network administrator would have to statically configure a network. Even in the earliest days of dialup access, network administrators found a static model inadequate. AAA ensures the flexibility of network policies. AAA also gives network administrators the ability to move systems; without AAA, they would have to clearly define connectivity options.
+
+Today, the proliferation of mobile devices, diverse network consumers, and varied network access methods combine to create an environment that places greater demands on AAA. AAA has a part to play in almost all the ways we access a network: wireless hotspots use AAA for security; partitioned networks require AAA to enforce access; all forms of remote access use AAA to authorise remote users.
+
+The following sections describe each part of the AAA solution, and how each one works.
+
+== AAA request handling
+
+AAA request handling refers to the process by which a system manages xref:aaa/authn.adoc[authentication], xref:aaa/authz.adoc[Authorization], and xref:aaa/acct.adoc[accounting] (AAA) services for users accessing computer resources or network services. This process involves verifying user identities, granting access based on permissions, and tracking their activities for auditing or billing purposes.
+
+Normally there are two steps in processing an authentication request
+coming from a NAS in FreeRADIUS: Authorization and authentication.
+If we use FreeRADIUS as a proxy to re-send the request to another
+RADIUS server there will be additional steps.
+
+=== Authentication vs. Authorization
+
+The following analogy illustrates the difference between Authentication and Authorization:
+
+Imagine you are driving a car and you are stopped by a police officer. The officer asks you to provide a piece of identification to identify yourself. You could, for example, use your passport, driver’s license, or ID card to prove or *authenticate* who you are. In terms of the RADIUS protocol, the authentication process identifies the user as someone who is allowed to access the network.
+
+The police officer may also ask you to prove that you are authorized to drive. In this case, there is only one document - a driver’s license - that proves that you are permitted or *authorized* to drive a car.
+
+The Authorization process combines the policy on the RADIUS server and the information in the request from the NAS. The NAS may add additional information to the request, such as the user’s Media Access Control (MAC) address. The NAS sends the information to the server, where an Authorization decision is made.
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Accounting
+
+Accounting refers to the recording of resources a user consumes during the time they are on the network. The information gathered can include the amount of system time used, the amount of data sent, or the quantity of data received by the user during a session.
+
+During a network session, the NAS periodically sends an accounting of user activity to the server. This accounting is a summary, and the collected data is used for billing purposes.
+
+ISPs are a large consumer of accounting data, because each user is billed for every minute of network access. However, corporations have not, historically, relied on network accounting information gathered by RADIUS because employees were not traditionally billed for network access. As their need for ongoing
+network monitoring increases, though, so does the need to store and process accounting information.
+
+The accounting summary sent by the NAS to the server does not include detailed information such as web sites visited or even how many bytes were transferred using a particular protocol (SMTP, HTTP, and so forth). That type of detailed information is only available to the NAS, and it does not send that data to the
+server.
+
+If detailed information about user activity is required, network administrators can obtain it through other protocols such as sFlow or NetFlow. Network administrators may find it difficult to tie the pieces together to get a more comprehensive understanding of user activity.
--- /dev/null
+= Authentication
+
+Authentication refers to the process of validating the identity of the user by matching the credentials supplied by the user (for example, name, password) to those configured on the AAA server (for example, name, password). If the credentials match, the user is authenticated and gains access to the network. If
+the credentials do not match, authentication fails, and network access is denied.
+
+Authentication can also fail if user credentials are entered incorrectly. For example, site policy may allow a user network access from an on-site location using a cleartext password. However, if the same password is entered by the user from a remote location, access may be denied.
+
+An ISP can also choose to deny network access to authenticated users if the users’ account has been suspended. An administrator can choose to permit limited network access to unknown users, as well. For example, an administrator can provide access to an area where the user can purchase additional network
+connectivity. This last example is most often seen in for-pay WiFi hotspots.
+
+Authentication is simply a process of comparing user’s credentials in request with the "known good" credentials retrieved from a database. Authentication usually deals with password encryption. The modules `pap`, `chap`, `mschap`, etc. do authentication.
+
+Some modules do both authentication and limited authorisation. For
+example, the `mschap` module authenticates MS-CHAP credentials, but it
+may also be used as an authorisation module, which verifies that
+request contains `MS-CHAP` related attribute. If so, the module
+instructs the server to use `mschap` for authentication, too
+
+These dual modules are usually related to protocol-specific
+attributes, such as the `pap` module for the `User-Password`
+attribute, `chap` for `CHAP-Password`, `mschap` for `MS-CHAP-*`, etc.
+
--- /dev/null
+= Authorisation
+
+Authorisation is the process of finding and returning information
+about what the user is allowed to do. For example, finding out what
+kind of authentication methods they are allowed to run, and what VLAN
+the user should be placed into.
+
+Authorisation modules generally "get data" from somewhere,
+e.g. `ldap`, `sql`, `files`, etc.
+
+The authentication method is usually determined when the server gets
+the users credentials from a database. Once the credentials are
+available, the server can authenticate the user.
+
+Authorisation refers to the process of determining what permissions are granted to the user. For example, the user may or may not be permitted certain kinds of network access or allowed to issue certain commands.
+
+The NAS sends a “request” - a packet of information about the user - and the RADIUS server either grants or denies authorisation based solely on information in the “request” sent by the NAS.In each case, the RADIUS server manages the authorisation policy and the NAS enforces the policy.
+
+The NAS “request” is really a set of statements. For example, the NAS may send the RADIUS server a “request” containing the following user information:
+
+```
+“user name is Bob”
+“password is Hello”
+“ip address is 192.02.34”
+```
+
+Once the server receives the request, it uses that information to figure out what properties the user should have (i.e. “Bob” is saying he/she has IP address 192.0.2.34, do the server records contradict this statement?).
+The server then sends a reply to the NAS. The reply contains a series of statements about what properties the user should have:
+
+```
+"user name is Bob"
+"ip address is 192.0.2.78"
+```
+
+[NOTE]
+====
+The RADIUS server can’t request further information from the NAS. In contrast with SQL systems, RADIUS is limited in that it cannot make complicated queries. In SQL, queries such as "SELECT name from table where ipaddress = 192.02.34" are common. RADIUS does not have that capability. Instead, RADIUS
+only makes statements about what is, and what should be.
+====
+
+Upon receipt of a reply from the server, the NAS tries to enforce those properties on the user. properties cannot be enforced, the NAS closes the connection.
--- /dev/null
+= RADIUS System Components
+
+RADIUS is a network protocol, a system that defines rules and conventions for communication between network devices. Like many protocols, RADIUS uses a client-server model. A RADIUS client (also called a Network Access Server (NAS) ) sends requests to a RADIUS server. The RADIUS server then processes the
+request and sends back a response.
+
+Common NAS products include wireless access points such as the Linksys WRT54G and dial-up equipment commonly available from large network manufacturers. Common RADIUS server products include Cisco ACS, Microsoft IAS, Juniper, Open Systems Radiator, and FreeRADIUS.
+
+The RADIUS protocol shares the general concept of client-server communication with many other protocols such as HTTP and SMTP, the specifics of RADIUS communications differ. This section describes the RADIUS system in more detail, including the specific roles of the NAS, the server, and datastores such as MySQL and Lightweight Directory Access Protocol (LDAP).
+
+This section describes the RADIUS system in more detail, including the specific roles of the NAS, the server, and datastores such as MySQL and Lightweight Directory Access Protocol (LDAP).
+
+.Examples of System Components
+[opts="headers, autowidth"]
+|===
+| *Component* | *Description* | *Examples*
+| User or a device | Requests access to the network.| Laptop, tablet, modem, mobile, or VOIP phone.
+| Network Access Server (NAS)| Provides access to the network for the user or device. | Switch, wireless access point (WAP), or VPN terminator.
+| Authentication Server | Receives authentication requests from the NAS and returns authentication results to the NAS. Optionally requests user and configuration information from the datastore. The server may also
+return configuration parameters to the NAS. Receives accounting information from the NAS. | FreeRADIUS, Radiator, Network Policy Server (NPS), or an Internet Authentication Service (IAS).
+| Optional datastore such as a database or directory containing user authentication and authorisation information.| RADIUS server communicates with the datastore using a database API or LDAP. | SQL Database, Kerberos Service Server, or an LDAP Directory.
+|===
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Datastore
+
+Datastores (i.e., databases or directories) permit the storage and retrieval of data. They have limited decision-making capabilities. While stored procedures are possible in most databases, they are rarely
+used when simple data storage is required.
+
+The key differences between RADIUS servers and datastores are the way they support policies and authentication. The role of a data store in the authentication process is to provide data to a RADIUS server. The server then uses an authentication method to authenticate the user.
+
+When a RADIUS server authenticates a user or stores accounting data for that user, it reads from or writes to a database or directory.User information (i.e., user name, password, credit amount) and session data (i.e., total session time and statistics for total traffic to and from the user) are stored on this database or directory.
+
+In many respects, the RADIUS protocol is similar to a remote database query language. Specifically, while an SQL or LDAP database stores user data, that database cannot be queried directly by the NAS. Instead, the NAS sends a request to the server, which in turn queries the database. This simplification of the normal database query language means that it is easy to add authentication and accounting to an NAS instead of implementing a full-featured SQL client, which would be very resource intensive and costly.
+
+.Comparison of Datastores and RADIUS Servers
+[opts="headers, autowidth"]
+|===
+| *Datastore* | *RADIUS Server*
+| Stores authentication and authorisation data | Processes data retrieved from the datastore.
+| Rarely implements policies. | Implements policies.
+| Supports basic authentication queries,
+such as LDAP “bind as user” | Support authentication protocols that include CHAP, MS-CHAP, MS-CHAPv2, and 802.1X (EAP, EAP-TLS, PEAP, EAP-TTLS, EAP-MD5).
+|===
+
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Network Access Server
+
+A Network Access Server (NAS) is a system that provides access to
+a network. In some cases, it's also known as a Terminal Server or Remote
+Access Server (RAS).
+
+The NAS is meant to act as a gateway to guard access to a
+protected resource. This can be anything from a telephone network,
+to printers, to the Internet.
+
+The client connects to the NAS. The NAS then connects to another
+resource asking whether the client's supplied credentials are
+valid. Based on that answer the NAS then allows or disallows
+access to the protected resource.
+
+The NAS contains no information about what clients can connect or
+what credentials are valid. All the NAS does is send the
+credentials the client supplied to a resource which does know how
+to process the credentials.
+
+== Examples
+
+The above translates into different implementations for different uses.
+Here are some examples.
+
+- The most common use would be for access to the Internet. A
+ user opens their browser. The NAS detects that the user is not
+ currently authorized to have access to the Internet, so the NAS
+ prompts the user for their username and password. The user
+ supplies them and sends them back to the NAS. The NAS then uses
+ RADIUS to connect to an AAA server (in this case,
+ it is running FreeRADIUS) and passes off the
+ username and password to the FreeRADIUS server. The FreeRADIUS
+ server searches through its resources and finds that the
+ credentials are valid and notifies the NAS they are valid. The NAS
+ then grants the user access to the internet.
+
+- Another use of a NAS would be in VoIP. However,
+ instead of using a username and password, many times a phone
+ number or IP Address are used. If the phone number is a valid
+ customer then the call can be completed. Other uses might be if
+ the phone number has long distance access or is a telephone card
+ and has minutes left.
+
+== Associated Protocols
+
+Although not required, NAS are almost exclusively used with
+AAA servers. Of the AAA protocols available,
+RADIUS tends to be the most widely used.
+DIAMETER is a new protocol which extends on
+RADIUS by providing error handling and inter-domain
+communications which is starting to be implimented in some high
+end NAS.
+
+== More Information
+
+- https://datatracker.ietf.org/doc/html/rfc2881[RFC 2881] Network Access Server Requirements Next Generation NAS Model
+- https://datatracker.ietf.org/doc/html/rfc2881[RFC 2882] Network Access Servers Requirements: Extended RADIUS Practices
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Server Policies
+The RADIUS server processes an NAS request based on the following criteria:
+
+* Contents of the NAS request.
+* Information available locally to the RADUS server (flat files, SQL, LDAP).
+
+The limitations inherent in the above processing criteria mean that the server can't negotiate with a NAS to request more information. The server takes what the NAS sends and returns either an acknowledgment or a non-acknowledgment.
+
+The RADIUS server has no control over the content of the request that the NAS sends. When the RADIUS server receives the request from the NAS, it uses local policies to decide how best to respond to the NAS request. The policies may be simple, such as “accept anyone with a correct user name and password”. More complex policies may be “allow basic users to request premium services in
+non-premium hours, except for Sundays and holidays, if their payment status is current”.
+
+In all cases, the policies must be designed, implemented, and deployed by the network administrator. because policies are based on the contents of the NAS requests. Note that the NAS documentation does not always describe the content of the NAS requests. The only way for a network administrator to determine the NAS request content is to set up a test network.
+
+Test logins will result in the receipt of requests by the server. The administrator can then examine these requests to determine their content and create policies that look for those specific sets of attributes. Once
+the policy is created, the server then uses that information to make decisions.
+This process becomes more complicated when different NAS elements send the same information in different formats.
+
+For example, RADIUS has no MAC address data type, which means that the MAC address is sent as ASCII strings. Some NAS elements send a MAC address in the format of “00:01:02:03:04:05”, while others use the format “00-01-02-03-04-05”. The fact that these differences are not documented makes policy creation very difficult.In most cases, the administrator has to resort to trial and error methods to determine how to implement policies.
--- /dev/null
+= RADIUS
+
+RADIUS is a protocol for remote user Authorisation, Authentication and Accounting. Its primary use is for Internet Service Providers, though it may as well be used on any network that needs a centralized authentication and/or accounting service for its workstations.
+
+RADIUS is often used in larger Wi-Fi (wireless) networks for authentication purposes, replacing the simple shared key methods which are uncomfortable if a Wi-Fi network reaches a specific size.
+
+The protocol originally was designed by the well known terminal server manufacturer Livingston for use with their Portmaster series of terminal servers. Since then it has been implemented by hundreds other vendors and has a become an Internet Standard RFC.
+
+The DIAMETER protocol is the designated successor, but RADIUS is still commonly used today.
+
+== Protocol dependencies
+
+UDP: RADIUS uses UDP as its underlying protocol. The registered UDP port for RADIUS traffic is 1812; the early deployment of RADIUS used UDP port 1645, which conflicted with the "datametrics" service. When RADIUS is used for accounting rather than authentication and configuration, the registered UDP port is 1813; the early deployment used port 1646, which conflicted with the "sa-msg-port" service.
+
+== External links
+
+* RFC 2865 Remote Authentication Dial In User Service (RADIUS)
+* RFC 2866 RADIUS Accounting
+* RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support
+* RFC 2868 RADIUS Attributes for Tunnel Protocol Support
+* RFC 2869 RADIUS Extensions
+* RADIUS attributes and packet type codes
+
+== See Also
+
+* FreeRADIUS
+* RADIUS-Clients
+* Other RADIUS Servers
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= RADIUS Server
+
+A RADIUS server is a central authority that handles authentication, authorisation, and accounting (AAA) for network access. The server receives requests from network access servers (NASs) like wireless access points or VPN concentrators and determines whether a user should be granted access based on predefined policies and data stored in a datastore.
+
+The RADIUS server is usually a software application running on a self-contained server. A physical device such as RADIUS appliances, with simplified maintenance and management interfaces, are also used. In either scenario, the server waits for a request from an NAS, processes or forwards the request, and then returns a response to the NAS. The response can contain authorisation policies or an acknowledgment of accounting data received.
+
+A single RADIUS server can receive and process many simultaneous access requests from numerous types of NASs (such as ADSL, dial-up, or VPN concentrators) in many different locations. A single server may also
+access flat files, SQL databases, LDAP directories, or other RADIUS servers. In order to make a decision regarding an access request, the RADIUS server must first use information from many sources.
+
+Once the server makes a decision, it returns a response to the NAS. The NAS may enforce the policy in that response, or it may ignore it altogether. The server is not aware if the NAS has received its response, or if the NAS is obeying the instructions in that response. Since it is customary for the NAS to log very little information about what has been received or how server responses are processed, it is very difficult to create and debug local site policies.
+
+The RADIUS server has no control over what the NAS does with a response.
+Consider the following analogy to help illustrate the point: a Human Resources (HR) department acts like a RADIUS server, by setting policies, and a security guard acts like the NAS in a network, by carrying out those HR department policies.
+
+In this example, the company policy is that when an employee is fired, HR notifies security and removes building access from that employee. The security guard is then responsible for ensuring the fired employee no longer accesses the company building. If one day an employee gets fired (similar to a user
+being denied access) and the HR department informs the security guard that the employee is no longer free to come and go (similar to the RADIUS server decision sent to the NAS), it is then up to the security guard at the company front desk to perform the task of refusing entry to the fired employee (similar to the NAS enforcing system access in a network). In the network, the NAS enforces system access. The RADIUS server does little more than offer advice to the NAS.
+
+[#policy]
+== RADIUS Server Policies
+
+The RADIUS server processes an NAS request based on the following criteria:
+
+* Contents of the NAS request.
+* Information available locally to the RADUS server (flat files, SQL, LDAP).
+
+This processing criteria limits the server ability to perform more complex authentication scenarios. The server can't negotiate with a NAS to request more information. The server uses the initial information that the NAS sends and returns either an acknowledgment or a non-acknowledgment.
+
+The RADIUS server has no control over the content of the request that the NAS sends. When the RADIUS server receives the request from the NAS, it uses local policies to decide how best to respond to the NAS request. The policies may be simple, such as “accept anyone with a correct user name and password”. More complex policies may be “allow basic users to request premium services in
+non-premium hours, except for Sundays and holidays, if their payment status is current”.
+
+In all cases, the policies must be designed, implemented, and deployed by the network administrator because policies are based on the contents of the NAS requests. Often, the NAS documentation doesn't describe the content of the NAS requests. The only way for a network administrator to determine the NAS request content is to set up a test network.
+
+Test logins will result in the receipt of requests by the server. The administrator can examine these requests to determine their content and create policies that look for those specific sets of attributes. Once
+the policy is created, the server then uses that information to make decisions.
+This process becomes more complex when different NAS elements send the same information in different formats.
+
+For example, RADIUS has no MAC address data type, which means that the MAC address is sent as ASCII strings. Some NAS elements send a MAC address in the format of “00:01:02:03:04:05”, while others use the format “00-01-02-03-04-05”. The fact that these differences are not documented makes policy creation very difficult.In most cases, the administrator has to resort to trial and error methods to determine how to implement policies.
--- /dev/null
+= What is FreeRADIUS?
+
+FreeRADIUS is the most popular and the most widely deployed open source RADIUS server in the world.
+It serves as the basis for multiple commercial offerings, and it supplies the authentication, authorisation, and accounting (AAA) needs of many Fortune 500 companies and Tier 1 ISPs. It is also widely used by the academic community (i.e., eduroam, the world-wide roaming access service developed for the international research and education community, utilises FreeRADIUS software).
+
+FreeRADIUS was started in August 1999 by Alan DeKok and Miquel van Smoorenburg. Miquel had previously written the Cistron RADIUS server software, which had been widely adopted when the Livingston server was no longer in service. FreeRADIUS was developed using a modular design, to encourage more active community involvement.
+
+== Features
+
+More authentication types are supported by FreeRADIUS than by any other open source server. For example, FreeRADIUS is the only open source RADIUS server to support Extensible Authentication Protocol (EAP).
+
+FreeRADIUS is also the only open source RADIUS server to support virtual servers. The use of virtual servers means that complex implementations are simplified. Ongoing support and maintenance costs for network administrators are greatly reduced. FreeRADIUS's ability to support virtual servers
+gives it a huge advantage over the competition.
+
+== Modularity
+
+The modular design protocol makes FreeRADIUS easy to understand. The modular interface also simplifies adding or removing modules. If a feature is not needed for a configuration, the module is removed with a simple edit of the configuration file. Once the module is removed, it does not affect server performance, memory use, or security. This flexibility enables the server to run on platforms ranging from embedded systems to multi-core machines with gigabytes of RAM.
+
+The server core does the basic RADIUS and network handling. Almost everyother feature is managed with a module. This modular design increases the flexibility of the policy language. The policy language can execute multiple modules in any order, allowing for highly customizable workflows. Each module handles a specific, isolated task such as authentication, logging, or database access.
+
+For example, each of the authentication methods (PAP,CHAP, MS-CHAP, TOTP, and EAP) are individual modules. Similarly, each database connector (SQL,Redis, LDAP, etc.) are individual modules. In many cases, no code changes to the server core have to be made in order to support complex new functionality.
+
+This modular design streamlines development, testing, and enhances the system’s adaptability to new requirements or technologies.
+
+== Scalability
+
+A single FreeRADIUS server is easily reconfigured to handle a wide range of workloads, from just a few requests per second to thousands—by adjusting a few default settings. This adaptability makes FreeRADIUS suitable for both small deployments and very large organisations, including those with over 10 million customers who rely on it for authentication, authorization, and accounting (AAA) services.
+
+A single FreeRADIUS server can transition from handling one request every few seconds to processing thousands of requests per second. These varied workloads are handled by changing a few default settings. FreeRADIUS is suitable for both small deployments and very large organisations, including those with over 10 million customers. Often, only a single FreeRADIUS server is required to fulfill an organisation's requirements for their AAA services.
+
+While many commercial severs offer different versions of their software to handle different needs, only the latest version of FreeRADIUS provides better performance, more realms, more RADIUS clients, and more features, with no need to purchase additional product licenses.
+
+== Features
+
+* Complete support for https://datatracker.ietf.org/doc/html/rfc2865[RFC 2865] and https://datatracker.ietf.org/doc/html/rfc2866[RFC 2866] attributes.
+* Authentication Protocol supports for:
+** EAP or protocol/EAP with EAP-MD5, EAP-SIM, EAP-TLS, EAP-TTLS.
+** EAP-PEAP or protocol/EAP-PEAP.
+** Cisco LEAP or protocol/LEAP and EAP sub-types.
+* Vendor Specific Attributes for over a hundred vendors including BinTec, Foundry, Cisco, Juniper, Lucent/Ascend, HP ProCurve, Microsoft, USR/3Com.
+* All known RADIUS clients.
+* Flexible configurations using attribute pairs.
+* Supports virtual servers.
= Concepts
-This section documents concerning the protocols and modules used by the
-FreeRADIUS server.
+The Concepts guide introduces the main concepts for readers who are new to RADIUS (Remote Authentication Dial-In User Service) and its associated components. This information explains the foundational ideas and principles behind RADIUS to help you understand what RADIUS is, what it does, and how it operates within a network environment. By covering these basics, the section aims to provide a solid starting point for further exploration or practical use of RADIUS in network authentication, authorization, and accounting.
-It intended to provide more theoretical information about particular subjects
-than would be appropriate to include inline in module configurations or as
-sidebars in howto guides.
+== Sections in this Guide
+
+* xref:concepts:overview.adoc[Overview] explains the RADIUS server, FreeRADIUS, and the core services provided.
+ ** xref:freeradius.adoc[What is FreeRADIUS] explains the benefits of the open-source software version.
+ ** xref:aaa/aaa.adoc[Authentication Authorisation Accounting (AAA)] explains the core services provided by FreeRADIUS.
+ *** xref:aaa/authz.adoc[Authorisation] is the process of allowing an authenticated user to access services on the network.
+ *** xref:aaa/authn.adoc[Authentication] if the process of verifying an end-user's credentials.
+ *** xref:aaa/acct.adoc[Accounting] operations record the time spent on the network and services accessed for auditing or billing purposes.
+ ** xref:components/architecture.adoc[RADIUS System Components] explains the RADIUS design and components.
+ *** xref:components/nas.adoc[Network Access Server (NAS)] outlines the NAS operations and access management.
+ *** xref:components/radius_servers.adoc[RADIUS Server] describes the role of the server and how server policies work.
+ *** xref:components/datastore.adoc[Datastores] details how datastores work and what's supported.
+ ** xref:session/radius_session.adoc[RADIUS Sessions] explains session transmission and management or these session on the network.
+ *** xref:session/radius_session_msg.adoc[Session Messages] details the format and content of session messages.
+ *** xref:session/processing.adoc[Processing] outlines the flow of messages and how aaa services are implemented.
+* xref:protocol/authproto.adoc[Protocols] defines the protocols used in the RADIUS environment.
+* xref:modules/ldap/authentication.adoc[Authentication with LDAP] can be used by RADIUS servers to authenticate the network users.
+ ** xref:modules/ldap/password_storage.adoc[Password Storage] explains the methods of how the user's information can be stored.
+ ** xref:modules/ldap/novell.adoc[Integrate Novell] with RADIUS networks using LDAP.
+* xref:resources.adoc[Resources] find more help, mailing lists, and related documentation to help learn about deploying FreeRADIUS.
--- /dev/null
+= Authentication with LDAP
+
+LDAP servers function primarily as databases that store user credentials and related information. They do not implement or handle authentication protocols themselves.
+
+The RADIUS server handles the authentication protocols such as `PAP`, `CHAP`, or `MS-CHAP`. The LDAP server is a backend accessed by the RADIUS server to verify user credentials. The LDAP module interacts with these protocols by retrieving and comparing data. The RADIUS server performs the authentication logic, not the LDAP server.
+
+The LDAP module is compatible a few different kinds of authentication
+methods. Note that we say _compatible_, and not _supports_. LDAP
+servers are databases, and do not support authentication protocols.
+
+PAP::
+The user supplies a `User-Password` (plaintext or EAP-TTLS/PAP)
++
+FreeRADIUS reads the "known good" password from LDAP, and compares
+that to what the user entered.
+
+Bind as user::
+The user supplies a `User-Password` (plaintext or EAP-TTLS/PAP)
++
+FreeRADIUS uses that password to "bind as the user" to LDAP, using the
+supplied `User-Name` and `User-Password. If the bind is successfull,
+the user is authenticated. Otherwise, authentication fails.
+
+CHAP::
+The user supplies a `CHAP` password attribute.
++
+FreeRADIUS reads the "known good" password from LDAP in cleartext, and
+compares that to what the user entered.
+
+MS-CHAP::
+The user supplies a `MS-CHAP` password attribute. Either as
+MS-CHAPv2, or as PEAP/MSCHAPv2, or as EAP-TTLS/MS-CHAPv2.
++
+FreeRADIUS reads the "known good" password from LDAP in cleartext, or
+as an NT hash, and compares that to what the user entered.
+
+All of above authentication methods other than "bind as user" require
+that FreeRADIUS obtain the `userPassword` field from LDAP. If that
+field is not returned to FreeRADIUS, then normal authentication is
+impossible. Either FreeRADIUS has to be configured to use "bind as
+user" for authentication, or the LDAP database has to be updated to
+return the `userPassword` field to FreeRADIUS. This change usually
+involves giving the FreeRADIUS "read-only" user permission to read the
+`userPassword` field.
+
+Again, the best method is to test authentication is with the
+ldap search tool. These tests *must* be
+run prior to configuring FreeRADIUS. We strongly recommend having the
+LDAP database return the `userPassword` field to FreeRADIUS, so that
+FreeRADIUS can authenticate the user.
+
+We recommend that the passwords be stored in LDAP as
+cleartext. Otherwise, the only authentication methods that will work
+are PAP and EAP-TTLS/PAP. The next section explains these issues in
+more detail.
+
+== Password Storage Methods
+
+If the `userPassword` field is returned from LDAP to FreeRADIUS, that
+information can be stored in a number of different formats:
+
+* the value can be cleartext
+* the value can be prepended with a string enclosed by braces, such as with `{crypt}` or `{ssha3}`.
+* the value can be have a suffix of `::`, in which case the password is generally a https://en.wikipedia.org/wiki/Base64[base64] encoded version of the real password
+
+TIP: Base64 values can be decoded via the command: `printf "%s"
+"VALUE" | base64 -d`
+
+FreeRADIUS is capable of understanding and parsing all of the above
+formats. There is sufficient information in the password values to
+determine what format it is in (base64, binary, or text), and what
+password "encryption" mechanism has been used (crypt, MD5, SHA, SSHA2,
+SHA3, etc). All that is necessary is that the
+https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/ldap[ldap module] be configured to map
+the `userPassword` LDAP field to the `control.Password-With-Header`
+attribute in FreeRADIUS. FreeRADIUS will then "do the right thing" to
+authenticate the user.
+
+This mapping is done in the default module configuration. There are
+no additional changes required for FreeRADIUS to correctly read and
+decode the `userPassword` field from LDAP. Please see the
+https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/man/man5/rlm_pap.5[pap module] for a full list of
+supported password "encryption" formats.
+
+== Additional Considerations
+
+There are some major caveats with the above authentication methods.
+The first is that we *strongly recommend* against using "bind as
+user". This process is slow, and causes unnecessary churn in the
+connections used to contact the LDAP server. Further, the "bind as
+user" process works _only_ when a `User-Password attribute exists in
+the request. If any other authentication type is used in the request,
+then the "bind as user" _will not work_. There is no amount of
+"fixing" things or configuration changes which will make it work.
+
+The second caveat is that the `CHAP` authentication type works _only_
+when a "clear text" password is stored in the LDAP database. The
+`CHAP` calclulations are designed around having access to the "clear
+text" password. It is impossible to use any "encrypted" or "hashed"
+passwords with `CHAP`.
+
+The third caveat is that the `MS-CHAP` authentication type works
+_only_ when a "clear text" password or "NT hashed" passwords which are
+stored in the LDAP database. The `MS-CHAP` calculations are designed
+around having access to "known good" passwords in those formats. It
+is impossible to use any other kind of "encrypted" or "hashed"
+passwords with `MS-CHAP`.
+
+The final caveat is that when the LDAP database contains "encrypted"
+or "hashed" passwords, the _only_ authentication type which is
+compatible with those passwords is PAP. i.e. when the `User-Password`
+is supplied to FreeRADIUS.
+
+For recommendations on password storage methods in LDAP, please see
+the LDAP
+https://openldap.org/doc/admin24/security.html#Password%20Storage[password
+storage] page. Please note that the recommendations there are made
+for LDAP security, and pay no attention to the caveats described
+above. When both RADIUS and LDAP are used together, then the
+requirements of _both_ systems must be met in order for them to work
+together. In many cases, a naive approach to LDAP security will
+prevent RADIUS from working.
+
+The issue of a database storing passwords in clear-text has to be
+balanced against the users sending clear-text passwords in
+authentication protocols. While those passwords are protected by TLS
+(EAP-TTLS) or by RADIUS (in it's own "encryption" mechanism), it is
+generally better to use a stronger authentication method than just
+PAP.
+
+In the end, there is no perfect solution to security requirements.
+The choice may be either to give up on using a particular
+authentication method, or to relax the security requirements on LDAP
+and on password storage. The final decision as to which choice is
+best can only be made by a local administrator.
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Integrate Novell eDirectory
+
+You can integrate Novell eDirectoryTM 8.7.1 or later with FreeRADIUS to allow wireless authentication for eDirectory users. By
+integrating eDirectory with FreeRADIUS, you can do the following:
+
+* Use universal password for RADIUS authentication. Universal password
+provides single login and authentication for eDirectory users.
+Therefore, the users need not have a separate password for RADIUS and
+eDirectory authentication.
+* Enforce eDirectory account policies for users. The existing eDirectory
+policies on the user accounts can still be applied even after
+integrating with RADIUS. Also, you can make use of the intruder lockout
+facility of eDirectory by logging the failed logins into eDirectory.
+
+For configuration information please refer to the https://www.netiq.com/documentation/edir_radius/[Novell documentation].
--- /dev/null
+= Password Storage Methods
+
+If the `userPassword` field is returned from LDAP to FreeRADIUS, that
+information can be stored in a number of different formats:
+
+* The value can be cleartext.
+* The value can be prepended with a string enclosed by braces, such as with `{crypt}` or `{ssha3}`.
+* the value can be have a suffix of `::`, in which case the password is generally a https://en.wikipedia.org/wiki/Base64[base64] encoded version of the real password.
+
+[TIP]
+====
+Base64 values can be decoded via the command: `printf "%s"
+"VALUE" | base64 -d`.
+====
+
+FreeRADIUS understands and parses all of the above
+formats. There is sufficient information in the password values to
+determine what format it is in (base64, binary, or text), and what
+password "encryption" mechanism has been used (crypt, MD5, SHA, SSHA2,
+SHA3, etc). All that is necessary is that the
+xhttps://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/ldap[ldap module] be configured to map
+the `userPassword` LDAP field to the `control.Password.With-Header`
+attribute in FreeRADIUS. FreeRADIUS will then "do the right thing" to
+authenticate the user.
+
+This mapping is done in the default module configuration. There are
+no additional changes required for FreeRADIUS to correctly read and
+decode the `userPassword` field from LDAP. Please see the
+https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/pap[pap module] for a full list of
+supported password "encryption" formats.
+
+== Additional Considerations
+
+There are some major caveats with the above authentication methods.
+The first is that we *strongly recommend* against using "bind as
+user". This process is slow, and causes unnecessary churn in the
+connections used to contact the LDAP server. Further, the "bind as
+user" process works _only_ when a `User-Password attribute exists in
+the request. If any other authentication type is used in the request,
+then the "bind as user" _will not work_. There is no amount of
+"fixing" things or configuration changes which will make it work.
+
+The second caveat is that the `CHAP` authentication type works _only_
+when a "clear text" password is stored in the LDAP database. The
+`CHAP` calculations are designed around having access to the "clear
+text" password. It is impossible to use any "encrypted" or "hashed"
+passwords with `CHAP`.
+
+The third caveat is that the `MS-CHAP` authentication type works
+_only_ when a "clear text" password or "NT hashed" passwords which are
+stored in the LDAP database. The `MS-CHAP` calculations are designed
+around having access to "known good" passwords in those formats. It
+is impossible to use any other kind of "encrypted" or "hashed"
+passwords with `MS-CHAP`.
+
+The final caveat is that when the LDAP database contains "encrypted"
+or "hashed" passwords, the _only_ authentication type which is
+compatible with those passwords is PAP. i.e. when the `User-Password`
+is supplied to FreeRADIUS.
+
+For recommendations on password storage methods in LDAP, please see
+the LDAP
+https://openldap.org/doc/admin24/security.html#Password%20Storage[password
+storage] page. Please note that the recommendations there are made
+for LDAP security, and pay no attention to the caveats described
+above. When both RADIUS and LDAP are used together, then the
+requirements of _both_ systems must be met in order for them to work
+together. In many cases, a naive approach to LDAP security will
+prevent RADIUS from working.
+
+The issue of a database storing passwords in clear-text has to be
+balanced against the users sending clear-text passwords in
+authentication protocols. While those passwords are protected by TLS
+(EAP-TTLS) or by RADIUS (in it's own "encryption" mechanism), it is
+generally better to use a stronger authentication method than just
+PAP.
+
+In the end, there is no perfect solution to security requirements.
+The choice may be either to give up on using a particular
+authentication method, or to relax the security requirements on LDAP
+and on password storage. The final decision as to which choice is
+best can only be made by a local administrator.
--- /dev/null
+= Overview
+
+A RADIUS (Remote Authentication Dial In User Service) server offers authentication, authorisation, and accounting (AAA) services for network access. A Network Access Servers (NAS) sends authentication and accounting requests to a RADIUS server. The server then verifies user credentials and returns configuration details to the NAS. The NAS either grants or denies network access to the end-user or device.
+
+The key concepts of any RADIUS include:
+
+* *Centralized AAA*: RADIUS servers manage network access by verifying user credentials, granting access rights, and tracking user activity.
+
+* *Client-Server Protocol*: RADIUS uses a client-server protocol. Network Access Servers are RADIUS clients that send requests to the RADIUS server.
+
+* *Background Process*: RADIUS servers run as background processes or daemons on UNIX systems.
+
+* *User Credentials:* The server stores or can access user account information and verifies authentication requests.
+
+* *Configuration Details*: The RADIUS server sends details to the client, enabling it to grant or deny network access.
+
+== What is RADIUS?
+
+RADIUS is a network protocol that defines rules and conventions for communication between network devices for remote user authentication and accounting. Commonly used by Internet Service Providers (ISPs), cellular network
+providers, and corporate and educational networks, the RADIUS protocol serves three primary functions:
+
+* Authenticates users or devices before allowing them access to a network.
+* Authorises those users or devices for specific network services.
+* Accounts for and tracks the usage of those services.
+
+=== History
+
+In 1991, Merit Network, a non-profit internet provider, required a creative way to manage dial-in access to various Points-Of-Presence (POPs) across its network. In response to this need, RADIUS was created by Livingston Enterprises.
+When RADIUS was created, network access systems were distributed across a wide area and were run by multiple independent organisations. Central administrators wanted to prevent security and scalability issues, and therefore didn't want to distribute user names and passwords. Instead, they wanted the remote access servers to contact a central server to authorise access to the requested system or service.
+
+[NOTE]
+====
+A remote access server (RAS) is often called a Network Access Server (NAS), Network Access Client (NAC), or simply client.
+====
+
+In response to contact from the remote access server, the central server would return a “success” or “failure” message, and the remote machines would enforce this response for each end-user. This process ensures that authentication decisions are centralized, while enforcement happens at the network edge, maintaining both security and scalability in the system.
+
+The goal of RADIUS was to create a central location for user authentication, wherein users from many locations could request network access.
+The simplicity, efficiency, and usability of the RADIUS system led to its widespread adoption by network equipment vendors. RADIUS evolved into an industry and Internet Engineering Task Force (IETF) standard as outlined in https://datatracker.ietf.org/doc/html/rfc2865[RFC 2865].
+
+=== Customers
+
+Many types of businesses and organisations use the RADIUS protocol for their authentication and accounting needs. Some examples of RADIUS customers are:
+
+* Cellular network providers with millions of users.
+* Small to large ISPs to authenticate users connecting to the internet.
+* Enterprise networks implementing Network Access Control (NAC) using 802.1x or to manage access to their internal networks and VPNs.
+* Wireless networks in educational institutions and campuses.
+
+=== Benefits
+
+The RADIUS client-server architecture is an open and scalable solution. RADIUS supports a wide range of environments and can grow to handle increased demand. Its adoption by many vendors ensures compatibility with a variety of products and systems. Organizations configure RADIUS to work with various security systems, including legacy solutions. Any RADIUS client-protocol-supporting communications device can interact with a RADIUS server, simplifying integration.
+
+The RADIUS authentication mechanisms enable organizations to integrate their existing security technologies. RADIUS architecture offers authentication and authorisation services to any supported security component. Additionally, the central server can integrate with a separate authentication mechanism. RADIUS extends beyond network access devices and terminal servers. ISPs integrating RADIUS leverage their infrastructure to provide Virtual Private Network (VPN) services.
+
+The distributive nature of RADIUS separates security processes from the communications processes. This design provides a single centralized information store for authorisation and authentication information. Centralization reduces the administrative burden of providing adequate access control for remote users.
+
+[NOTE]
+====
+The authentication server manages the security processes. The network access server (NAS) handles the communication processes.
+====
+
+If high availability is not a priority, redundancy is not necessary. All RADIUS-compatible hardware on the network can derive authentication services from a single server.
+
+In summary, the RADIUS client-server protocol provides these advantages:
+
+* An open and scalable solution.
+* Broad support by a large vendor base.
+* Easy modification.
+* Separation of security and communication processes.
+* Adaptable to most security systems.
+* Workable with any communication device that supports RADIUS client protocol.
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Protocols
+
+== RADIUS Protocol
+
+RADIUS is a protocol for remote user Authorisation, Authentication, and Accounting. It's very important for Internet Service Providers, and any network that needs a centralized authentication and/or accounting services for its infrastructure.
+
+RADIUS is often used in larger Wi-Fi (wireless) networks for authentication purposes, replacing the simple shared key methods which are uncomfortable if a Wi-Fi network reaches a specific size.
+
+The protocol originally was designed by the well known terminal server manufacturer Livingston for use with their Portmaster series of terminal servers. Since then it has been implemented by hundreds other vendors and has a become an Internet Standard RFC. The DIAMETER protocol is the designated successor, but RADIUS is still commonly used today.
+
+=== RADIUS Protocol Dependencies
+
+RADIUS uses UDP as its underlying protocol. The registered UDP port for RADIUS traffic is 1812 for authentication and configuration. The early deployment of RADIUS used UDP port 1645, which conflicted with the "datametrics" service. When RADIUS is used for accounting the registered UDP port is 1813. The earlier RADIUS version used port 1646, which conflicted with the "sa-msg-port" service.
+
+== Authentication Protocols
+
+In order for RADIUS authentication to work, user passwords need to be stored in a format that is understood by the authentication protocol used by the client. Many protocols integrated with RADIUS include:
+
+* PAP
+* CHAP
+* MS-CHAP
+* EAP
+
+Authentication protocols used in RADIUS are not always compatible with the way the passwords have been stored. The following table shows which protocol is compatible with what kind of password.
+
+=== Authentication Protocol and Password Compatibility
+
+Passwords may be stored in a datastore in many forms. Clear-text, MD5 hashed, crypt'd, NT hash, or other methods are all commonly used. Authentication protocols used in RADIUS are not always compatible with the way the passwords have been stored. The following table shows which protocol is compatible with what kind of password.
+
+[#Proto-Password-Compat]
+.Protocol Password Compatibility
+[cols="2,1,1,1,1,1,1,1"]
+|===
+|*Protocol*|*Clear-text*|*NT hash*|*MD5 hash*|*Salted MD5 hash*|*SHA1 hash*|*Salted SHA1 hash*|*Unix Crypt*
+|*PAP*
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+
+|*CHAP*
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*Digest*
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*MSCHAP*
+| ✔️
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*PEAP*
+| ✔️
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*EA-MSCHAP2*
+| ✔️
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*Cisco-LEAP*
+| ✔️
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*EAP-GTC*
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+| ✔️
+
+|*EAP-MD5*
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+| ❌
+
+|*EAP-PWD*
+| ✔️
+| ❌
+| ❌
+| ❌
+| ❌
+| ✔️
+| ✔️
+
+|===
+
+Many people store passwords in their databases in hashed or encrypted form. They later decide that they need to support an authentication protocol that the above table shows is incompatible with their password storage method. They then ask "How can I make authentication protocol X work with passwords stored as Y?" The short answer is "you can't".
+
+The password hashes, and authentication protocols were designed to be incompatible. If the cell in the above table is red, then it's impossible to make the authentication protocol use that form of the password. Your only choices are to stop trying to use that authentication protocol, or to store the passwords in a form compatible with that authentication protocol. The last choice often means asking all users to change their passwords, unfortunately.
+
+== More Information
+
+Refer to https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/share[Attributes] for more protocol attribute details and https://www.iana.org/assignments/radius-types/radius-types.xhtml[RADIUS Packet Types].
+
+The relevant RFCs are:
+
+* https://datatracker.ietf.org/doc/html/rfc2867[RFC 2867] RADIUS Accounting Modifications for Tunnel Protocol Support
+
+* https://datatracker.ietf.org/doc/html/rfc2868[RFC 2868] RADIUS Attributes for Tunnel Protocol Support
+
+* https://datatracker.ietf.org/doc/html/rfc2869[RFC 2869] RADIUS Extensions
+
+* https://datatracker.ietf.org/doc/html/rfc3758[RFC 3748] Extensible Authentication Protocol (EAP)
+
+* https://datatracker.ietf.org/doc/html/rfc3579[RFC 3579] RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
+
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+*Protected Extensible Authentication Protocol*, *Protected EAP*, or simply *PEAP* (pronounced *peep*), is a method to securely transmit authentication information, including passwords, over wireless LANs. It was jointly developed by Microsoft, RSA Security and Cisco.
+It is an IETF open standard.
+
+PEAP is **not** an encryption protocol; as with other EAP types it only authenticates a client into a network.
+
+PEAP uses only server-side public key certificates to authenticate clients by creating an encrypted SSL/TLS tunnel between the client and the authentication server, which protects the ensuing exchange of authentication information from casual inspection.
+
+PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication.
+
+As of May of 2005, there were two PEAP sub-types certified for the updated WPA and WPA2 standard. They are:
+
+* PEAPv0/EAP-MSCHAPv2
+* PEAPv1/EAP-GTC
+
+== Types
+
+=== PEAPv0/EAP-MSCHAPv2
+
+PEAPv0/EAP-MSCHAPv2 is the most common form of PEAP in use, and what is usually referred to as PEAP.
+
+Behind EAP-TLS, PEAPv0/EAP-MSCHAPv2 is the second most widely supported EAP standard in the world. There are client and server implementations of it from various vendors, including support in all recent releases from Microsoft, Apple and Cisco.
+Other implementations exist such as AEGIS from Meetinghouse and xsupplicant from the Open1x.org project.
+
+=== PEAPv1/EAP-GTC
+
+PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2. It allows the use of an inner authentication protocol other than Microsoft’s MSCHAPv2.
+
+Even though Microsoft co-invented the PEAP standard, Microsoft never added support for PEAPv1 in general, which means PEAPv1/EAP-GTC has no native Windows OS support.
+
+Since Cisco has always favored the use of its own less secure proprietary LEAP and EAP-FAST protocols over PEAP and markets them as simpler certificate-less solutions, standardized PEAP is rarely promoted by Cisco.
+
+Cisco stands to gain a monopoly in the access point market if LEAP or EAP-FAST is universally adopted. As a result, most Cisco customers run Cisco's proprietary LEAP or EAP-FAST authentication protocols due to their promotion by Cisco. With no interest from Microsoft to support PEAPv1 and little interest from Cisco to promote PEAP in general, PEAPv1 authentication is rarely used. There is no native OS support for this EAP protocol.
+
+Note: The PEAP standard was created by Microsoft, Cisco, and RSA after EAP-TTLS had already come on the market. Even with its late start, Microsoft’s and Cisco’s size allowed them to quickly overtake EAP-TTLS in the market.
+
+Microsoft and Cisco parted ways when Microsoft only supported the PEAPv0 standard while Cisco supported both PEAPv0 and PEAPv1. PEAPv0 and PEAPv1 both refer to the outer authentication method and is the mechanism that creates the secure TLS tunnel to protect subsequent authentication transactions while EAP-MSCHAPv2, EAP-GTC, and EAP-SIM refer to the inner authentication method which facilitates user or device authentication.
+
+From Cisco’s perspective, PEAPv0 supports inner EAP methods EAP-MSCHAPv2 and EAP-SIM while PEAPv1 supports inner EAP methods EAP-GTC and EAP-SIM.
+
+Since Microsoft only supports PEAPv0 and doesn’t support PEAPv1, Microsoft simply calls PEAPv0 PEAP without the v0 or v1 designator. Another difference between Microsoft and Cisco is that Microsoft only supports PEAPv0/EAP-MSCHAPv2 mode but not PEAPv0/EAP-SIM mode.
+
+=== PEAP-EAP-TLS
+
+Microsoft supports another form of PEAPv0 (which Microsoft calls PEAP-EAP-TLS) that Cisco and other third-party server and client software don’t support. PEAP-EAP-TLS does require a client-side digital certificate located on the client’s hard drive or a more secure smartcard. PEAP-EAP-TLS is very similar in operation to the original EAP-TLS but provides slightly more protection due to the fact that portions of the client certificate that are unencrypted in EAP-TLS are encrypted in PEAP-EAP-TLS.
+
+Since few third-party clients and servers support PEAP-EAP-TLS, users should probably avoid it unless they only intend to use Microsoft desktop clients and servers.
+
+Ultimately, PEAPv0/EAP-MSCHAPv2 is the only form of PEAP that most people will ever know. PEAP is so successful in the market place that even Funk Software, the inventor and backer of EAP-TTLS, had no choice but to support PEAP in their server and client software for wireless networks.
+
+== References
+
+* Understanding the updated WPA and WPA2 standards(http://blogs.zdnet.com/Ou/index.php?p=67)
+
+== External links
+
+* draft-josefsson-pppext-eap-tls-eap(http://www.potaroo.net/ietf/idref/draft-josefsson-pppext-eap-tls-eap/) - The PEAP protocol specifications
+
+== See Also
+
+* EAP
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+
+== Overview
+
+*Wired Equivalent Privacy (WEP)* is a scheme that is part of the IEEE 802.11 wireless networking standard to secure IEEE 802.11 wireless computer network (also known as Wi-Fi networks). Because a wireless network broadcasts messages using radio, it is particularly susceptible to eavesdropping. WEP was intended to provide comparable confidentiality to a traditional wired local area network|network (in particular it doesn't protect users of the network from each other), hence the name. Several serious weaknesses were identified by cryptanalysts, and WEP was superseded by Wi-Fi Protected Access (WPA) in 2003, and then by the full IEEE 802.11i standard (also known as WPA2) in 2004. Despite the weaknesses, WEP provides a level of security that can deter casual snooping.
+
+== Details
+
+WEP is part of the IEEE 802.11 standard ratified in September 1999. WEP uses the stream cipher RC4 for confidentiality and the CRC-32 checksum for integrity.
+
+Standard 64-bit WEP uses a 40-bit encryption|40 bit key, which is concatenated to a 24-bit initialization vector (IV) to form the RC4 traffic key. At the time that the original WEP standard was being drafted, US Government export of cryptography limited the keysize. Once the restrictions were lifted, all of the major manufacturers eventually implemented an extended 128-bit WEP protocol using a 104-bit key size.
+A 128-bit WEP key is almost always entered by users as a string of 26 Hexadecimal (Hex) characters (0-9 and A-F). Each character represents 4 bits of the key. 4 * 26 = 104 bits. Adding the 24-bit IV brings us what we call a "128-bit WEP key". A 256-bit WEP system is available from some vendors, and as with the above-mentioned system, 24 bits of that is for the I.V., leaving 232 actual bits for protection. This is typically entered as 58 Hexadecimal characters. (58 * 4 = 232 bits) + 24 I.V. bits = 256 bits of WEP protection.
+
+Key size is not the only major security limitation in WEP. Cryptanalysis a longer key requires interception of more packets, but there are active attacks that stimulate the necessary traffic. There are other weaknesses in WEP, including the possibility of IV collisions and altered packets, that are not helped at all by a longer key. See stream cipher attack.
+
+== Flaws
+
+Because RC4 is a stream cipher, the same traffic key must never be used twice. The purpose of an IV, which is transmitted as plaintext, is to prevent any repetition, but a 24-bit IV is not long enough to ensure this on a busy network. The way the IV was used also opened WEP to a [[related key attack]]. For a 24-bit IV, there is a 50% probability the same IV will repeat after 5000 packets.
+
+Many WEP systems require a key in hexadecimal format. Some users choose keys that spell words in the limited 0-9, A-F hex character set, for example _C0DE C0DE C0DE C0DE_. Such keys are often easily guessed.
+
+In August 2001, Scott Fluhrer, Itzik Mantin, and Adi Shamir published a cryptanalysis of WEP that exploits the way the RC4 cipher and IV is used in WEP, resulting in a passive attack that can recover the RC4 key (cryptography) after eavesdropping on the network (depending on the network traffic (the number of packets you can inspect) the length could be from 10 minutes to indefinitely (if there is no data being sent at all)). There are also ways to force the traffic onto the network which is rejected, but packets are sent and thus can also be inspected to find the key. The attack was soon implemented, and automated tools have since been released. It is possible to perform the attack with a personal computer, off-the-shelf hardware and freely-available software.
+
+Cam-Winget et al. (2003) surveyed a variety of shortcomings in WEP. They write "_Experiments in the field indicate that, with proper equipment, it is practical to eavesdrop on WEP-protected networks from distances of a mile or more from the target._" They also reported two generic weaknesses:
+* the use of WEP was optional, resulting in many installations never even activating it, and
+* WEP did not include a key management protocol, relying instead on a single shared key amongst users.
+
+In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.<ref>http://www.tomsnetworking.com/2005/03/31/the_feds_can_own_your_wlan_too/</ref>
+
+In 2006, Bittau, Handley and Lackey showed that the 802.11 protocol itself can be used against WEP to enable earlier attacks that were previously thought impractical. After eavesdropping a single packet, an attacker can rapidly bootstrap to be able to transmit arbitrary data. Then the eavesdropped packet can be decrypted a byte at a time (by transmitting about 128 packets per byte to decrypt) to discover the local network IP addresses. Finally if the 802.11 network is connected to the Internet, the attacker can use 802.11 fragmentation to replay eavesdropped packets while crafting a new IP header on to them. The access point can then be used to decrypt these packets and relay them on to a buddy on the Internet, allowing real-time decryption of WEP traffic within a minute of eavesdropping the first packet.
+
+== Remedies
+
+=== WEP2
+
+A stopgap enhancement to WEP, implementable on _some_ (not all) hardware not able to handle WPA/WPA2, based on:
+* Enlarged IV value
+* Enforced 128-bit encryption
+However, WEP2 remains vulnerable to known WEP attacks -- at most it will just slow an attacker down a bit -- and thus shouldn't really be considered more secure than WEP.
+
+=== WEPplus
+
+Also known as WEP+. A proprietary enhancement to WEP by Agere Systems (formerly a subsidiary of Lucent Technologies) that enhances WEP security by avoiding "weak IVs". It is only completely effective when WEPplus is used at _both ends_ of the wireless connection. As this cannot easily be enforced, it remains serious limitation. It is possible that successful attacks against WEPplus will eventually be found. It also does not necessarily prevent Replay attack|replay attacks.
+
+=== WPA/WPA2
+
+The most widely recommended solution to WEP security problems is to switch to WPA or WPA2. Either is much more secure than WEP. Some old WiFi access points might need to be replaced to do this or have their operating system, in flash memory, upgraded; however, replacements are relatively inexpensive. Another alternative is to use a tunneling protocol, such as IPsec, although that only protects traffic streams, not the network itself.
+
+== References
+
+* Nikita Borisov, Ian Goldberg, David Wagner, "Intercepting mobile communications: the insecurity of 802.11." MOBICOM 2001, pp180–189.
+* Nancy Cam-Winget, Russell Housley, David Wagner, Jesse Walker: Security flaws in 802.11 data link protocols. Communications of the ACM 46(5): 35-39 (2003)
+* Scott R. Fluhrer, Itsik Mantin, Adi Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4". Selected Areas in Cryptography 2001: pp1–24.
+* Andrea Bittau, Mark Handley, Joshua Lackey, "The Final Nail in WEP's Coffin", IEEE Symposium on Security and Privacy (Oakland) 2006.
+* Update: Stepping Up Your WLAN Security (http://www.networkmagazineindia.com/200112/focus3.htm 802.11b)
+* Wireless LAN Deployment and Security Basics (http://www.extremetech.com/article2/0,1697,1157728,00.asp)
+* An Inductive Chosen Plaintext Attack against WEP/WEP2 (http://www.cs.umd.edu/~waa/attack/v3dcmnt.htm)
+* [http://www.starkrealities.com/wireless003.html It Came Out of the Sky -- WEP2, Credibility Zero]
+* [http://www.agere.com/NEWS/PRESS2001/111201b.html Agere Systems press release]
+** [http://www.proxim.com/learn/library/whitepapers/wireless_security.pdf Wireless Network Security] ([[Proxim Wireless]] white paper)
+* Weak IVs
+** [http://www.cs.virginia.edu/sammyg/CS551/node16.html Weak IV Attack]
+** [http://www.informit.com/guides/content.asp?g=security&seqNum=85&rl=1 WPA Part 2: Weak IV's]
+** [http://airsnort.shmoo.com/faq.html Frequently Asked Questions About AirSnort]
+* [http://www.cs.virginia.edu/sammyg/CS551/node18.html Replay Attack]
+
+==External links==
+
+*[http://www.profit42.com/index.php/2006/08/02/92/ This simple but detailled guide describes how to crack wep step by step]
+*[http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html (In)Security of the WEP algorithm]
+*[http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf Weaknesses in the Key Scheduling Algorithm of RC4]
+*[http://www.cs.virginia.edu/sammyg/CS551/node12.html WEP Weaknesses]
+*[http://www.cs.umd.edu/~waa/wireless.html List of security problems with WEP]
+*[http://securityfocus.com/infocus/1814 WEP: Dead Again, Part 1 (Dec. 14, 2004)]
+*[http://securityfocus.com/infocus/1824 WEP: Dead Again, Part 2 (Mar. 8, 2005)]
+*[http://www.tomsnetworking.com/Sections-article111.php The Feds can own your WLAN too : TomsNetworking]
+* Humphrey Cheung, How to crack WEP, [http://www.tomsnetworking.com/Sections-article118.php part one], [http://www.tomsnetworking.com/Sections-article120.php part two], [http://www.tomsnetworking.com/Sections-article124.php part three] May/June 2005.
+
+
+*Several software tools are available to compute and recover WEP keys by passively monitoring transmissions.
+**[http://www.tuto-fr.com/tutoriaux/crack-wep/fichiers/wlan/en-index.php aircrack]
+**[[aircrack-ng|Aircrack-ng (aircrack-ng is the next generation of aircrack)]]
+**[http://airsnort.shmoo.com/ AirSnort]
+**[http://sourceforge.net/projects/wepcrack WEPCrack]
+**[http://sourceforge.net/projects/weplab Weplab]
+**[http://kismac.binaervarianz.de/ KisMAC]
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+== Overview
+
+*Wi-Fi Protected Access* (*WPA* and *WPA2*) is a class of systems to secure wireless (Wi-Fi) computer networks. It was created in response to several serious weaknesses researchers had found in the previous system, Wired Equivalent Privacy (WEP). WPA implements the majority of the IEEE 802.11i standard, and was intended as an intermediate measure to take the place of WEP while 802.11i was prepared. WPA is designed to work with all wireless network interface cards, but not necessarily with first generation wireless access points. WPA2 implements the full standard, but will not work with some older network cards. Both provide good security, with two significant issues:
+
+* either WPA or WPA2 must be enabled and chosen in preference to WEP. WEP is usually presented as the first security choice in most installation instructions.
+* in the "Personal" mode, the most likely choice for homes and small offices, a passphrase is required that, for full security, must be longer than the typical 6 to 8 character passwords users are taught to employ.
+
+== History
+
+WPA was created by the The Wi-Fi Alliance, an industry trade group, which owns the trademark to the Wi-Fi name and certifies devices that carry that name.
+
+WPA is designed for use with an IEEE 802.1X authentication server, which distributes different keys to each user; however, it can also be used in a less secure *"pre-shared key" (PSK)* mode, where every user is given the same passphrase. The design of WPA is based on a Draft 3 of the IEEE 802.11i standard.
+
+The Wi-Fi Alliance created WPA to enable introduction of standard-based secure wireless network products prior to the IEEE 802.11i group finishing its work. The Wi-Fi Alliance at the time already anticipated the WPA2 certification based on the final draft of the IEEE 802.11i standard, therefore the tags on the frame fields (Information Elements or IEs) are intentionally made different from 802.11i to avoid the confusion in unified WPA/WPA2 implementations.
+
+Data is encrypted using the RC4 (cipher), with a 128-bit key and a 48-bit initialization vector (IV). One major improvement in WPA over WEP is the Temporal Key Integrity Protocol (TKIP), which dynamically changes keys as the system is used. When combined with the much larger IV, this defeats the well-known related-key attack on WEP.
+
+In addition to authentication and encryption, WPA also provides vastly improved payload integrity. The cyclic redundancy check (CRC) used in WEP is inherently insecure; it is possible to alter the payload and update the message CRC without knowing the WEP key. A more secure message authentication code (usually known as a MAC, but here termed a *MIC* for "Message Integrity Code") is used in WPA, an algorithm named "Michael". The MIC used in WPA includes a frame counter, which prevents replay attack being executed;
+
+By increasing the size of the keys and IVs, reducing the number of packets sent with related keys, and adding a secure message verification system, WPA makes breaking into a Wireless LAN far more difficult. The Michael algorithm was the strongest that WPA designers could come up with that would still work with most older network cards. Due to inevitable weaknesses of Michael, WPA includes special countermeasure mechanism that detects the attempt to break TKIP and temporarily blocks communications with the attacker.
+
+== WPA2
+
+WPA2 implements the mandatory elements of 802.11i. In particular, in addition to TKIP and the Michael algorithm, it introduces a new Advanced Encryption Standard based algorithm, CCMP, that is considered fully secure. Official support for WPA2 in Microsoft Windows XP was rolled out on 1 May 2005. Driver upgrades for network cards may be required. Apple Computer supports WPA2 on all AirPort Extreme-enabled Apple Macintosh, the AirPort Extreme Base Station, and the AirPort Express. Firmware upgrades needed are included in AirPort 4.2, released July 14, 2005. Note that from March 13, 2006, WPA2 certification is mandatory for all new devices wishing to be Wi-Fi certified.
+
+== Security in pre-shared key mode
+
+Pre-shared key mode (PSK, also known as *personal* mode) is designed for home and small office networks that cannot afford the cost and complexity of an 802.1X authentication server. Each user must enter a passphrase to access the network. The passphrase may be from 8 to 63 ASCII characters or 64 hexadecimal digits (256 bits). If you choose to use the ASCII characters, a Hash_function|hash function reduces it from 504 bits (63 characters * 8 bits/character) to 256 bits (using also the SSID). The passphrase may be stored on the user's computer at their discretion under most operating systems to avoid re-entry. The passphrase must remain stored in the Wi-Fi access point.
+
+Security is strengthened by employing a PBKDF2 key derivation function. However, the weak passphrases users typically employ are vulnerable to password cracking attack. Password cracking can be defeated by using a passphrase of at least 5 Diceware words or 14 completely random letters with WPA and WPA2. For maximum strength, 8 Diceware words or 22 random characters should be employed. Passphrases should be changed at regular intervals, or whenever an individual with access is no longer authorized to use the network or when a device configured to use the network is lost or compromised.
+
+Some consumer chip manufacturers have attempted to bypass weak passphrase choice by adding a method of automatically generating and distributing strong keys through a software or hardware interface that uses an external method of adding a new Wi-Fi adapter or appliance to a network. These methods include pushing a button (Broadcom and Buffalo AirStation One-Touch Secure System]) and entering a short challenge phrase through software (Atheros). The Wi-Fi Alliance is currently working on standardisation of this approach as part of its Simple Configuration effort.
+
+== EAP types under WPA- and WPA2- Enterprise
+
+The Wi-Fi alliance has announced the inclusion of additional EAP (Extensible Authentication Protocol) types to its certification programs for WPA- and WPA2- Enterprise. This was to ensure that WPA-Enterprise certified products can interoperate with one another. Previously, only EAP-TLS (Transport Layer Security) was certified by the Wi-Fi alliance.
+
+The EAP types now included in the certification program are:
+
+* EAP-TLS (previously tested)
+* EAP-TTLS/MSCHAPv2
+* PEAPv0/EAP-MSCHAPv2
+* PEAPv1/EAP-GTC
+* EAP-SIM
+
+Other EAP types may be supported by 802.1X clients and servers developed by specific firms. This certification is an attempt for popular EAP types to interoperate; their failure to do so is currently one of the major issues preventing rollout of 802.1X on heterogeneous networks.
+
+== See also
+
+* WAPI —<!-- controversial--> Chinese National Standard for wireless LAN security.
+* tinyPEAP — a small-footprint RADIUS server designed to load into a wireless access point
+* FreeRADIUS - a free [[open source]] RADIUS server
+* Radiuz — a "cooperative WiFi network" that provides free RADIUS service for WPA-Enterprise compatible routers
+* SecureMyWiFi — Service that provides WPA/WPA2-Enterprise security with User/Network Management Interface.
+* SecureEasySetup — a technology developed by Broadcom to easily set up wireless LANs with WPA
+
+== References
+
+* Wi-Fi Alliance. (2003). Wi-Fi Protected Access: Strong, standards-based, interoperable security for today’s Wi-Fi networks. Retrieved March 1, 2004 from http://www.wifialliance.com/OpenSection/pdf/Whitepaper_Wi-Fi_Security4-29-03.pdf
+* Wi-Fi Alliance. (2004). Wi-Fi Protected Access™ security sees strong adoption: Wi-Fi Alliance takes strong position by requiring WPA security for product certification. Retrieved January 5, 2004 from http://www.wi-fi.org/opensection/ReleaseDisplay.asp?TID=4&ItemID=165&StrYear=2004&strmonth=2
+* Weakness in Passphrase Choice in WPA Interface, by Robert Moskowitz. Retrieved March 2, 2004 from http://wifinetnews.com/archives/002452.html
+* Press Release about new EAP types supported under WPA-Enterprise from http://www.wi-fi.org/OpenSection/ReleaseDisplay.asp?TID=4&ItemID=205&StrYear=2005&strmonth=4
+
+== External links
+
+* Wi-Fi Alliance's WPA page (http://www.wi-fi.org/opensection/protected_access.asp)
+* Wi-Fi Alliance's Interoperability Certificate page (http://www.wi-fi.org/opensection/certification-certificate.asp)
+* Network Configuration with WPA (http://www.wi-fiplanet.com/tutorials/article.php/3552826)
+* Apple Airport and Wi-Fi Network Security (http://theworld.com/~reinhold/airport.html)
+* EAP types supported under WPA-Enterprise (http://www.wi-fi.org/OpenSection/eap.asp)
+* Linux WPA/WPA2/IEEE 802.1X Supplicant (http://hostap.epitest.fi/wpa_supplicant/)
+* SmithMicro Quicklink Mobile Software (http://www.smithmicro.com/default.tpl?sku=QLMWA0EE&group=product_full)
+* Steve Gibson's Perfect Passwords(https://www.grc.com/passwords/)
+* GRC's Ultra High Security Password Generators(http://darkvoice.dyndns.org/wlankeygen/ Online WEP-/WPA-Key Generator)
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= RESOURCES
+
+== Primary Sites
+
+* *https://www.freeradius.org/[FreeRADIUS]*
+* *https://www.inkbridgenetworks.com/[Inkbridge Networks]*
+
+== Mailing lists
+
+include::ROOT:partial$mailinglist.adoc[]
+
+== RFCs
+
+* http://www.freeradius.org/rfc/[Related RFCs and Drafts]
+
+* https://datatracker.ietf.org/doc/html/rfc2865[RFC 2865] Remote Authentication Dial In User Service (RADIUS)
+* https://datatracker.ietf.org/doc/html/rfc2866[RFC 2866] RADIUS Accounting
+* https://datatracker.ietf.org/doc/html/rfc2867[RFC 2867] RADIUS Accounting Modifications for Tunnel Protocol Support
+* https://datatracker.ietf.org/doc/html/rfc2868[RFC 2868] RADIUS Attributes for Tunnel Protocol Support
+* https://datatracker.ietf.org/doc/html/rfc2869[RFC 2869] RADIUS Extensions
+* https://datatracker.ietf.org/doc/html/rfc3758[RFC 3748] Extensible Authentication Protocol (EAP)
+* https://datatracker.ietf.org/doc/html/rfc3579[RFC 3579] - RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
+
+== Related RADIUS Sites
+* *https://www.iana.org/assignments/radius-types/radius-types.xhtml[RADIUS Packet Types]*
+
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= Processing
+
+The server processes requests through local site policy. That policy is used to examine the request, the request attributes, and the attribute values. The server then builds a reply message using responses (determined by local policy) such as time of day restrictions, group access limitations, and IP address
+allocation. The processing stage may include keeping track of <<server-attr,server-side attributes>>.
+
+== How things work in RADIUS
+
+The client sends the server a RADIUS authentication request. You don't decide what's in the request, the client does. The server doesn't decide what's in the request, the client does. The client is 100% responsible for everything in the request.
+
+
+.FreeRADIUS v3 Request Flow
+image:request_flow.svg[Process Flow railroad diagram].
+
+=== Summary of the Request Flow Steps
+
+. An end-user tries to access a network through a RADIUS client such as a wireless access point.
+. The RADIUS client sends a request to the RADIUS server along with the user's credentials.
+. The RADIUS server verifies the user's credentials against its datastore (flat file, SQL, LDAP, etc.).
+. If authentication passes, the server returns configuration details (including authorisation) to the client. The client can now grant network access to the end-user
+. If the authentication fails, the server denies access, and the RADIUS client informs the end-user.
+
+
+Users new to RADIUS, AAA, or EAP are encouraged to read the standards listed below. This documentation provides you with a solid foundation in RADIUS concepts and EAP at a protocol level.
+
+- https://datatracker.ietf.org/doc/html/rfc2865[RFC 2865] - Remote Authentication Dial In User Service (RADIUS)
+- https://datatracker.ietf.org/doc/html/rfc2866[RFC 2866] - RADIUS Accounting
+
+- https://datatracker.ietf.org/doc/html/rfc3748[RFC 3748] - Extensible Authentication Protocol (EAP)
+- https://datatracker.ietf.org/doc/html/rfc2865[RFC 3579] - RADIUS Support For Extensible Authentication Protocol (EAP)
+
+
+== Request Processing
+
+When the server processes requests, it manages four xref:unlang:list.adoc[attribute lists]. All of these lists are available to all modules. All of these lists are available in xref:unlang:index.adoc[Unlang]
+
+.Attribute Lists and Details
+
+[cols="1,2"]
+|===
+|*Attribute List*|*Description*
+
+|`request`
+|Attributes taken from the received packet.
+
+|`reply`
+|Attributes which will be sent in the reply.
+
+|`control`
+|Attributes used to control how the server operates. These are never sent in a packet.
+
+|`session-state`
+|Attributes which are saved and restored across multiple request / reply exchanges.
+|===
+
+
+
+== Select an Auth-Type - authorise {}
+
+The RADIUS server looks at the request and says:
+
+> Hmmm... can I deal with this request?
+
+The answer to that depends on what authentication types are enabled in the server, what the server can look up in a datastore, and what is in the request.
+
+The server starts querying the modules in the authorise section:
+
+> Unix module, can you handle this one?
+
+> Pap module, can you handle this one?
+
+> Mschap module, can you handle this one?
+
+At some point, one of the modules will say:
+
+> Yes, I see something in the request I recognize. I can do something!
+
+The module does this by looking for key attributes in the received request, such as MS-CHAP-Challenge (for mschap), or CHAP-Challenge (for chap), or EAP-Message (for eap). Or it may just assume it needs to add something to every request.
+
+If the module thinks has a possibility of authenticating the user, it'll say:
+
+> I can't authenticate this user now (I was just told to authorise them i.e. set the Auth-Type),
+> but my pal in the Authenticate section can!
+> Hey, set the Auth-Type to me!
+
+TThe module performs no action if it doesn't recognize anything in the request. If the module knows it doesn't need to do lookups, the module also does nothing.
+
+== Authenticate a user - authenticate {}
+
+At the end of the authorise process, the server checks if the Auth-Type has been set by a module.
+
+If no module sets the Auth-Type, the server immediately rejects the request.
+
+For example, the client sends a request with a User-Password attribute, and pap is enabled. The pap module then sets the ``Auth-Type = pap``.
+
+During this authenticate process, the server calls the pap module again:
+
+> I see a User-Password, which is what the user entered.
+> That's nice, but I need to compare it with something.
+> Ah! Another module added the "known good" password for this user in authorise!
+
+Next, the server compares the local "known good" password to the password as entered by the user. This is how authentication works.
+
+The "known good" password comes from another module. The pap module just does PAP authentication, and nothing more. The benefit of this approach is that the "known good" password can come from the 'users' file, SQL, LDAP, ``/etc/passwd``, or any external program.
+
+For this example, the ldap module is listed in the authorise section. It will have run and checked:
+
+> Hmm... Can I find a "known good" password for this user?
+
+If so, it will have added the "known good" password to the request, so that another module in authenticate can use it.
+
+== Insufficient information
+
+But WAIT! What if the client sends a MSCHAP request? What does the RADIUS server say then?
+
+> Well, this difficult and not the same as previous request
+> That client has made this difficult. I'm limited by some constraints!
+
+In this case, the mschap module looks at the request, and finds the MS-CHAP attributes. It sets the *Auth-Type* to itself (mschap). A database module (such as LDAP, above) gets the "known good" password, and adds it to the request. The mschap module is then run for authentication. It looks for either a clear text password or nt-hash. See an explanation for this limitation is explained in the xref:protocol/authproto.adoc#Proto-Password-Compat[Protocol Password Compatibilty] table. If one of those hasn't been added by a database, the mschap module says:
+
+> Sorry, I can't authenticate the user,
+> because I don't have the information I need to validate MSCHAP.
+
+But now the server has run out of options! Its only choice was mschap because that's what the client sent in the request. The mschap module can't do anything because you didn't give it a useful "known good" password . So the server has no choice but to reject the request. The MSCHAP data might be correct, but the server has no way to know that. So it replies with a reject.
+
+// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
+// This documentation was developed by Network RADIUS SAS.
--- /dev/null
+= RADIUS Sessions
+
+A RADIUS session consists of the following steps:
+
+. A remote user connects to a RADIUS client device (using Point-to-Point Protocol (PPP, 802.1X) or another Data Layer link protocol) and initiates a login:
+
+* The NAS initiates all conversations (Authentication Sessions) in RADIUS.
+* All information sent to the server is done solely at the discretion of the client.
+* The RADIUS server does not control what the NAS sends.
+
+. The Network Access Server communicates with the RADIUS server using a shared secret mechanism:
+
+* RADIUS uses User Datagram Protocol (UDP) port 1812 for authentication and 1813 for accounting.
+
+. The NAS sends a RADIUS message (called an Access-Request) to the server.
+
+* This message contains information about the user, including user name, authentication credentials, and requested service.
+* In addition, the message may contain information about the NAS, such as its host name, MAC address, or wireless SSID.
+* The message is sent using the Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), or Extensible Authentication Protocol (EAP).
+* The server must decide whether to authenticate or authorise a user based solely on the information contained within the NAS request, as it does not have access to any additional user information.
+* If the NAS sends a packet with an authentication protocol that the server does not support, the server will reject that request.
+
+. The RADIUS server processes the request and verifies the login request against either a local data- base or the authentication service running on the network.
+
+* Authentication services can include: LDAP servers for a domain validation; Active Directory servers on Windows networks; Kerberos servers; SQL Server or another type of database for getting information from a database
+
+. The RADIUS server sends validation results back to the NAS in one of the following forms: Access Reject, Access Challenge, or Access Accept.
+
+* Access Reject locks the user out of the network if the user is invalid or not authorized, denying them access to the requested resource.
+* Access Challenge occurs when the server requires additional information from the user. Since RADIUS packages are limited in size, Access Challenges allow the exchange of larger amounts of data.
+* Access Accept provides the user access to the resource and contains policy information which the NAS uses to provide services to, and enforce the behavior of the user. An Access Accept condition does not apply to all resources. Each additional resource is checked as required. The RADIUS client also verifies the original access offered on a periodic basis.
+* An Access Accept response results in the NAS providing the following services to the remote client: supplys a static or dynamic IP address; assigning a Time-to-Live for the session; downloading and applying the users’ Access Control List (ACL); setting up any L2TP , VLAN, and QoS session parameters required
+
+. Once the session is established on the RADIUS client, the accounting process is initiated:
+
+* The Accounting-Request (start) message, sent by the NAS to the server, indicates the commencement of the session. The the session account record is then created. * The Accounting-Request account record is then closed.
+(stop) message indicates the end of the session; the session
+* The data stored in the database during the accounting sessions is used to generate billable information and reports.
+* Accounting information retained in the database includes the following: time of session, number of packets and amount of data transferred, user and machine identification, network address, and point of attachment information.
--- /dev/null
+= Messages
+
+A RADIUS session message consists of a single User Datagram Protocol (UDP) packet, containing a short header followed by the authentication, authorisation, or accounting data.
+
+== Message Attributes
+
+Each message contains a list of Attribute Value Pairs (AVPs), commonly referred to as attributes. These attributes carry information from the NAS to the server or virtual proxy server and from the server to the NAS. Common attributes include items such as user name, password, IP address, and NAS address; each
+attribute contains only one of these items. An attribute can also contain sub-attributes, for grouping purposes.
+
+For a complete list of standardized attributes, see the http://freeradius.org/rfc/attributes.html[FreeRADIUS RFC Attributes] for more details.
+Each client and server supports only a limited set of attributes. In some cases, attributes may not be supported because the server or NAS software may have been written before a standard was published, or the software may not support that particular functionality.
+
+Consult the software vendor documentation to determine what attributes are supported. If the documentation doesn't contain this information, the select attributes are probably not supported. Contact the vendor for additional information.
+
+In addition to standardized attributes, vendors can extend RADIUS with vendor-specific attributes (VSAs). Using VSAs means that the vendor can rapidly add functionality without having to do a time-consuming standardisation process.
+In order to be useful in the RADIUS client protocol, however, VSAs must be defined on the RADIUS server. Because VSAs are non-standardized attributes, it is difficult to discover any information about them. In addition, they are all vendor-specific (only work on that vendor’s products). Thus, defining VSAs for
+RADIUS server use may be difficult.
+
+== Attribute Types
+
+Basic RADIUS attribute types are defined in http://tools.ietf.org/html/rfc2865[RFC 2865]. Since the original implementation and standardisation, additional attribute types have been also defined.
+
+.RADIUS Attribute Types
+[options="headers, autowidth"]
+|===
+| *Type* | *Format* | *Description*
+| integer | Value between 0 - 4294967295 | Unsigned 32-bit integer.
+| ipaddr | x.x.x.x | IPv4 address
+| date | 10 digit epoch time (xxxxxxxxxx)| Unix timestamp in seconds since January 1, 1970 GMT.
+| string | Variable-length string field | Used by FreeRADIUS for printable text strings.
+| octet | Variable-length string field | Used by FreeRADIUS for binary data.
+| ifid | x.x.x.x.x.x.x.x | IPv6 interface ID (host portion).
+| ipv6addr | x.x.x.x.x.x.x.x | IPv6 address.
+| ipv6prefix | Value between 0 - 128 | IPv6prefix.
+| byte | Single-byte integer | Supported in FreeRADIUS > v2.
+Value between 0 - 255.
+| short | Two-byte integer | Supported in FreeRADIUS > v3.
+Values between 0 - 65535, integer64, 8-byte integer.
+|===
+
+See xref:unlang:type/index.adoc[data types of attributes] for a more details.
+
+== https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x/share[Attribute Definition Dictionaries]
+
+FreeRADIUS contains over 100 dictionaries, which hold nearly 5000 attribute definitions.
+
+Unlike text-based protocols such as SMTP or HTTP, RADIUS is a binary protocol; therefore, although attributes are commonly referred to by name (for example, “User-Name”), these names have no meaning in the protocol. Data (i.e., “User-Name”) are encoded in a message as a binary header with binary data, and not as text strings.
+
+Dictionary files are used to map between the names used by people and the binary data in the RADIUS packets.
+
+The packets sent by the NAS contain attributes that have a number, a length, and binary data. By contrast, a dictionary file consists of a list of entries with name, number, and data type.
+
+The server uses the dictionaries to interpret the binary data as follows: the server searches the dictionaries to match the number from the packet, and the corresponding data type in the dictionary entry is then used by the server to interpret the binary data in the packet. The name within the dictionary entry appears in all logs and debug messages, in order to present the attribute in a form that is understandable to people.
+
+This process also works in reverse: the server uses the dictionaries to encode a string (i.e., “User-Name = Bob”) as “number, length, binary data” in a packet.
+
+For example, a server may receive a packet that contains the number 1 and some binary data. The server would not be able to decode these attributes without knowing if the binary data were in the form of a string, an IP address, or an integer. The corresponding dictionary entry may state: the number ‘1’ is called
+‘User-Name’ and it is in the form ‘string’. This information (i.e., form = ‘string’), contained in the dictionary entry, allows the server to successfully decode the packet.
+
+Adding new attributes to RADIUS software is made simpler through the use of dictionaries, as they allow the administrator to create new mappings without upgrading the software.
+
+Vendors can define new attributes in the dictionary without changing any of the server or client source code. These new attributes can then be incorporated in policy decisions or logged in an accounting record.Vendors can also define new functionality for their equipment by publishing a new dictionary file.
+Server support for an NAS can easily be added by writing the correct dictionary file for that NAS.
+
+There is no direct connection between the NAS and the dictionary files, as the dictionary files reside only on the server. For example, if names are edited in a local dictionary file, there is no effect on any other NAS or RADIUS server, because these names appear only in the local dictionary file. The RADIUS packets remain in binary format and contain only numbers, not names.
+
+[NOTE]
+====
+Editing attribute names in a local dictionary file does not effect any other NAS or RADIUS server. Only the attribute numbers are encoded and sent in RADIUS packets.
+
+The NAS and server may use different dictionaries, which may cause problems if they are not coordinated (a set of data may be interpreted differently by the NAS and the server, i.e., as a string by the NAS and an IP address by the server)
+====
+
+Since the attribute names are not sent in RADIUS packets, the dictionaries are limited to the local server and to the policy implemented by that server.
+In this respect, NAS implementations are much simpler than server implementations. Each NAS “looks” in the RADIUS packet for what it “understands” and ignores everything else. In contrast, each RADIUS server
+is presented with all of the information from every NAS in the RADIUS deployment. Each RADIUS server must be capable of “understanding” the functionality and configure-ability of every attribute that is
+necessary to authenticate or authorise the users.
+
+== Dictionary File Format
+
+It is very important to use the correct dictionaries. If the wrong dictionaries are used, the server may not properly interpret local configuration, or generate the correct response for the NAS.
+
+If the server does not have access to the correct vendor-specific attributes and dictionaries, it cannot correctly process any VSAs it receives for that vendor.
+
+[NOTE]
+====
+Servers must have access to a vendor dictionary to understand vendor attributes.
+====
+
+Some servers may not contain all the necessary dictionary files because each vendor defines their own dictionaries and release schedule. If a server does not include dictionaries for a particular vendor, contact that vendor, and not the organisation that supplied the RADIUS server.
+
+[#server-attr]
+=== Server-side Attributes
+
+Server-side attributes are attributes that control the server’s behavior. It is frequently necessary to define these server-side attributes, while ensuring that information pertaining to server-side attributes never
+gets sent through the network in a RADIUS message. Server-side attributes should not be included in RADIUS messages, since these attributes are internal to server implementation.
+
+Definitions for server-side attributes may vary by server vendor, or may vary even from one version of the same server to another. Only FreeRADIUS definitions for internal attributes are referenced in this document. Those definitions are generally the same across all versions of the server, but other vendors may have different implementations.
+
+Information such as “use LDAP server X”, or “remember that the user is in group Y” should be used to create local policy. This information should be stored in server-side attributes (also known as “non-protocol attributes”).
+
+Server-side attributes are presented using the same format as standard or vendor RADIUS attributes. This format gives the administrator the same control over internal aspects of the server behavior as over the server external responses. The server-side attribute information can be retrieved as part of one policy and checked later as part of another policy. For example, the policy can say “use LDAP server X for this request” and “respond with attribute X, value Y”.
+
+=== xref:session/processing.adoc[Processing Requests]
+
+The server processes requests through local site policy. That policy is used to examine the request, the request attributes, and the attribute values. The server then builds a reply message using responses (determined by local policy) such as time of day restrictions, group access limitations, and IP address allocation. The processing stage may include keeping track of <<server-attr,server-side attributes>>. FreeRADIUS maintains these attribute lists for every request.
+
+.Attribute Lists and Details
+
+[cols="1,2"]
+|===
+|*Attribute List*|*Description*
+
+|`request`
+|Attributes taken from the received packet.
+
+|`reply`
+|Attributes which will be sent in the reply.
+
+|`control`
+|Attributes used to control how the server operates. These are never sent in a packet.
+
+|`session-state`
+|Attributes which are saved and restored across multiple request / reply exchanges.
+|===
+
+See the xref:unlang:list.adoc[Attribute Lists] reference documentation for more details.
== Introduction
-The FreeRADIUS web site is at https://freeradius.org/, and most
-information referenced in this document can be found there.
+The https://freeradius.org/[FreeRADIUS website] contains most of the
+information referenced in this document.
This document is primarily for non-developers of the FreeRADIUS
server. If you are able to patch the code to work correctly, then
Where the server terminates ungracefully due to a bus error,
segmentation violation, or other memory error, you should create a new
-issue in the issue tracker https://bugs.freeradius.org/, including
+issue in the https://freeradius.org/[issue tracker], including
information from the debugging sections below.
-For any other issues, you should first discuss them on the
+For any other issues, first post and discuss them on the
https://freeradius.org/support/[FreeRADIUS users list], to
see if anyone can reproduce them. Often there’s a simple explanation of
why the server behaves as it does, and it’s not necessarily a bug in the
you should file a bug against our documentation.
For more information about the users list, the lists’ archives and the
-faq, please visit https://www.freeradius.org/list/users.html Please make
-sure to READ and RESPECT the house-rules. You will get much better
+faq, please visit https://www.freeradius.org/list/users.html[FreeRADIUS org]. Please make
+sure to *read* and *respect* the house-rules. You will get much better
response and much faster if you do!
== Core dumps
someone else wrote. You don’t want to do that.
For FreeRADIUS, use doxygen `@`-style comments so you get the
-benefits of the developer documentation site, https://doc.freeradius.org/.
+benefits of the developer documentation https://doc.freeradius.org/[site].
== Give things reasonable names
condition), then they could have produced a descriptive error message
instead of having the program core dump.
-== Core dumps are for weenies
+== Core dumps are *ineffectual*
-If your program core dumps accidentally, you’re a bad programmer. You don’t know
-what your program is doing, or what it’s supposed to be doing when anything goes
-wrong.
+If your program core dumps accidentally, it's an indication of bad or weak programming. You don’t know what your program is doing, or what it’s supposed to be doing when anything goes wrong.
If it hits an `assert()` and calls `abort()`, you’re a genius. You’ve thought
ahead to what _might_ go wrong, and put in an assertion to ensure that it fails
-= FreeRADIUS Dependencies
+= Dependencies
Some external dependencies must be installed before building or
running FreeRADIUS. For version 3, the core depends on one
=== libtalloc
-Talloc is a memory allocation library available at
-https://talloc.samba.org/talloc/doc/html/index.html
+Talloc is a memory allocation library available on the
+https://talloc.samba.org/talloc/doc/html/index.html[Samba] website.
*OSX*
FreeRADIUS is available from multiple sources:
-* Official xref:packages.adoc[Network RADIUS packages]
+* Official xref:packages.adoc[InkBridge Networks] FreeRADIUS packages
* xref:source.adoc[Source code]
* Many Operating System distributions
-== Install from packages
+= Install from packages
Network RADIUS provide pre-built binary packages of FreeRADIUS for
common Linux distributions. This is the recommended installation
method when packages are available for your system.
-The official http://packages.networkradius.com[Network RADIUS
+The official https://packages.inkbridgenetworks.com/[InkBridge Networks
packages] page contains recent FreeRADIUS packages and
installation instructions.
-=== Distribution-supplied packages
+== Distribution-supplied packages
While many Operating System distributions ship FreeRADIUS
packages, the versions they include are often years out of date.
-== Building from Source
+= Building from Source
We recommend xref:packages.adoc[installing from packages] if
possible. Full instructions on building and installing from source
code follow.
-The mandatory xref:installation:dependencies.adoc[dependencies]
+The xref:installation:dependencies.adoc[dependencies]
must be installed before FreeRADIUS can be built. These dependencies
are `libtalloc` and `libkqueue`, which FreeRADIUS uses for memory
management, and platform-independent event handling.
output to figure out which additional development libraries need
to be installed.
+include::xref:ROOT/partial$externaldoc.adoc
+
The FreeRADIUS source may be obtained from a number of locations:
* Download the latest version of the FreeRADIUS source from
sudo make install
----
-=== Custom build
+== Custom build
FreeRADIUS has GNU autoconf support. This means you have to run
`./configure`, and then run `make`. To see which configuration
options are supported, run `./configure --help`, and read its output.
The `make install` stage will install the binaries, the "man" pages,
-and _may_ install the configuration files. If you have not installed a
+and *may* install the configuration files. If you have not installed a
RADIUS server before, then the configuration files for FreeRADIUS will
be installed.
The initial output from running in debugging mode (`radiusd -X`)
will tell you which configuration files are being used. See
-xref:installation:upgrade.adoc[Upgrading] for information about
+xref:installation:upgrade.adoc[Upgrade to v3] for information about
upgrading from older versions. There _may_ be changes in the
dictionary files which are required for a new version of the
software. These files will not be installed over your current
without first carefully reading the output of this process as it
often contains the information needed to resolve a problem.
-== Upgrading To A New Minor Release
+== Upgrade To A New Minor Release
The installation process will not over-write your existing configuration
files. It will, however, warn you about the files it did not install.
versions of the server.
For details on what has changed between the version, see the
-xref:installation:upgrade.adoc[upgrade] guide.
+xref:installation:upgrade.adoc[Upgrade to v3] guide.
-We _strongly_ recommend that new major versions be installed in a
+We *strongly* recommend that new major versions be installed in a
different location than any existing installations. Any local policies
can then be migrated gradually to the configuration format of the new
major version. The number of differences in the new configuration mean
that is is both simpler and safer to migrate your configurations rather
than to try and just get the old configuration to work.
-== Running the server
+== Run the Server
If the server builds and installs, but doesn’t run correctly, then
you should first use debugging mode (`radiusd -X`) to figure out
We really cannot emphasize that last sentence enough. Configuring
a RADIUS server for complex local authentication isn’t a trivial
-task. Your _best_ and _only_ method for debugging it is to read
+task. Your *best* and *only* method for debugging it is to read
the debug messages, where the server will tell you exactly what
it’s doing, and why. You should then compare its behaviour to what
you intended, and edit the configuration files as appropriate.
----
You should see a lot of text printed on the screen as it starts up. If
-you don’t, or if you see error messages, please read the FAQ:
+you don’t, or if you see error messages, please read the https://www.freeradius.org/documentation/freeradius-server/4.0.0/faq.html[FAQ]:
-https://wiki.freeradius.org/guide/FAQ
If the server says `Ready to process requests.`, then it is running
properly. From another shell (or another window), type
carefully, as many configuration options are only documented in comments
in the file.
-Note that is is _highly_ recommended that you use some sort of version
+Note that is is *highly* recommended that you use some sort of version
control system to manage your configuration, such as git or Subversion.
You should then make small changes to the configuration, checking in and
testing as you go. When a config change causes the server to stop
Please read the documentation in the doc/ directory. The comments in the
configuration files also contain a lot of documentation.
-If you have any additional issues, the FAQ is also a good place to
-start.
+If you have any additional issues, the https://www.freeradius.org/documentation/freeradius-server/4.0.0/faq.html[FAQ] or https://www.freeradius.org/documentation/freeradius-server/4.0.0/trouble-shooting/index.html[Troubleshooting] guides are good places to start.
+
-https://wiki.freeradius.org/guide/FAQ
-= Upgrading from v2 to v3
+= Upgrade to v3
-The configuration for 3.0 is *largely* compatible with the 2.x.x
-configuration. However, it is NOT possible to simply use the 2.x.x
+The configuration for version 3 is *largely* compatible with the version 2
+configuration. However, it is NOT possible to simply use the v2
configuration as-is. Instead, you should re-create it.
== Security
modules in that directory will be loaded. This means that the
`instantiate` section of radiusd.conf is less important. The only
reason to list a module in the `instantiate` section is to force
-ordering when the modules are loaded.
+ordering when the modules are loaded.
Modules can be enabled by creating a soft link. For module `foo`, do:
}
}
----
-
-
+
+
=== rlm_unix
The `unix` module does not have an `authenticate` section. So you
Instances of rlm_date register an xlat method which can translate
integer and date values to an arbitrarily formatted date time
-string, or an arbitrarily formated time string to an integer,
+string, or an arbitrarily formated time string to an integer,
depending on the attribute type passed.
=== rlm_rest
-The `rest` module is used to translate RADIUS requests into
+The `rest` module is used to translate RADIUS requests into
RESTfull HTTP requests. Currently supported body types are JSON
and POST.
=== rlm_yubikey
The `yubikey` module can be used to forward yubikey OTP token
-values to a Yubico validation server, or decrypt the token
+values to a Yubico validation server, or decrypt the token
using a PSK.
== Deleted Modules
-
+
The following modules have been deleted, and are no longer supported
in Version 3. If you are using one of these modules, your
configuration can probably be changed to not need it. Otherwise email
the `lua`, `perl` or `python` modules. Those modules allow the insertion of
full-featured scripts at any point in the packet processing.
-NOTE: The documentation is this directory is _reference_
+[NOTE]
+====
+The documentation is this directory is *reference*
documentation. That is, it describes the syntax of `unlang` keywords,
using minimal examples. The reference documentation does not,
-however, describe _when_ to use the keywords, or _how_ to create
-policies. Please see the xref:howto:index.adoc[howto] directory for
-more in-depth "how to" guides.
+however, describe *when* to use the keywords, or *how* to create
+policies. Please see the xref:howto:index.adoc[Howto] section for
+more in-depth "howto" guides.
+====
The documentation is organized so that each item is on its own page.
The page beings with a description of the item, followed by some text
== Update Statements
-xref:update.adoc[update] statements are used to edit attributes and
+xref:update.adoc[Update] statements are used to edit attributes and
lists of attributes.
Most request packets will result in reply packets that contain
projects / thirdparty / freeradius-server.git / commitdiff
