users man page on BSDi

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDi logo
[printable version]



USERS(5)						 USERS(5)

NAME
       users  -	 Merit AAA server user security and configuration
       file

SYNOPSIS
       ../raddb/users

DESCRIPTION
       The users file resides in the Merit AAA server  configura-
       tion directory (named .../raddb somewhere).  It contains a
       list of users on which the Merit AAA server  will  perform
       authentication.	 Comments  are indicated by leading pound
       sign ('#') characters.  All such comment lines are ignored
       (as are blank lines).

       The  file  contains  one	 or more lines of information for
       each such user.	The first line of each entry consists  of
       one or more fields:

	      <users-name>  <check-item>  [, <check-item>]  ...

       For example:

	      george   Password = "foobar"

       There  are  four	 special  user	names, DEFAULT, dumbuser,
       pppuser and slipuser, which are used  1)	 as  the  default
       entry  for  user	 names	which  do  not match any previous
       entries, 2) to hold non-framed reply-items, 3) to hold PPP
       reply-items,  and  4)  to  hold	SLIP reply-items, respec-
       tively.	The latter three entries allow a user to  authen-
       ticate with the same account name for any of the framed or
       non-framed protocols.  The  DEFAULT  entry  specifies  how
       user  names, not explicitly matched above it in this file,
       are to be authenticated.

       Additional lines associated with the first line	described
       above,  but  beginning with leading whitespace, follow the
       first line and indicate the (Attribute/Value Pairs)  reply
       items to be passed back to the requesting RADIUS client or
       server.	These may include things like  PPP  configuration
       values,	the  name of the host to which the user wishes to
       connect	 or   an    optional	packet	  filter    name.
       Attribute/Value	Pair names must be defined in the dictio-
       nary file.

       These additional lines consist of one or more fields:

	      <whitespace>  <reply-item>,  [<reply-item>,]  ...

       For example:

	      <TAB>   Framed-Protocol = PPP,

			 9 December 1997			1

USERS(5)						 USERS(5)

       Note that the first line (of check-items) for  each  entry
       does NOT end with a comma (',') character while the reply-
       item lines of each entry begin with a TAB or space charac-
       ter  and	 end with a comma character, except for the final
       reply-item of each entry, which omits the trailing  comma.

       There  are  two	types of check-items: regular check-items
       and deny-items.	A deny-item is a regular attribute (iden-
       tical  in all respects to a check-item except that instead
       of using an equals ("=") character, you may  specify  not-
       equals  by  using the two character ("!=") sequence).  The
       deny-items are used to reverse the sense of the	authenti-
       cation-time  check  from	 "must	match"	this attribute to
       "must not match" this attribute.	 In other words, a  deny-
       item causes an Access-Request to be rejected if it matches
       an attribute in the request.  You  may  also  configure	a
       denial  message	as a deny-item (all on the first line) as
       follows:

	      Deny-Message = "Access to this port is not allowed"

       This  string  would be returned to the user in the Access-
       Reject as a Reply-Message if any deny-item for  this  user
       caused  a  rejection.  You may also use the special string
       ("*") consisting of just the asterisk  character	 as  fol-
       lows:

	      Deny-Message = "*"

       This  provides a canned message indicating which deny-item
       triggered the rejection:

	      "Access denied, <attribute> = <value>"

       Vendor specific	attributes  may	 be  specified	as  <ven-
       dor>:<attribute>	 in place of normal check-item and reply-
       item attributes, for example:

	      Ascend:Ascend-Metric

       The users file is optionally read into internal tables  by
       radiusd	at  startup and whenever a HUP signal is received
       by radiusd.  The Merit AAA server detects any  out-of-date
       configuration  files  upon  receipt of a Status-Server (or
       Management-Poll) request and re-reads all  the  configura-
       tion files.  The users file may be converted into a dbm(3)
       database by using the builddbm(8) utility.  This	 file  is
       maintained  by  the system administrator using a text edi-
       tor.

FILES
       ../raddb/dictionary the	file  describing   the	 possible
			   Attribute/Value Pairs.
       ../raddb/users	   this file.

			 9 December 1997			2

USERS(5)						 USERS(5)

SEE ALSO
       dbm(3), signal(3), dictionary(5), builddbm(8), radiusd(8),
       radcheck(8), radpwtst(8)

			 9 December 1997			3

[top]

List of man pages available for BSDi

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net