 |
» |
|
|
|
NAMEsis — secure internet services with Kerberos authentication and authorization DESCRIPTIONSecure Internet Services
(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
telnet,
rlogin,
or
ftp,
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 man page 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 Kerberos
environment specifically used by SIS. AuthenticationFor 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
dce_login
command.
For systems configured into a Praesidium/Security Server cell,
credentials are obtained through the
dess_login
command.
In a non-DCE Kerberos-based secure environment, credentials are obtained
through the
kinit
command. AuthorizationFor 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:
The login name must exist in the remote system's password file,
i.e, 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. One of the following conditions must be true:
The remote account's home directory has a
.k5login
file that contains the user principal. The
.k5login
file must be owned by that account and only that account can
have write permission (i.e., the permissions would appear
as -rw-r--r--). The remote system has an authorization name database
file,
aname,
that contains the user principal. The
aname
file should contain a mapping of the user principal to an
account on the remote system. 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 continue. Bypassing or Enforcing Authentication/AuthorizationIf the authentication or authorization fails, the service
can be re-run with a special command line option
(-P)
to request non-Kerberos authentication. 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 non-secure remote systems. The
ftp and telnet
daemons have a special command line option
(-A)
which can be used to ensure that non-secure systems are
denied access. To prevent non-secure access through the rcp, remsh or rlogin
commands, the
inetd.conf
file on the remote system should be edited to comment out the entries for
shell and login. SERVICES- ftp, ftpd
file transfer program - rlogin, rlogind
remote login - telnet, telnetd
user interface and server for Telnet protocol - rcp, remshd
remote file copy - remsh, remshd
execute from a remote shell
TROUBLESHOOTINGFor 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
/etc/services
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 (e.g.,
kadmin
or HP DCE's
dcecp)
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
krb.conf,
krb.realms,
and a server key table file. Generally, the Kerberos configuration
directory will be
/krb5
and the server key table file will be named
v5srvtab. - 4.
The user principal must be specified in
~/.k5login
on the local and remote systems. The
~/.k5login
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,
aname,
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
~/.k5login
exists, has the correct permissions (i.e., -rw-r--r--), and
includes the user principal. Or, use the appropriate tool (e.g.,
krb5_anadd
on a non-HP DCE system) to verify that the user principal is
included in the
aname
file. - 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:
klist -k.
If
klist
supports the -k option, type this command and verify that
a host principal is listed. Alternatively, if the validation tool,
krbval,
is available on the system, use the command:
krbval -v. - 6
If
krbval
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.
DIAGNOSTICSIn 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- ERROR! Kerberos authentication failed.
The user has not obtained a valid Ticket Granting Ticket (through
kinit,
dce_login,
or
dess_login)
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 non-secure remote system. In which case, this
message will be preceded by the message: "To bypass Kerberos authentication,
use the -P option". This error is reported by ftp, rlogin and telnet. - ERROR! Kerberos-specific options are invalid with the -P option.
The
-P
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
remsh and rlogin,
this means the
-P
option can not be used in conjunction with the
-F, -f or -k
options. For
rcp
this means the
-P
option can not be used in conjunction with the
-k
option. For
telnet,
this means the
-P
option cannot be used in conjunction with the
-a
or
-l
options. - WARNING! Password will be sent in a non-secure manner.
- WARNING! Kerberos authentication will be bypassed.
The user has specified the
-P
option on the command line to access a non-secure remote system or to bypass a
bad configuration in the Kerberos environment. In the cases where a password is requested, the
-P
command line option will cause the password to be
sent across the network in a readable form where
it could possibly be intercepted or captured. It is recommended that the user corrects a bad
configuration and only uses the
-P
option if the remote system is non-secure. The first warning is reported by
ftp, rlogin,
and telnet.
The second warning is reported by
rcp. remsh
could report either warning depending upon whether a password is required.
Error messages reported in the syslog by the SIS daemons- ERROR! Access denied. Kerberos authentication must succeed.
The daemon was started with the
-A
command line switch to ensure that non-secure 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
ftpd and telnetd. - ERROR! Principal <principal> (<remote_user>@<remote_host>) logging in
as <local_user> has no account. The "local_user" does not have a valid password file entry. This error is logged by all SIS daemons. - ERROR! Principal <principal> (<remote_user>@<remote_host>) logging in
as <local_user> failed krb5_userok. Authentication succeeded but authorization failed.
The user should verify that their user name is listed
in
~/.k5login
or in the
aname
file on the remote system. The user's
~/.k5login
must have the correct permissions and must be owned by the user
(i.e., -rw-r--r--). This error is logged by all SIS daemons. - ERROR! Principal <principal> (<remote_user>@<remote_host>) logging in
as <local_user> failed ruserok. The
/etc/hosts.equiv or
~/.rhost
files are missing or are not set up properly to authorize
"local_user" (see ruserok(3N)). This error is logged by rlogind or remshd if they are started with the
-R, -r or -k
options.
SEE ALSOftp(1),
kinit(1),
kdestroy(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). |
