You can use choose one of three ways to install Kerberos clients:
Automatically – See Using Automatic Installation to Install Kerberos Clients.
By script – See Using the kclient Profile to Install Kerberos Clients.
Manually – See the MIT Kerberos Documentation web site while taking into account Oracle Solaris features such as PAM.
Client configuration planning includes which PAM module to use and whether to allow delegation of services.
In Oracle Solaris, the PAM framework provides protected network logins with the pam_krb5 module and other PAM modules. See Kerberos Client Login Security and the pam_krb5(5) man page.
When a client requests a service, that service can be granted by a server other than the master KDC. For more information, see Trusted Delegated Services in Kerberos.
For the procedures, see Configuring Kerberos Clients.
Kerberos clients can be configured quickly and easily by using the Oracle Solaris Automated Installer (AI) feature. AI server administrators create and assign Kerberos configuration profiles to AI clients. Additionally, the AI server delivers the client keys. Therefore, at installation, the Kerberos client is a fully provisioned Kerberos system, capable of hosting secure services. Using the Automated Installer can lower system administration and maintenance costs.
You run the kclient command to create Kerberos configuration profiles for AI. For more information, see the kclient(1M) man page. For instructions to configure Kerberos clients by using AI, see How to Configure Kerberos Clients Using AI in Installing Oracle Solaris 11.3 Systems.
You can use AI for clients that are not clients of an Oracle Solaris KDC. For the list of KDC vendors, see the kclient(1M) man page.
For all KDC types, pre-generated keytab transfer is supported. Oracle Solaris KDC and MS AD also support auto-registering.
In addition to AI configuration, Oracle Solaris provides the kclient configuration utility. This utility runs in interactive mode and noninteractive mode. Interactive mode prompts you for Kerberos-specific parameter values, so you can make changes when configuring each client. In noninteractive mode, you supply a file with parameter values and you can supply command-line options. The kclient utility requires fewer steps than manual configuration and are quicker and less prone to error.
If the following setup is in effect, then no explicit configuration of your Kerberos client is necessary:
DNS is configured to return SRV records for KDCs.
The realm name matches the DNS domain name, or the KDC supports referrals.
The Kerberos client does not require keys that are different from the KDC server's keys.
You still might want to explicitly configure the Kerberos client for the following reasons:
The zero-configuration process performs more DNS lookups than a directly configured client, and therefore is less efficient than direct configuration.
If referrals are not used, the zero-configuration logic depends on the DNS domain name of the host to determine the realm. This configuration introduces a small security risk, but the risk is much smaller than enabling dns_lookup_realm.
The pam_krb5 module relies on a host key entry in the keytab file. Although this requirement can be disabled in the krb5.conf file, doing so is not recommended for security reasons. For more information, see Kerberos Client Login Security and the krb5.conf(4) man page.
At login, a client uses a Kerberos PAM module to verify that the KDC that issued the latest TGT is the same KDC that issued the client host principal that is stored in the /etc/krb5/krb5.keytab file. The PAM module must be configured in the authentication stack to verify the KDC.
For some configurations, such as DHCP clients that do not store a client host principal, this check needs to be disabled. To disable the check, see Verifying Kerberos Clients Without a Host Principal.
For some applications, a client might need to delegate authority to a server to act on its behalf in contacting other services. The client must forward credentials to an intermediate server. The client's ability to obtain a service ticket to a server conveys no information to the client about whether the server can be trusted to accept delegated credentials. The –ok_to_auth_as_delegate option to the kadmin command provides a way for a KDC to communicate the local realm policy to a client regarding whether an intermediate server is trusted to accept such credentials.
The encrypted part of the KDC reply to the client can include a copy of the credential ticket flags with the –ok_to_auth_as_delegate option set. A client can use this setting to determine whether to delegate credentials (by granting either a proxy or a forwarded TGT) to this server. When setting this option, consider the security and placement of the server on which the service runs, as well as whether the service requires the use of delegated credentials.