ServerSide Attributes

Nicolas Breuer Nicolas.Breuer at belcenter.biz
Tue May 28 13:25:08 CEST 2019


Hi,

Indeed i have this message : This attribute MUST go on the first line with
 So the best is to attribute an index of 3000 and ignore the message at Startup. The attribute is only needed for assigning the user in the correct group.
Indeed the attribute is not intended to be sent to the NAS.

I found an other way put an index of 999 but after reading your mail, I think I will ignore the startup error and set a number of "3000"
As it's intended 😊



-----Message d'origine-----
De : Freeradius-Users <freeradius-users-bounces+nicolas.breuer=belcenter.biz at lists.freeradius.org> De la part de Alexey Dotsenko
Envoyé : mardi 28 mai 2019 13:11
À : freeradius-users at lists.freeradius.org
Objet : Re: ServerSide Attributes

Hello,

I suppose you see a message like the following:
Warning: [/etc/raddb/users]:1 Check item "My-Attr" found in reply item 
list for user "DEFAULT". This attribute MUST go on the first line with 
the other check items

This means (according to the comment in the dictionary file):
1) local attribute is supposed to be used as check (control) attribute. 
These attributes are specified in the first line of the user-item in the 
users file:
DEFAULT Hint == "SLIP"
         Framed-Protocol = SLIP

In this example, Hints - is a check item (attribute), and 
Framed-Protocol - is a reply item (attribute). If you see a warning at 
startup, it means that you used the local attribute in the replay 
context (where the Framed-Protocol in example), whereas its use is 
assumed in the check context (where the Hint in example).

2) In your case, this only works until a certain point: local attributes 
in the replay context will be processed by the server like any other, 
but will not be transferred to the client. A warning on the startup says 
about this - "why use local attributes in a replay context if you are 
not going to send them to the client? Use check context for this - it is 
for this purpose intended."

3) In general, this is not a error. If you have a very large array of 
local attributes, it is very inconvenient to use them in the context of 
a check - a very long string is obtained. In this case it is easier to 
use them in the context of a replay - it allows multi-line definition. 
But it is better to use other modules, such as ldap or sql - they do not 
have a similar problem.

On 28.05.2019 11:11, Nicolas Breuer wrote:
> Hello,
> 
> https://networkradius.com/doc/3.0.10/concepts/dictionary/creating_server_attributes.html
> 
> Following the documentation, we can create server-side attributes with
> number range 3000-4000.
> If I create a new attribute , I have a warning on the startup that I
> can't use that on a reply attribute in the user file but it's working.
> 
> Can you advise what we can do ?
> 
> Thanks
> 
> 
> 
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



More information about the Freeradius-Users mailing list