Local dictionary definitions

FreeRADIUS will automatically load the main dictionary files from:

It is no longer necessary for this file to $INCLUDE the main dictionaries from this file. However, if the $INCLUDE line is here, nothing bad will happen.

v4 also supports a dictionary { …​ } subsection in a virtual server. If the attributes are used only in one virtual server, they should be defined there.

Any new/changed attributes must be placed in this file. The pre-defined dictionaries should not be edited. See man dictionary for documentation on how dictionary entries should be formatted.

All local attributes and $INCLUDE directives should go into this files.

The attribute definitions here should use DEFINE, not ATTRIBUTE. The DEFINE keyword is exactly like ATTRIBUTE, except it does not require an attribute number.

As a result, there is no need to manually manage numbers.

Any attribute `DEFINE`d here will not go into a packet.

If you do want attributes to go into a RADIUS packet, you will need to use VSAs. This means requesting allocation of a Private Enterprise Code from https://www.iana.org/. We strongly suggest doing that only if you are a vendor of RADIUS equipment.

See RFC 6158 for more details: http://ietf.org/rfc/rfc6158.txt

The attributes below are examples. You should edit them as required, or add your own.

By default, the server does NOT load the v3 names. While this behavior is done to simplify the server configuration, it can also make migration more difficult.

If your system is using Vendor-Specific attributes from a particular vendor, you can list those dictionaries below. The server will then load the version 3 names, which makes migration much simpler.

For v4, all of the attributes have been renamed from v3. This change was necessary in order to support new functionality. The unfortunate side effect of this change is that all of the names used by v3 in tje SQL, LDAP, and "files" module are incompatible with v4.

The problem with v3 was that names were all in flat lists, so that User-Name appeared in the same to Cisco-AVPAir. This organization was simple enough to work for 25 years, but its time has come. The new names are hierarchical, which means they are organized into a tree-like structure.

For v4, the Cisco-AVPair attribute is now called "AVPair". It lives inside of the "Cisco" namespace, which in turn lives inside of the "Vendor-Specific" namespace. So the new name for Cisco-AVPair is Vendor-Specific.Cisco.AVPair.

These changes have been made for many hundreds of dictionary files, and many thousands of Vendor-Specific attributes.

In the interest of compatibility, is possible to use the old names with v4. There are limitations, but it will generally work. The main reason for enabling the old names is to try out v4 with a database that is also used by v3. This lets you test that v4 works, without going through a complex "upgrade everything" process.

The old v3 names are in "alias" dictionaries, in the ${dictdir} directory. To find out where this directory is on your local system, run "radiusd -h" or "radclient -h". Then look for the "-D" command-line option, and it will tell you where the dictionary files are located.

The v3 names are in ${dictdir}/radius/alias/VENDOR.txt where VENDOR is the name taken from the v3 dictionary.VENDOR.

You will need to edit the text below to add a $INCLUDE line for each vendor-specific dictionary which is used by your local system. The default v4 dictionaries do not enable all of v3 compatibility names.

We recognize that this process is a bit of work. However, we wish to encourage everyone using v4 to upgrade to using the new v4 features. Our experience shows that if we automatically enable "compatibility functions", then those compatibility functions will be used for a decade. So we need to find a balance between upgrades and ongoing support. Easy upgrades will mean complex ongoing support. Complex upgrades make ongoing support easier, but also make it less likely that people will upgrade.

Note that if you over-write the "v3/dictionary.VENDOR" files with a copy of the v3 dictionary, then it won’t work. Migrations across major version numbers means that the configuration files are not 100% compatible. This includes the dictionaries!

The v3 compatibility names are in the RADIUS namespace. There are no aliases for DHCPv4.

This dictionary includes v3-compatible names like "Cleartext-Password", or "NT-Password".