 |
» |
|
|
|
Some things you, as network or system administrator, should
be aware of, regarding how end users might use the Secure Internet
Services, are described in the paragraphs below. Overview of the User's Session | |
Users must
issue a
kinit (for HP DCE clients, a dce_login, or for HP P/SS clients, a dess_login) command so that they get a TGT from the KDC (for
example, kinit amy@realm1.com). The TGT credentials received from the
kinit (or dce_login or dess_login) will typically be valid for a default lifetime.
The kinit(1) man page describes TGT lifetime and renewable
options. For more information, refer to the kinit(1), dce_login(1), and dess_login(1) man pages. Once users have obtained a TGT, they can use the
Secure Internet Services throughout the time period that their TGT
is valid. The lifetime of a TGT is configurable and is typically
eight hours. The only visible difference when using the Internet Services
with the Secure Internet Services mechanism enabled is that users
are not prompted for a password. For information on Kerberos concepts,
refer to “Overview of the Secure
Environment and the Kerberos V5 Protocol” of this chapter. The klist command is
one of the Kerberos utilities users may want to use during their
secure session. This command will display their accumulated credentials.
For more information, refer to the klist(1) man page. When users are finished for the day (or secure session),
they should issue the kdestroy command to
remove the credentials they have accumulated during their session.
These credentials are not automatically removed when they exit a
shell or log out of their session. So, we strongly recommended that
they issue this command so that any credentials they accumulated
are not susceptible to misuse from intruders. For more information
refer to the kdestroy(1) man page.
Bypassing and Enforcing Kerberos Authentication | |
Depending on how certain options are used with these services,
the Secure Internet Services clients will still be able to access
non-secure remote hosts, and the daemons will still be able to accept
requests from non-secure clients. To access a non-secure remote system on the network, users
can use the -P option when issuing the client command to bypass
Kerberos authentication. However, if accessing the host requires
a password, then the password will be sent in a readable form over
the network. To prevent remote users from gaining access in a non-secure
manner, administrators can enforce Kerberos authentication. For ftpd and telnetd, to prevent access from non-secure clients these
daemons should be invoked with the -A option. For remshd and rlogind, to prevent access from non-secure clients the
entries for shell and login in the /etc/inetd.conf file should be commented out. If these steps have
been taken, the client cannot use the -P option to bypass authentication. | | | |  | CAUTION: If the shell line is commented out, the rdist command will no longer work. | | | | |
Other Comments on Using the Secure Internet Services | |
There is no change to the way in which
anonymous users are handled when using ftp with the Secure Internet Services mechanism enabled.
However, in secure environments, it serves no purpose to authenticate
or authorize an anonymous user. An anonymous user does not have
a password to protect, and any data accessible through an ftp account has been made publicly available. Therefore,
it does not make sense to add an anonymous user to the KDC's
database. To access a secure system anonymously, use the -P option ftp provides. This approach requires that ftpd was not invoked with the -A option on the remote host. When the Secure Internet Services mechanism is enabled, rlogin, remsh, and rcp are affected as follows: rlogin accesses rlogind through the new port specified by the /etc/services entry klogin when operating as a secure client. If you invoke rlogin with the -P option, or if you run rlogin without the Secure Internet Services mechanism
enabled, then rlogin will behave as a non-secure client and access rlogind through the login port. remsh accesses remshd through the new port specified by the /etc/services entry kshell when operating as a secure client. If you invoke remsh with the -P option, or if you run remsh without the Secure Internet Services mechanism
enabled, then remsh will behave as a non-secure client and access remshd through the shell port. rcp accesses remshd through the new port specified by the /etc/services entry kshell when operating as a secure client. If you invoke rcp with the -P option, or if you run rcp without the Secure Internet Services mechanism
enabled, then rcp will behave as a non-secure client and access remshd through the shell port.
|
