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.

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, 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 The Oracle Solaris 11 Release

This section lists the changes that are available in the Oracle Solaris 11 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.

• A set of user-level statically defined trace points for Kerberos has been added. These probes provide a logical view into Kerberos protocol messages. See Using DTrace With the Kerberos Service for an example.

• The kclient script has been enhanced. The script includes the capability of joining Microsoft Active Directory servers. For instructions, see How to Interactively Configure a Kerberos Client and How to Configure a Kerberos Client for an Active Directory Server. In addition, the script includes a -T option that can be used to identify the KDC server type for the client. All of the options for this script are covered in the kclient(1M) man page.

• The /etc/krb5/kadm5.keytab file is no longer needed. The keys that were stored in this file are now directly read from the Kerberos database.

• Support for accessing Kerberos principal and policy records by using LDAP from a directory server has been added. This change simplifies administration and can provide greater availability, depending on the deployment of the KDCs and the directory servers. See Managing a KDC on an LDAP Directory Server for a list of LDAP-related procedures.

• The new kdcmgr command can be used to automatically or interactively setup any KDC. This command creates both master and slave KDC servers. Also, when used with the status option, the kdcmgr command shows information about any KDC that is installed on the local host. Look for the pointers to the automatic and interactive procedures in Table 21-1.

• Support for Oracle Solaris clients that require no additional setup has been added to this release. Changes were made to the Kerberos service and to some default values. Kerberos clients work with no client-side configuration in environments that are appropriately configured. See Client Configuration Options for more information.