# This is the access authorisation file used by protelnetd.  This file
# should exist as /etc/protelnetd.auth on any system running protelnetd.
# You are able to specify criteria for allowing or rejecting access to the
# system.  The criteria can be based on the incoming IP address, the user
# name used, the certificate passed (if any), or a combination of them.
# These tests are in addition to the standard Unix username/password
# validations.
#
# The following (optional) sections may be defined:
#[local]
#  This defines the IP address range(s) of the local system.  Any incoming
#  connection with an IP address in the range(s) defined here is let through.
#  All other sections are ignored for local connections.
#[deny]
#  This defines IP addresses, users, or users within an IP address range that
#  are to be denied access to the system.
#[allow]
#  If this section is present, it defines IP addresses, users, or users within
#  an IP address range that will be allowed access to the system.  Any IP
#  address or user that is not in this allowed list will be denied access to
#  the system.
#[trusted]
#  This defines IP addresses, users, or users within an IP address range that
#  are considered to be trusted (i.e. no additional authorisation checks are
#  required).  This is similar to [local], except that you can specify IP
#  addresses, users, or both, and the connection must pass any [deny] and
#  [allow] section criteria.  
#[certificates]
#  This defines a list of certificates that are considered to be trusted.
#  Each certificate can contain a list of users who are valid for the
#  certificate.  If no user list is specified for a certificate, then all
#  users are valid if they have the certificate.
#
# The PROTELNETD program performs the following steps (in order) to verify
# if a connection will be granted access to the system:
#
# 1) The username and password will be requested as per a normal login.
# 2) If the connection's IP address is in the [local] IP address range, then
#    access is permitted (no further tests).
# 3) If the connection fails the [allow]/[deny] criteria, then access to the
#    system is denied (no further tests).
# 4) If the connection passes the [trusted] criteria, then access is
#    permitted (no further tests).
# 5) If the connection passes the [certificates] criteria, then access is
#    permitted (no further tests).
# 6) A connection password will be requested (if one is defined).  If no
#    connection password is defined, then access to the system is denied.
#    If the password entered is correct, then access is permitted.  If the
#    password entered is not correct, a "login incorrect" message will be
#    given, and the login process will start again.
#
# If access to the system is permitted then the username and password entered
# will be validated.  If valid, the user will be logged in.
#
# The additional connection password is contained in /etc/protelnetd.pwd.
# This is set by the /usr/local/bin/protelnetdpwd program.
#
# The format of an IP address range is:
#   <start-IP-address> - <end-IP-address>
# e.g.
#   128.9.0.0 - 128.9.255.255
# Only one IP address or range of addresses may be specified per line.
# Individual IP addresses may be used instead of a range where appropriate.
# Note: If the connecting clients are resolvable using DNS, please ensure
# both forward and reverse zones are configured properly.  If DNS isn't
# configured properly it may cause Protelnetd to be unable to resolve the
# connecting client IP which will cause the IP access lists to function incorrectly.

#
# In sections that allow users to be specified within IP addresses, the list
# of users occurs after the IP address (on the same line), separated by a
# vertical bar (|).  For example:
#  128.9.0.0 - 128.9.255.255 | fred, harry
# If the IP address range is ommitted, this implies all IP addresses.  e.g.
#  | fred, harry
# If the user list is ommitted, this implies all users.  e.g.
#  128.9.0.0 - 128.9.255.255 |
#
# The [certificates] section allows a list of certificates (identified by
# their subject text).  Only one certificate is allowed per line.  If the
# certificate is restricted to a set of users, the list of users are specified
# after the certificate's subject, separated by a vertical bar (|).  e.g.
#   /C=AU/O=Dodgy Brothers/CN=Brother 1 | fred, harry
#
# Only the leading part of the subject text for the certificate needs to be
# specified.  This allows you to specify a single line that covers all
# certificates within a company (or department of a company).  The c_info
# script can be used to list the subject text (amoungst other things) for
# a certificate (assuming that you have a copy of it).
#
# The public key from the certificate authority who issued the certificate
# must be in the /usr/local/ssl/certs directory.  Once a new certificate is
# placed in this directory, run the /usr/local/ssl/bin/c_rehash script to
# create the required hashed links to them.

[local]
#	Our local (internal) IP address range
#	128.9.0.0-128.9.255.255
[deny]
#	Never let these thru (if not local)
	|root,pronto,backup,guest
[trusted]
[certificates]