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 ServicesNOTES
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)