Installing and Administering Internet Services

352 Chapter 11
Secure Internet Services
Overview of the Secure Environment and the Kerberos V5 Protocol
Generally, configurations that contain non-HP security clients will
interoperate securely with configurations that include the HP Secure
Internet Services, provided all of the following things are true:
• The Kerberos utilities kinit, klist, and kdestroy are based on
Kerberos V5.
• Secure versions of rcp/remshd, remsh/remshd, rlogin/rlogind,
and telnet/telnetd either are implemented with Kerberos V5
Release 1.0 API or interoperate with it.
• Secure versions of ftp/ftpd are implemented according to the FTP
security extension standard and use the GSS-API Version 1 based on
the Kerberos V5 Release 1.0 API.
For information on the non-HP Kerberos client, refer to your provider’s
documentation.
The Non-HP Kerberos client is shown as node E in Figure 11-2 and
Figure 11-3.
Interoperability within a Realm
Within a given realm, all KDCs must be of the same type. In other words,
for configurations that include the Secure Internet Services, KDCs must
be all HP DCE Security Services, all HP P/SSs, or all non-HP Kerberos
V5 KDCs (implementing RFC 1510). Multiple KDCs of the same type can
exist. In these cases there is effectively one “master” KDC. The
additional KDCs contain duplicate, read-only, database information from
the master. This is done for availability purposes: if the master goes
down, a “slave” (one of the KDCs with the duplicate information) takes
over for the master.
Currently it is not possible to set up heterogeneous cross-realm
authentication between an HP DCE or P/SS KDC and a Kerberos V5
KDC. So, even in cross-realm configurations, all KDCs must be of the
same type. In other words, they must be either all HP DCE Security
Services, HP P/SSs, or all non-HP Kerberos V5 KDCs (implementing
RFC 1510). For more specific interoperability information with non-HP
Kerberos clients (node E in Figure 11-2 and Figure 11-3), contact your
HP support representative.