USERS(5)

💅 USERS(5) — the FreeRADIUS user authorization file, bestie edition

okay so this page? it's USERS(5), the user authorization file for the FreeRADIUS server, from the FreeRADIUS user authorization file manual. buckle up, it's actually cute once you get it 💖

---

✨ NAME ✨

users — the user authorization file for the FreeRADIUS server. that's it, that's the name, slay.

---

🌸 DESCRIPTION 🌸

okay so the users files live in the files module configuration directory, which defaults to /etc/raddb/mods-config/files/. it's a whole series of configuration directives, and the files module reads them to decide how to authorize and authenticate each user request. main character file energy, honestly 👑

every line that starts with a hash sign (#) is a comment and gets ignored. no notes, we love a clean comment.

each entry in the file starts with a username, followed by a (possibly empty) list of check items — all on one line. the next line starts with a tab, and holds a (possibly empty) list of reply items. every item in the check or reply item list is an attribute shaped like name = value. you can stack multiple items on one line, but then they must be separated by commas. the reply items can also spread over multiple lines — in that case each line must end with a comma, and the last line of reply items must not end with a comma. (the way the comma rules flip at the end is so real, don't @ me 🎀)

the check items are a list of attributes used to match the incoming request. if the username matches AND all the check items match the incoming request, then the reply items get added to the list of attributes that'll be used in the reply to that request. and this whole process repeats for all the entries in the users file. every single one. 🦋

if the incoming request matches NO entry, then the request is rejected. yeah. it's giving strict. 💀

---

⚠️ CAVEATS ⚠️

the special keyword DEFAULT matches any usernames. iconic, universal, no gatekeeping.

entries are processed in order, from the top of the users file on down. if an entry contains the special item Fall-Through = No as a reply attribute, then processing of the file stops and no more entries are matched. and heads up: any reply item list without any Fall-Through attribute is treated as though it included a Fall-Through = No attribute. sneaky default, i know 😭

if an entry contains the special item Fall-Through = Yes as a reply attribute, then processing proceeds to the next entry in order. carry on, bestie ✨

be so careful when using Fall-Through. you should test the server in debugging mode with a number of test requests, to verify that the configured entries behave as expected. this is not a drill, fr fr.

the special attribute Auth-Type is used to identify the authentication type to be used for that user. check the dictionary file for the list of permitted values for the Auth-Type attribute. 👑

once the users file has been processed, the request is authenticated using the method given by Auth-Type. periodt.

---

🎀 OPERATORS 🎀

so, the = operator isn't the only one — you can use additional operators for the attributes in either the check item list or the reply item list. here's the full list and what each one means. no skipping, we're doing all of them 💅

• Attribute = Value — not allowed as a check item for RADIUS protocol attributes. it is allowed for server configuration attributes (Auth-Type, etc), and it sets the value of an attribute only if there's no other item of the same attribute. as a reply item, it means "add the item to the reply list, but only if there's no other item of the same attribute."
• Attribute := Value — always matches as a check item, and replaces in the configuration items any attribute of the same name. if no attribute of that name appears in the request, then this attribute is added. as a reply item, it has an identical meaning, but for the reply items instead of the request items.
• Attribute == Value — as a check item, it matches if the named attribute is present in the request AND has the given value. not allowed as a reply item.
• Attribute += Value — always matches as a check item, and adds the current attribute with value to the tail of the list of configuration items. as a reply item, it has an identical meaning, but the attribute is added to the tail of the reply items list.
• Attribute ^= Value — always matches as a check item, and adds the current attribute with value to the head of the list of configuration items. as a reply item, it has an identical meaning, but the attribute is added to the head of the reply items list.
• Attribute != Value — as a check item, matches if the given attribute is in the request AND does not have the given value. not allowed as a reply item.
• Attribute > Value — as a check item, it matches if the request contains an attribute with a value greater than the one given. not allowed as a reply item.
• Attribute >= Value — as a check item, it matches if the request contains an attribute with a value greater than, or equal to the one given. not allowed as a reply item.
• Attribute < Value — as a check item, it matches if the request contains an attribute with a value less than the one given. not allowed as a reply item.
• Attribute <= Value — as a check item, it matches if the request contains an attribute with a value less than, or equal to the one given. not allowed as a reply item.
• Attribute =* Value — as a check item, it matches if the request contains the named attribute, no matter what the value is. not allowed as a reply item.
• Attribute !* Value — as a check item, it matches if the request does not contain the named attribute, no matter what the value is. not allowed as a reply item.

---

🦋 EXAMPLES 🦋

okay, example time, these slap:

bob  Cleartext-Password := "hello"

requests containing the User-Name attribute with value "bob" will be authenticated using the "known good" password "hello". there are no reply items, so the reply will be empty. simple, clean, no crumbs.

DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
     Service-Type = Framed-User,
     Framed-Protocol = PPP,
     Fall-Through = Yes

if the request packet contains the attributes Service-Type and Framed-Protocol with the given values, then include those attributes in the reply. that is, give the user what they ask for. this entry also shows how to specify multiple reply items. we love a generous queen 🌈

see the users file supplied with the server for more examples and comments — there's lore in there, go read it.

---

💡 HINTS 💡

run the server in debugging mode (-X), and use the radclient program to send it test packets that you think will match specific entries. the server will print out which entries were matched for that request, so you can verify your expectations. this should be the FIRST thing you do if you suspect problems with the file. literally first. before anything else. 🔥

care should be taken when writing entries for the users file. it's easy to misconfigure the server so that requests are accepted when you wish to reject them. yikes. the entries should be ordered, and the Fall-Through item should be used ONLY where it is required.

entries rejecting certain requests should go at the top of the file, and should not have a Fall-Through item in their reply items. entries for specific users, who do not have a Fall-Through item, should come next. any DEFAULT entries should usually come last, except as fall-through entries that set reply attributes. order is everything, bestie 🫶

---

📁 FILES 📁

• /etc/raddb/mods-config/files/

---

👀 SEE ALSO 👀

radclient(1), radiusd(8), dictionary(5), — go read those too, iykyk 💜

---

🌟 AUTHOR 🌟

The FreeRADIUS team. legends, honestly 👑

---

and that's the whole page, bestie — this one's from 04 Jan 2004, part of the FreeRADIUS user authorization file docs. go forth and configure responsibly 💖✨🎀