Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
USERS(5)	      FreeRADIUS user authorization file	      USERS(5)

NAME
       users - user authorization file for the FreeRADIUS server

DESCRIPTION
       The  users files	reside in the files module configuration directory, by
       default	/usr/local/share/examples/freeradius/raddb/mods-config/files/.
       It  contains a series of	configuration directives which are used	by the
       files module to decide how to authorize and authenticate	each user  re-
       quest.

       Every  line  starting  with a hash sign ('#') is	treated	as comment and
       ignored.

       Each entry of the file begins with a username, followed by a  (possibly
       empty) list of check items, all on one line.  The next line begins with
       a tab, and a (possibly empty) list of reply items.  Each	 item  in  the
       check  or  reply	 item  list  is	an attribute of	the form name =	value.
       Multiple	items may be placed on one line, in which case	they  must  be
       separated  by  commas.	The reply items	may be specified over multiple
       lines, in which case each line must end with a comma, and the last line
       of the reply items must not end with a comma.

       The check items are a list of attributes	used to	match the incoming re-
       quest.  If the username matches,	AND all	of the check items  match  the
       incoming	 request,  then	 the  reply items are added to the list	of at-
       tributes	which will be used in the reply	to that	request.  This process
       is repeated for all of the entries in the users file.

       If the incoming request matches NO entry, then the request is rejected.

CAVEATS
       The special keyword DEFAULT matches any usernames.

       The  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 re-
       ply  attribute,	then the processing of the file	stops, and no more en-
       tries are matched.  Any reply item list without any Fall-Through	attri-
       bute is treated as though it included a Fall-Through = No attribute.

       If an entry contains the	special	item Fall-Through = Yes	as a reply at-
       tribute,	then the processing proceeds to	the next entry in order.

       Care should be taken when using Fall-Through.   The  server  should  be
       tested  in  debugging  mode with	a number of test requests, in order to
       verify that the configured entries behave as expected.

       The special attribute Auth-Type is used to identify the	authentication
       type  to	 be used for that user.	 See the dictionary file for a 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.

OPERATORS
       Additional operators other than = may be	used for the attributes	in ei-
       ther the	check item, or reply item list.	 The following is  a  list  of
       operators, and their meaning.

       Attribute = Value
	    Not	allowed	as a check item	for RADIUS protocol attributes.	 It is
	    allowed for	server configuration attributes	(Auth-Type, etc),  and
	    sets  the value of on attribute, only if there is no other item of
	    the	same attribute.
	    As a reply item, it	means "add the item to	the  reply  list,  but
	    only if there is 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 list of configuration items.
	    As a reply item, it	has an identical meaning, but the attribute is
	    added to the reply items.

       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  at-
	    tribute, 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
       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.

       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 at-
	      tributes in the reply.

	      That is, give the	user what they ask for.	 This entry also shows
	      how to specify multiple reply items.

       See  the	users file supplied with the server for	more examples and com-
       ments.

HINTS
       Run the server in debugging mode	(-X), and use the radclient program to
       send  it	test packets which 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.

       Care should be taken when writing entries for the users	file.	It  is
       easy  to	misconfigure the server	so that	requests are accepted when you
       wish to reject them.  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.

FILES
       /usr/local/share/examples/freeradius/raddb/mods-config/files/

SEE ALSO
       radclient(1), radiusd(8), dictionary(5),

AUTHOR
       The FreeRADIUS team.

				  04 Jan 2004			      USERS(5)

NAME | DESCRIPTION | CAVEATS | OPERATORS | EXAMPLES | HINTS | FILES | SEE ALSO | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=users&sektion=5&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help