Specifying Attribute-Value Pairs

Attribute names and their enumerated value names are defined in the dictionary file. When specifying attribute values in configuration files, you must have a space before the equals (=) or not equal (!=) operator. A list of A-V pairs may be delimited by commas, white space, or both.

Attribute-Value Formats

The attribute values (to the right of the equal sign) may take on any of the supported, legal values described in the dictionary file. The attributes and their corresponding values are defined to be one of the following types: IP address, string, vendor, tag string, tag integer, date, integer, string, octet, and short values.

The string values must be surrounded by the double quote ('"') character if they contain spaces; otherwise, the quotation marks are optional. These values are limited to a maximum of 253 characters.
LDAP policy and decision files cannot handle tag string and tag integer values
The IP address values may use the common dotted-quad notation.
The date values follow the format of three character month abbreviation (e.g., Jan, Feb, Mar, etc.), followed by the day, followed the year expressed as four digits (e.g., 1998). Each field must be delimited by a space or hyphen (e.g., Jan 8 2002, Jan-21-2002, etc.)
A-V pair lists must be delimited by white space. For readability you may use both a comma and white space as a delimiter.

Examples

The following examples are syntactically valid A-V pair lists:

Password = "rock", Service-Type = "Framed", Comment = "This is OK"
Password =rock Service-Type =Framed Comment ="This is OK"

The following examples are not syntactically valid A-V pair lists, with errors in italic:

Password="rock"Service-Type="Framed"Comment="This is not OK"
Password= rock Service-Type= Framed Comment= This is not OK

Tagged Attributes

A RADIUS message may include multiple values for one or more attributes that are tagged to organize the attributes into defined groups. Depending on its capabilities, a client or server may selectively use one set of tagged attributes. For example, an Access-Accept may contain several different tunnel definitions. If it supports tagged attributes, the client may select which definition to use. Tagged attributes may be used as check or reply items.

Tagged attributes follow the syntax:

Attribute=:Tag:Value
Attribute The attribute to tag.
Tag A unique integer (less than 32) that identifies what set this attribute belongs to.
Value The attribute value.

For example, Tunnel-Type =:1:PPTP indicates an attribute value of PPTP that belongs to a larger set of attributes, all tagged with 1, that collectively define one type of tunnel that might be established for a user.




	IMPORTANT: Some NASs do not support tagged attributes. It is recommended that when you return multiple tunnel definitions to a client, you should have at least one set of attributes that is untagged or tagged with a 0 value, so that there is a tunnel definition available to a client that does not support tags.

Specifying Attribute-Value Pairs

Technical documentation

» Table of Contents

» Glossary

» Index

Attribute-Value Formats

Examples

Tagged Attributes