kerberos(5) Standards, Environments, and Macros kerberos(5)
kerberos - overview of Solaris Kerberos implementation
The Solaris Kerberos implementation, hereafter sometimes shortened to "Kerberos," authen-
ticates clients in a network environment, allowing for secure transactions. (A client may
be a user or a network service.) Kerberos validates the identity of a client and the
authenticity of transferred data. Kerberos is a single-sign-on system, meaning that a user
needs to provide a password only at the beginning of a session. The Solaris Kerberos
implementation is based on the Kerberos(TM) system developed at MIT, and is compatible
with Kerberos V5 systems over heterogeneous networks.
Kerberos works by granting clients tickets, which uniquely identify a client, and which
have a finite lifetime. A client possessing a ticket is automatically validated for net-
work services for which it is entitled; for example, a user with a valid Kerberos ticket
may rlogin into another machine running Kerberos without having to identify itself.
Because each client has a unique ticket, its identity is guaranteed.
To obtain tickets, a client must first initialize the Kerberos session, either by using
the kinit(1) command or a PAM module. (See pam_krb5(5)). kinit prompts for a password, and
then communicates with a Key Distribution Center (KDC). The KDC returns a Ticket-Granting
Ticket (TGT) and prompts for a confirmation password. If the client confirms the password,
it can use the Ticket-Granting Ticket to obtain tickets for specific network services.
Because tickets are granted transparently, the user need not worry about their management.
Current tickets may be viewed by using the klist(1) command.
Tickets are valid according to the system policy set up at installation time. For example,
tickets have a default lifetime for which they are valid. A policy may further dictate
that privileged tickets, such as those belonging to root, have very short lifetimes. Poli-
cies may allow some defaults to be overruled; for example, a client may request a ticket
with a lifetime greater or less than the default.
Tickets can be renewed using kinit. Tickets are also forwardable, allowing you to use a
ticket granted on one machine on a different host. Tickets can be destroyed by using kde-
stroy(1). It is a good idea to include a call to kdestroy in your .logout file.
Under Kerberos, a client is referred to as a principal. A principal takes the following
primary A user, a host, or a service.
instance A qualification of the primary. If the primary is a host -- indicated by the
keyword host-- then the instance is the fully-qualified domain name of that
host. If the primary is a user or service, then the instance is optional. Some
instances, such as admin or root, are privileged.
realm The Kerberos equivalent of a domain; in fact, in most cases the realm is
directly mapped to a DNS domain name. Kerberos realms are given in upper-case
only. For examples of principal names, see the EXAMPLES.
By taking advantage of the General Security Services API (GSS-API), Kerberos offers,
besides user authentication, two other types of security service: integrity, which authen-
ticates the validity of transmitted data, and privacy, which encrypts transmitted data.
Developers can take advantage of the GSS-API through the use of the RPCSEC_GSS API inter-
face (see rpcsec_gss(3NSL)).
Example 1 Examples of valid principal names
The following are examples of valid principal names:
The first four cases are user principals. In the first two cases, it is assumed that the
user joe is in the same realm as the client, so no realm is specified. Note that joeand
joe/admin are different principals, even if the same user uses them; joe/admin has differ-
ent privileges from joe. The fifth case is a service principal, while the final case is a
host principal. The word host is required for host principals. With host principals, the
instance is the fully qualified hostname. Note that the words admin and host are reserved
kdestroy(1), kinit(1), klist(1), kpasswd(1), krb5.conf(4), krb5envvar(5)
System Administration Guide: Security Services
In previous releases of the Solaris operating system, the Solaris Kerberos implementation
was referred to as the "Sun Enterprise Authentication Mechanism" (SEAM).
If you enter your username and kinit responds with this message:
Principal unknown (kerberos)
you have not been registered as a Kerberos user. See your system administrator or the Sys-
tem Administration Guide: Security Services.
SunOS 5.11 1 Oct 2008 kerberos(5)