sis(5)sis(5)NAMEsis - secure internet services with Kerberos authentication and autho‐
rization
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 secu‐
rity hole for traditional internet services.
The optional Secure Internet Services are a replacement for their tra‐
ditional 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 ser‐
vice or authorize the user.
This manpage assumes the reader is familiar with Kerberos terminology
normally provided with your Kerberos V5 Network Authentication Services
environment. The intent here is to describe those aspects of the Ker‐
beros 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 connec‐
tion 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 authentica‐
tion is successful, the user principal is then used as part of the Ker‐
beros 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 pass‐
word (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 continue.
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 authentica‐
tion. 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 envi‐
ronment 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 con‐
tain entries for the Kerberos ports.
2. The user's user principal must be entered into the Key Distribu‐
tion 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. Gener‐
ally, 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 princi‐
pal 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 sys‐
tem, 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
application 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 ser‐
vices. 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 mes‐
sage 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 contradic‐
tion 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 readable form where it could possibly be intercepted or cap‐
tured.
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 cannot 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 ALSOftp(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)
