Radiator only knows how to deal with attribute/value pairs as defined in the
dictionary that is in use. In your example above, "Xstring" is not defined
in
your dictionary, so there is no match.
>>I already have the Xstring attributed added to the default dictionary
file.
>>It looks like this:
>>
>>ATTRIBUTE Xstring 3660 string
>>
You will have to find an attribute in the incoming request that indicates
what
you are looking for (for example, Service-Type, or NAS-Port-Type) then set
your
LDAP attribute to match on the same value (for example, "Framed-User" for
Sevice-Type, or "async" for NAS-Port-Type).
>>I think I understand then....in other words, I'm limited in what I can use
as my attributes
>>by what the Cisco sends to Radiator during the Access-Request?
>>So if I steal an attribute, then map the actual LDAP attribute to it with
the AuthAttrDef statement, it should work...
>>Am I on the right track?
>>
Alternatively you may be able to write a hook to do what you require.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.starport.net/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
