Sun Cluster HA for Kerberos

You must configure Sun Cluster HA for Kerberos as a failover data service. For conceptual information about failover data services, see Chapter 1, Planning for Sun Cluster Data Services, in Sun Cluster Data Services Planning and Administration Guide for Solaris OS and the Sun Cluster Concepts Guide for Solaris OS.

Kerberos servers have two daemons:

krb5kdc(1M)

Authentication service

kadmind(1M)

Principal or policy administration service

The krb5kdc daemon runs on both master and slave Key Distribution Center (KDC) servers. This service provides redundancy because an environment can have a master and one or more slaves that are running this process.

The kadmind daemon runs only on the master server and can handle requests that make updates to the principal/policy database. This single point of failure makes update requests more fragile than krb5kdc. By clustering the master KDC in the Kerberos environment you can provide update requests with greater availability.

For an introduction to Kerberos concepts, refer to Part VI, Kerberos Service, in System Administration Guide: Security Services.

Figure 1–1 lists the Kerberos components of a Sun Cluster environment.

Figure 1–1 Kerberos Components in the Sun Cluster Environment

In Figure 1–1, pam_krb5(5), kpasswd(1), kpropd(1M), and kadmin(1M) all send requests to kadmind directly. pam_krb5 and kpasswd make update requests when changing a users password. kadmin is used for general administration of the principal and policy database.

Figure 1–2 shows how databases and configuration information are shared between the cluster nodes and zones through a global or failover file system.

Figure 1–2 Database and Configuration Sharing

The configuration and keytab files are placed in /etc/krb5. The databases and logging files are kept under /var/krb5. By having these directories on a shared file system, you ensure that the database and configuration are identical. During failover, there should be little impact on client ticket requests, especially if there are slaves in the environment because slaves could be used to service client tickets during the failover period.

Clients that have already established sessions with kadmind by using the kadmin command are dropped after a failover on the cluster. Given the amount of privileges usually given for administrative principals, active kadmin sessions should not be left unattended. They should not run for an extended period of time. This means that kadmin session drops should not occur frequently because they are short lived processes.