hpux man page for sis

sis(5)								File Formats Manual							    sis(5)

NAME
       sis - secure internet services with Kerberos authentication and authorization

DESCRIPTION
       (SIS)  provides	network authentication when used in conjunction with HP DCE security services, the HP Praesidium/Security Server, or other
       software products that provide a Kerberos V5 Network Authentication Services environment.  The network authentication ensures that a  local
       and remote host will be mutually identified to each other in a secure and trusted manner and that the user is authorized to use the service
       on the remote host.

       Traditional internet services such as or allow the user to access remote systems by typing a password  that  is	then  transmitted  to  the
       remote  system  over  the  network.  The password is transmitted without encryption over the network, permitting an observer to capture the
       cleartext packets containing the password.  This has been a major security hole for traditional internet services.

       The optional Secure Internet Services are a replacement for their traditional counterparts and prevent the cleartext transmission  of  user
       passwords  over the network.  However, none of these services will encrypt the session beyond what is necessary to authenticate the service
       or authorize the user.

       This manpage assumes the reader is familiar with Kerberos terminology normally provided with your Kerberos V5 Network  Authentication  Ser-
       vices environment.  The intent here is to describe those aspects of the Kerberos environment specifically used by SIS.

   Authentication
       For  Kerberos  authentication to succeed, the user must have successfully logged into a system within the Kerberos realm and obtained a set
       of credentials.	The credentials include a Ticket Granting Ticket (TGT) and a session key.  The SIS client will use the	TGT  to  obtain  a
       service	ticket	to access a SIS daemon on the network.	If the credentials are missing or the TGT is invalid, the authentication will fail
       and connection to the SIS daemon will be denied.

       For systems configured into a DCE cell, credentials are obtained through the command.  For systems configured  into  a  Praesidium/Security
       Server  cell,  credentials  are	obtained  through  the	command.  In a non-DCE Kerberos-based secure environment, credentials are obtained
       through the command.

   Authorization
       For every user of these services, a user principal must be configured into the Key Distribution	Center's  database.   The  user  principal
       allows  the  user  to obtain a service ticket which is sent to the remote service as part of the Kerberos authentication mechanism.  If the
       authentication is successful, the user principal is then used as part of the Kerberos authorization mechanism.

       In order for the authorization to succeed, both of the following requirements must be met:

       1.     The login name must exist in the remote system's password file, that is, the remote account must exist.  Note:  The  login  name	is
	      the name specified by the user in response to a login prompt and may be different from the current user name.

       2.     One of the following conditions must be true:

       A.     The  remote  account's  home directory has a file that contains the user principal.  The file must be owned by that account and only
	      that account can have write permission (that is, the permissions would appear as

	      Note: In the remote system, if the directory exists, Kerberos ignores the file in the remote account's home directory.

       B.     The remote system has a file or symbolic link in the directory that contains the user principal. If the directory  does  not  exist,
	      Kerberos	checks	the  file in the remote account's home directory. If the directory exists, Kerberos ignores the file in the remote
	      account's home directory.

	      The format of the entries in the file is similar to the entries in the file. The file (or symbolic link) and directory must be owned
	      by  the  root  user  and only the root user must have write permission (that is, To give privileges to a user to handle the file, an
	      administrator can create a symbolic link to the file in remote account's home directory.

       C.     The remote system has an authorization name database file, that contains the user principal.  The file should contain a  mapping	of
	      the user principal to an account on the remote system.

       D.     The user name in the user principal is the same as the user name of the account being accessed, and the local and remote systems are
	      in the same realm.

       If authorization succeeds, the user will not see a prompt for a password (when a password is required) and the  connection  to  the  remote
       system  will succeed.  If the authentication or authorization fails, the user will be notified of the error and will not be allowed to con-
       tinue.

   Bypassing or Enforcing Authentication/Authorization
       If the authentication or authorization fails, the service can be rerun with a special command-line option to request non-Kerberos authenti-
       cation.	However, when a password is required, it will be sent across the network in a readable form.  Typically, this special command-line
       option should only be used to access nonsecure remote systems.

       The and daemons have a special command-line option which can be used to ensure that nonsecure systems are denied access.

       To prevent nonsecure access through the rcp, remsh or rlogin commands, the file on the remote system should be edited to  comment  out  the
       entries for and

SERVICES
       file transfer program

       remote login

       user interface and server for Telnet protocol

       remote file copy

       execute from a remote shell

TROUBLESHOOTING
       For the correct execution of SIS, it is important that the secure environment be properly installed, configured and running.  The following
       is a quick checklist to verify this:

       1.     The DCE, Praesidium/Security Server, or Kerberos security system should be running on the Kerberos server.  The file should  contain
	      entries for the Kerberos ports.

       2.     The user's user principal must be entered into the Key Distribution Center's database.  Use the appropriate tool (for example, or HP
	      DCE's to list the database and to verify that the user has a user principal configured.

       3.     The Kerberos configuration directory on the local and remote systems should contain a and a server key table file.   Generally,  the
	      Kerberos configuration directory will be and the server key table file will be named

       4.     The user principal must be specified in the or on the local and remote systems.  The lists the principals and realm names which have
	      access permission for the user's account.

	      Alternatively, the secure system can use an authorization name database, on the local and remote systems.  An  entry  in	this  file
	      will authorize the user name in a user principal to the specified login name.

	      Verify  that  or	exists,  has the correct permissions (that is, and includes the user principal.  Or, use the appropriate tool (for
	      example, on a non-HP DCE system) to verify that the user principal is included in the file.

	      Note: In the remote system, if the directory exists, Kerberos ignores the file in remote account's home directory.

       5.     The server key table file on the remote system should contain a host principal.  The root  user  can  verify  the  contents  of  the
	      v5srvtab through the command: If supports the option, type this command and verify that a host principal is listed.

	      Alternatively, if the validation tool, is available on the system, use the command:

       6      If  is available on the local and remote systems, use it to test the Kerberos configuration by invoking it to act as a client appli-
	      cation on the local system and a server application on the remote system.  See krbval(1M) for details.

       7.     The SIS files must be installed.	The traditional services will have been saved and the files for the new services will be linked to
	      the original, traditional file names.

DIAGNOSTICS
       In  addition  to  Kerberos-specific  error messages, SIS has a few security related error messages that are common to several or all of the
       services.  These error messages can be used by scripts to detect whether the invocation of a service has failed.

   Error and Warning Messages Reported by the SIS Clients

	      The user has not obtained a valid Ticket Granting Ticket (through or or a valid host principal has not been configured  in  the  Key
	      Distribution  Center's  database	for  the  realm.   A more specific error message indicating the possible cause of the failure will
	      accompany this error message.

	      This error message will also be generated if the user attempts to access a nonsecure remote system.  In  which  case,  this  message
	      will be preceded by the message:

	      This error is reported by ftp, rlogin and telnet.

	      The  command-line  option indicates that Kerberos authentication should not be performed.  If any Kerberos-specific options are also
	      specified on the command line, then they are in contradiction to this request.

	      For and this means the option can not be used in conjunction with the or options.

	      For this means the option can not be used in conjunction with the option.

	      For this means the option cannot be used in conjunction with the or options.

	      The user has specified the option on the command line to access a nonsecure remote system or to bypass a bad  configuration  in  the
	      Kerberos environment.

	      In the cases where a password is requested, the command-line option will cause the password to be sent across the network in a read-
	      able form where it could possibly be intercepted or captured.

	      It is recommended that the user corrects a bad configuration and only uses the option if the remote system is nonsecure.

	      The first warning is reported by and The second warning is reported by could report either warning depending upon whether a password
	      is required.

   Error Messages Reported in the syslog by the SIS Daemons

	      The daemon was started with the command-line option to ensure that nonsecure access by remote systems will be denied.  The user can-
	      not access the remote system unless the local system has been configured for secure access.

	      This error is logged by and

	      The local_user does not have a valid password file entry.

	      This error is logged by all SIS daemons.

	      Authentication succeeded but authorization failed.  The user should verify that their user name is listed in or or in  the  file	on
	      the remote system.  The user's must have the correct permissions and must be owned by the user (that is,

	      This error is logged by all SIS daemons.

	      The or files are missing or are not set up properly to authorize local_user (see ruserok(3N)).

	      This error is logged by or if they are started with the or options.

SEE ALSO
       ftp(1),	kdestroy(1), kinit(1), klist(1), krbval(1M), rcp(1), remsh(1), rlogin(1), telnet(1), dce_intro(1M), dce_login(1M), dess_login(1M),
       ftpd(1M), remshd(1M), rlogind(1M), telnetd(1M), dess(5).

																	    sis(5)