Creating a dictionary is sometimes necessary, as in these two common situations: defining new vendor-specific attributes and defining site-local server-side attributes. These two situations are sufficiently different from each other that they will be discussed separately.
One additional case, both noted here and dismissed, is when the local administrator wishes to return extra information to the NAS in a RADIUS packet. This desire, though noble, is doomed to fail. Even if the server were configured to send those attributes back in a packet, the NAS would not understand them. This limitation is due to the way RADIUS is designed and to fact that the NAS does not have access to the dictionary files that were edited on the server. The NAS therefore has no way of knowing what to do with those attributes when it receives them, or even what kind of data they carry. The only thing an NAS can do with those attributes is to ignore them.
|Sending additional attributes to the NAS is useful only if the NAS documentation says it understands those attributes.|
It is recommended that the dictionary files distributed with FreeRADIUS not be edited. Those dictionaries are meant to be updated with every new release of the server, and new releases may over-ride any local changes.
In all cases, instead of creating new dictionaries, it is
recommended that the main
dictionary file in the
raddb directory be
changed instead. It is intended to contain site-local changes and will
not be over-written on any server upgrade.