This optional parameter allows you to use additional ADSI user
information as RADIUS check or reply items. This is most useful when you
define new user attributes in your Active Directory schema. It is beyond
the scope of this document to describe how to add new attributes to an
Active Directory schema.
The general format is
AuthAttrDef adsiname,radiusattr,type
adsiname is the name of an attribute in your
Active Directory User schema. The value of that attribute will be
fetched using ADSI during authentication.radiusattr is the name of the RADIUS
attribute that the adsiname will be converted to. check or reply item.
The special radiusattr ‘GENERIC’ indicates that it is a list of comma
separated attribute=value pairs, similar to ReplyAttr or
CheckAttr.type specifies whether to use the value as a
check or reply item. type may be check, reply or request. If type is
“request” the value is saved in the current request, from where it can
be later collected with a special formatting macro like:
%{attributename}.
For example,
AuthAttrDef address,Framed-IP-Address,reply
would
get an attribute called ’address’ from the ADSI user record, and put it
into Framed-IP-Address attribute in the RADIUS reply. If address was not
defined in your schema, or there was no value defined for the user being
authenticated, then Framed-IPAddress would not be set in the
reply.
Multi-valued AD attributes can be used as check items, which
results in Radiator passing the authentication if one of the multiple
items matches. For example if you have this in your AuthBy
ADSI:
AuthAttrDef otherHomePhone,Calling-Station-Id,check
and
multiple entries in Home, ‘Other....’ tab of the Telephones tab. Then
Radiator will let the user log in if they call from any one of the Other
Home Phone numbers.
