Go to main content

man pages section 5: File Formats

Exit Print View

Updated: Wednesday, February 10, 2021

kerberos (5)


kerberos - overview of Solaris Kerberos implementation


Please see following description for synopsis


Standards, Environments, and Macros                                kerberos(5)

       kerberos - overview of Solaris Kerberos implementation

       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  het-
       erogeneous 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 enti-
       tled; 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. 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     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 prin-
                   cipal names, see the EXAMPLES.

       By taking advantage of the General  Security  Services  API  (GSS-API),
       Kerberos  offers, besides user authentication, two other types of secu-
       rity service: integrity, which authenticates the validity of  transmit-
       ted  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(3C)).

       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 princi-
       pals, even if the same user uses them; joe/admin has  different  privi-
       leges  from joe. The fifth case is a service principal, while the final
       case is a host principal. The word host is required  for  host  princi-
       pals.  With  host principals, the instance is the fully qualified host-
       name. Note that the words admin and host are reserved keywords.

       See attributes(7) for descriptions of the following attributes:

       |Availability   | security/kerberos-5    |
       |Stability      | Pass-through committed |
       kdestroy(1),    kinit(1),    klist(1),    kpasswd(1),     krb5.conf(4),

       This     software     was    built    from    source    available    at
       https://github.com/oracle/solaris-userland.   The  original   community
       source      was      downloaded      from      https://web.mit.edu/ker-

       Further information about this software can be found on the open source
       community website at https://web.mit.edu/kerberos/.

Solaris 11.4                      1 Oct 2008                       kerberos(5)