Provided by: yardradius_1.1.2-4_amd64 bug

NAME

       radiusd - Yet Another Radius Daemon (YARD RADIUS)

SYNOPSIS

       radiusd  [ -AbchoPsvxz ] [ -a acct_dir ] [ -d db_dir ] [ -f alt_passwd_file ] [ -i ip_addr
       ] [ -l log_file ] [ -p udp_port ] [ -q max_outstanding_reqs ] [ -t max_queue_secs ]  [  -w
       max_proxy_secs ]

DESCRIPTION

       YARD  radiusd  is a program that provides authorization and accounting services for remote
       hosts, based on RADIUS protocols.  RADIUS protocols are defined in a pair of RFC documents
       and  currently  used  by  the  majority  of network access servers and routers in order to
       manage incoming dialup connections.  Open source  products  of  RADIUS  clients  are  also
       available for general use on *nix hosts.

       YARD  RADIUS  daemon  is  largerly based on the original Livingston Inc. RADIUS 2.1 daemon
       (currently known as Lucent Inc. Remote Access RADIUS server 2.1 - Livingston Inc.  is  now
       disappeared...).   It enhances the original code with a number of useful features, such as
       control  of  simultaneous  logins,  support  of  many   non   standard   vendor   clients,
       autoconfiguration  capabilities,  PAM  services,  MD5  passwords,  etc.  All them are very
       useful in real world area of application (e.g. ISPs).  A complete and up-to-date  list  of
       extensions  currently  present  in  YARD  RADIUS is available in the Changelog file, which
       should be enclosed in sources.

       The daemon listens to a couple of non privileged UDP ports (1645 and 1646) and possibly to
       other  two ones (1815 and 1816), when proxy is enabled.  Those ports could also be changed
       at run-time, but you are not encouraged to do this. If your authorization information  are
       available  either  as a separate passwd file or self-contained in users file (i.e. in some
       form independent from system passwd file, see below)  you  could  run  radiusd  as  a  non
       privileged users.

       All configuration files of YARD RADIUS are contained under /usr/confdirectory if not spe

OPTIONS

       -a acct_dir
              Sets  the  accounting  directory  instead  of  the builtin default.  The default is
              choosen at configuration time and it is generally /usr/logs

       -A     Enable accounting via PAM. See below.

       -b     Uses GDBM for the users file ( users.db ) instead of the plain text version ( users
              )  This  improve  performances  of  users  file  checking for authentication.  It's
              strongly suggested. But it's not completely equivalent to plain text, because  GDBM
              files  are  strictly  unsorted. This could be ok or not, it depens on your specific
              choices of attributes.  You need to run builddbm to convert the plain users file in
              the  GDBM  indexed file and this needs to be done every time you changes users file
              contents.

       -c     Clears user  stats  database.  This  should  be  done  to  solve  troubles  due  to
              unsynchonized status among the servers and one or more of its clients. Mabye, after
              a cold-reboot of an access server.

       -d db_dir
              Sets the database directory instead of the builtin default  one.   The  default  is
              choosen at configuration time and it is generally /usr/logs.

       -h     Prints out usage of the command.

       -f alt_passwd_file
              Sets  an  alternate  password  file name to use instead of the system password file
              /etc/passwd.

       -i ip_addr
              Sets an alternate IP for the server host, instead of  the  default  one.   This  is
              useful  if  the  host  on  which the daemon is runnig has multiple interfaces or ip
              aliases.

       -l log_file
              Sets a logging text file, to use instead of syslog.

       -o     Accept all-zero accounting requests authenticator.  A damned thing to use with some
              old  non-RFC  compliant  clients.   Use  this if you see this kind of errors in the
              logging file, only.

       -p udp_port
              Set an alternate radius port number.  Default ports should be (optionally)  defined
              in /etc/services as follows:

              Name            Port
              ─────────────────────────
              radius          1645/udp
              radacct         1646/udp
              radius-proxy    1815/udp
              radacct-proxy   1816/udp

              If they are not in that file, the above ones are used.  If you specify the port `n'
              as the argument of -p option, then radiusd tries to use the following ports:

              Name            Port
              ────────────────────────
              radius          n/udp
              radacct         n+1/udp
              radius-proxy    n+5/udp
              radacct-proxy   n+6/udp

       -P     Enable authorization via PAM. See below.

       -q max_outstanding_reqs
              Sets the incoming packets queue size. 100 is the default.

       -s     Forks another process for accounting.  This is  not  generally  suggested,  due  to
              dependencies among auth and acct modules in YARD radiusd .

       -t max_queue_secs
              Set time out for requests queue.

       -v     Print  version. It shows also enabled features. Version number should be a group of
              three point-separated numbers, such as major.minor.patch where meaning of the three
              values  should be obvious. It's not easy to define a `major' advancement in respect
              of a `minor' one. Anyway, any minor/major number should correspond to  a  different
              branch in the CVS repository. This is not true for a patching release.

       -w  max_proxy_secs
              Set time out for proxy requests.

       -x     Set debug mode on. It increases verbosity level.

       -z     The same of -b -x -d . -a ra.  This is intended for debugging.

FILES

       radiusd requires a group of configuration files under /usr/conf in order to properly work.
       Examples of those working files are provided with sources and should be present under  the
       same  directory,  with  extension .example.  All files are well commented and it should be
       easy to customize them.  The work files are the following ones:

       /usr/conf/users
              This file contains  the  human  readable  information  for  users'  accounting  and
              authorization. See radius_attributes(5) for details about its syntax.

       /usr/conf/users.db
              The same of the previous one as compiled in by builddbm in GDBM format. It needs to
              be compiled again every time you make changes  to  the  previous  one  and  without
              restarting radiusd .

       /usr/conf/dictionary
              This  read-only  file contains the codes and formats for standard and vendor RADIUS
              protocol attributes and values along with their human readable  representation.  It
              is  subject  to  change, due to new access server supports. It is a plain text file
              with a pletora of comments in it.

       /usr/conf/clients
              It contains names or ip addresses of remote clients authorized to  use  the  server
              for  authentication  and  accounting, along with their passwords in clear text.  So
              this file should be protected with mode 600.

       /usr/conf/clcache
              The same of the previous file as cached in GDBM format for fast  access  at  daemon
              startup. With the same recommendations for file access modes.

       /usr/conf/proxy
              This file is used to collect proxy hosts and their associated realms and passwords.
              It contains  a list of remote servers to forward to authentication  and  accounting
              requests.

              Every  line refers to a different proxy server: the first field is a valid hostname
              or ip address; the second field  (seperated  by  blanks  or  tabs)  is  the  shared
              secret);  the  third field is the named or numeric authentication realm; the fourth
              field can contain the optional RADIUS UDP Port number of  the  remote  server,  the
              RADIUS and RADIUS Accounting Port numbers, and any of following optional keywords:

              old      Strip  realm and do not attach Proxy-State
                       when forwarding
              secure   Allow remote  server  to  authorize  admin
                       logins for your client
              ipass    Use the ipass protocol

              The realm string must follow an `@' sign after the username to identify the correct
              proxy server.

       /usr/conf/allowuser
              You can list here (one per line) usernames/groupnames who are  granted  for  having
              access  (if  their  password  are  correct).   Each  entry  must respect one of the
              following syntaxes:

              USER:    <username>
              GROUP:   <groupname>
              GECOS:   <string>
              SHELL:   <string>

              so you can match users  by  usernames,  groupnames,  gcos  substrings  (i.e.  case-
              sensitive  sub-strings  in  the  fifth  field of the system /etc/passwd file or the
              alternate password file), or shell paths. You can use the special string `ANY' as a
              matching argument too (e.g. `USER: ANY'). An empty or missing file grants access to
              anyone which is not listed in the next file.

       /usr/conf/denyuser
              The same syntax of allowuser can be used to deny  access  to  specific  classes  of
              users,  with  the  same previous matching criteria. An empty or missing file grants
              access to anyone which is listed in the previous file or not.

       Note that all users have always to match their  password  with  the  authorization  module
       selected  in  their `users' file entry, after the above files allowed to login. You cannot
       use these files to grant access without any other additional authentication.

       /usr/conf/stopuser
              This text file is created by  radwatch  to  deny  access  to  users,  when  certain
              conditions  are  reached  (as  selected  in  the  radwatch configuration file). The
              authentication daemon radiusd consults that file along with `denyuser' in order  to
              grant  access  or not.  It has an entry per line, which should be a valid system or
              `users' username.

       /usr/conf/radwatch.conf
              This is the configuration file for radwatch.  It is a text files each line of which
              is  of  the  form:  user_list:restriction:time_list  where  `user_list' is a comma-
              separated list of usernames for which this line apply. You can use @group syntax to
              denote  the  standard  UNIX  user  groups.  The field `restriction' is the value in
              seconds of the maximum permitted online time within the `time_list'.  This  one  is
              the  third colon separated field and is a list of days of the week and times during
              which this restriction apply to this user. The valid days  are  'Su',  'Mo',  'Tu',
              'We', 'Th', 'Fr', and 'Sa'.  In addition, the value 'Al' represents all 7 days, and
              'Wk' represents the 5 weekdays.  Times are given as HHMM-HHMM.  The ending time may
              be before the starting time.  Days are presumed to wrap at 0000.

       /usr/conf/config.aeg
              This  text  file  contains  the  configuration information necessary for radiusd to
              connect to the ActivEngine, which is  the  ActivCard  Authentication  Server.   See
              comments contained in the example file provided for details.

LOGGING FILES

       All  logging  and accounting files of YARD RADIUS are stored under `/usr/logs'. Accounting
       files are organized on a per-month and per-year basis. All files written  by  Livingston's
       server  are  also written by YARD, but it also creates some specific binary files to store
       the on-line status of users, and collect users statistics.

       It's important to ensure that those files are synchronized with the  real  status  of  the
       clients,  to  avoid annoying denial-of-service troubles to your users (e.g. in conjunction
       with a Yard-Simultaneuous-Use attribute).  This could happen  when  one  or  more  clients
       reboots  without  sending suitable stop accouting records before. In those cases, YARD has
       to be killed too and restarted with a `clean up' argument `-c',  in  order  to  reset  its
       internal status.

       The logging file structure is as follows:

       <year>/user-stats        GDBM yearly file
       <year>/radlast-XX        Binary compact monthly file
       <nas>/<year>/detail-XX   Livingston-like logging text file

       This allows very fast computing of statistics and maintaining on-line status.

BUGS

       Bugs? What's a bug?

SEE ALSO

       builddbm(8),   radlast(1),   radlist(1),  radtest(1),  radwatch(1),  radius_attributes(5),
       gdbm(3)

AUTHOR

       Francesco Paolo Lovergine <francesco@yardradius.org>.

       A complete list of contributors is contained in CREDITS file.  You should  get  that  file
       among other ones within your distribution and possibly installed under /usr/docs directory

COPYRIGHT

       Copyright (C) 1992-1999 Lucent Inc. All rights reserved.

       Copyright (C) 1999-2004 Francesco Paolo Lovergine. All rights reserved.

       See the LICENSE file enclosed within this software for conditions of use and distribution.
       This is a pure ISO BSD Open Source License .

NOTES

       The configuration of a RADIUS server is an argument too long to deal with it here. Please,
       refer  to  the  official  Livingston  documentation,  which  includes  the RADIUS for UNIX
       Administrator's       Guide.         It        is        freely        available        at
       http://www.livingston.com/tech/docs/manuals.html at the time of this document.

       It's a very good point to start with.