KERBEROS(7) Standards, Environments, and Macros KERBEROS(7)

NAME

kerberos - overview of Solaris Kerberos implementation

DESCRIPTION

The Solaris Kerberos implementation, hereafter sometimes shortened to
"Kerberos," authenticates 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 network 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(7)). 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.
Policies 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 kdestroy(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 form:

primary/instance@REALM


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 authenticates 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 interface (see rpcsec_gss(3NSL)).

EXAMPLES

Example 1: Examples of valid principal names

The following are examples of valid principal names:


joe
joe/admin
joe@ENG.EXAMPLE.COM
joe/admin@ENG.EXAMPLE.COM
rlogin/bigmachine.eng.example.com@ENG.EXAMPLE.COM
host/bigmachine.eng.example.com@ENG.EXAMPLE.COM


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 joe and joe/admin are different
principals, even if the same user uses them; joe/admin has different
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
keywords.

SEE ALSO

kdestroy(1), kinit(1), klist(1), kpasswd(1), krb5.conf(5),
krb5envvar(7)


System Administration Guide: Security Services

NOTES

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 System Administration Guide: Security Services.

November 22, 2021 KERBEROS(7)