Hello,
https://networkradius.com/doc/3.0.10/concepts/dictionary/creating_server_att...
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
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@lists.freeradius.org> De la part de Alexey Dotsenko Envoyé : mardi 28 mai 2019 13:11 À : freeradius-users@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: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html