-
Notifications
You must be signed in to change notification settings - Fork 1.1k
/
dictionary
151 lines (144 loc) · 5.46 KB
/
dictionary
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
# -*- text -*-
#
#
# $Id$
#######################################################################
#
# # Local dictionary definitions
#
# This is the local dictionary file which can be
# edited by local administrators. It will be loaded
# *after* the main dictionary files are loaded.
#
#
# NOTE: We recommend using local variables inside of "unlang"
# sections instead of defining attributes in this file. See
# the xref:reference:index.adoc[reference documentation]
# for more information on
# xref:reference:unlang/local.adoc[local variables].
#
#
# This file exists for two purposes:
#
# 1) defining local attributes in order to simplify the process
# of migrating from version 3 to version 4. We recommend
# removing these attributes, and using local variables instead.
#
# 2) Including alias dictionaries in order to simplify the
# process of migrating from version 3 to version 4. We
# recommend using the new names where possible.
#
# ## Dictionary loading order
#
# FreeRADIUS will automatically load the main dictionary files from:
#
# ${prefix}/share/freeradius/dictionary
#
# 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.
#
# ## Dictionaries per Virtual Server
#
# 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.
#
#
# ## Editing the dictionary
#
# 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
#
# ## Example attributes
#
# The attributes below are examples. You should edit them as
# required, or add your own.
#
#DEFINE My-Local-String string
#DEFINE My-Local-IPAddr ipaddr
#DEFINE My-Local-Integer integer
#
# ## v3 Compatible names.
#
# All of the attributes have been renamed from v3. This change was
# necessary in order to support new functionality in v4. The
# unfortunate side effect of this change is that all of the names in
# SQL, LDAP, and the "files" module are incompatible with v4.
#
# We recognize that is is difficult to change every entry in a
# database, especially when there's no clear mapping between the
# "old" and "new" names. This renaming is made more complex because
# the "new" names need to be grouped and arranged in ways that the
# old ones were not.
#
# The "old" names were all in flat lists, so that User-Name appeared
# next to Cisco-AVPAir. This organization was simple enough to work
# for 20 years, but its time has come. The new names are
# hierarchical, so that the organization is nested by definition.
#
# For v4, the Cisco-AVPair attribute is called "AVPair", and it lives
# inside of the "Cisco" namespace, which in turn lives inside of the
# "Vendor-Specific" namespace. So the new name for Cisco-AVPair is
# Vendor-Specific.Cisco.AVPair.
#
# This process continues for many thousands of vendor-specific
# attributes.
#
# Happily, it is possible to (mostly) use the old names with v4.
# There are limitations, but it will mostly work. The main reason
# for enabling the old names is to try out v4 with a database that is
# also used by v3. This lets you test that v4 works, without going
# through a complex "upgrade everything" process.
#
# The old v3 names are in "alias" dictionaries, in the `${dictdir}`
# directory. To find out where this directory is on your local
# system, run "radiusd -h" or "radclient -h". Then look for the "-D"
# command-line option, and it will tell you where the dictionary
# files are located.
#
# The v3 names are in `${dictdir}/radius/alias/VENDOR.txt` where
# _VENDOR_ is the name of the vendor, which is taken from the `VENDOR`
# definition in the v3 dictionaries.
#
# You will need to add a `$INCLUDE` line for each vendor-specific
# dictionary which is used by your local system. The default v4
# dictionaries do not enable all of v3 compatibility names.
#
# Yes, we recognize that this process is a bit of work. However, we
# wish to encourage everyone using v4 to upgrade to using the new v4
# features. Our experience shows that if we automatically enable
# "compatibility functions", then those 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.
#
#
# All of the v3 compatibility names are in the RADIUS namespace.
#
#BEGIN-PROTOCOL RADIUS
#$INCLUDE ${dictdir}/radius/alias/cisco.txt
#END-PROTOCOL RADIUS