Components of Various Kerberos Releases

Components of the Kerberos service have been included in many releases. Originally, the Kerberos service and changes to the base operating system to support the Kerberos service were released using the product name “Sun Enterprise Authentication Mechanism” which was shortened to SEAM. As more components of the SEAM product were included in the Oracle Solaris software, the contents of the SEAM release decreased. Starting with the Oracle Solaris 10 release, all components of the SEAM product are included, so there is no longer a need for the SEAM product. The SEAM product name exists in the documentation for historical reasons.

The following table describes which components are included in each release. Each product release is listed in chronological order. All components are described in the following sections.

Table 19-1 Kerberos Release Contents

For more information about enhancements included in the Oracle Solaris 10 release, see Kerberos Components in System Administration Guide: Security Services.

Kerberos Components

Similar to the MIT distribution of the Kerberos V5 product, the Kerberos service in the Oracle Solaris release includes the following:

• Key Distribution Center (KDC):

  • Kerberos database administration daemon – kadmind.

  • Kerberos ticket processing daemon – krb5kdc.

  • Database administration programs – kadmin (master only), kadmin.local and kdb5_util.

  • Database propagation software – kprop (slave only) and kpropd.

• User programs for managing credentials – kinit, klist, and kdestroy.

• User program for changing your Kerberos password – kpasswd.

• Remote applications – ftp, rcp, rlogin, rsh, scp, sftp, ssh, and telnet.

• Remote application daemons – ftpd, rlogind, rshd, sshd, and telnetd.

• Keytab administration utility – ktutil.

• The Generic Security Service Application Programming Interface (GSS-API) – Enables applications to use multiple security mechanisms without requiring you to recompile the application every time a new mechanism is added. The GSS-API uses standard interfaces that allow applications to be portable to many operating systems. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication. Both ftp and ssh use the GSS-API.

• The RPCSEC_GSS Application Programming Interface (API) – Enables NFS services to use Kerberos authentication. RPCSEC_GSS is a security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits on top of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.

In addition, the Kerberos service in the Oracle Solaris release includes the following:

• A Kerberos Administration GUI-based Tool (gkadmin) – Enables you to administer the principals and principal policies. This Java technology-based GUI is an alternative to the kadmin command.

• A Kerberos V5 service module for PAM – Provides authentication, account management, session management and password management for the Kerberos service. The module can be used to make Kerberos authentication transparent to the user.

• Kernel modules – Provides kernel-based implementations of the kerberos service for use by the NFS service, which greatly improves performance.

About Kerberos in this Release

This section lists the changes that are available in the Oracle Solaris 11.1 release.

• The Kerberos software has been synchronized with the MIT 1.8 release. The following features were included:

  • The arcfour-hmac-md5-exp, des-cbc-md5, and des-cbc-crc weak encryption types are disallowed by default. The allow_weak_crypto = true declaration in the /etc/krb5/krb5.conf file can be added to allow use of the weaker encryption algorithms.

  • In the /etc/krb5/krb5.conf file, the permitted_enctypes relation can take an optional DEFAULT keyword with + or - enctyp_family to add of remove a specific encryption type from the default set.

  • In most cases, you can eliminate the need for the domain_realm mapping table on the client side, by implementing minimal referral support in the KDC and providing the mapping information to clients through that protocol. Clients can function with no domain_realm mapping table, by sending requests for the service principal name service/canonical-fqdn@LOCAL.REALM to the local KDC and requesting referrals. This capability can be limited to service principal names with specific name types or in specific forms. The KDC can use only its domain_realm mapping table. No blocking queries to DNS can be introduced.

  • You can create aliases for principal entries if you are using an LDAP backend for the Kerberos database. Principal alias support is useful if a service can be accessed by different host names or if DNS is not available to canonicalize the host name, meaning that the short form is being used. You can use an alias for the various principal names a service is known by and the system only needs one set of keys for the actual service principal in its keytab file.

  • You can use the kvno utility to diagnose issues with service principal keys that are stored in /etc/krb5/krb5.keytab.

  • The kadmin ktadd command supports the -norandkey option which prevents the kadmind command from creating a new randomized key. The -norandkey option can be useful when you want to create a keytab for a principal that has a password-derived key. You can create a keytab that can be used to run the kinit command without having to specify a password.

  • Principals can be locked out after a certain number of preauthentication failures within a given time limit. See How to Configure Account Lockout for more information.

  • The OK_AS_DELEGATE flag enables the KDC to communicate the local realm policy to a client regarding whether an intermediate server is trusted to accept delegated credentials. See Trusts of Services for Delegation for more information.

• The Kerberos service has been updated to provide the ability for a Solaris client to make updates in a multiple KDC master environment. See Example 21-15 for more information.

• The ktkt_warnd daemon has been enhanced to register principals with existing credentials and to allow mail to be sent to users without explicitly specify each user. In addition, the service is now user configurable. See How to Automatically Renew All Ticket-Granting Tickets (TGTs) for working examples.