Standards, Environments, and Macros                   kerberos(5)



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  Ker-
     beros session, either by using the kinit(1) command or a PAM
     module. (See pamkrb5(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 tran-
     sparently, 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 life-
     time 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  for-
     wardable,  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.



SunOS 5.11           Last change: 1 Oct 2008                    1






Standards, Environments, and Macros                   kerberos(5)



     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 ser-
                 vice,  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
     (GS-API), Kerberos offers, besides user authentication, two
     other types of security service: integrity, which  authenti-
     cates  the  validity of transmitted data, and privacy, which
     encrypts transmitted data. Developers can take advantage  of
     the  GS-API through the use of the RPCSECGS API interface
     (see rpcsecgss(3NSL)).

EXAMPLES
     Example 1 Examples of valid principal names


     The following are examples of valid principal names:


            joe
            joe/admin
            joe@ENG.ACME.COM
            joe/admin@ENG.ACME.COM
            rlogin/bigmachine.eng.acme.com@ENG.ACME.COM
            host/bigmachine.eng.acme.com@ENG.ACME.COM







SunOS 5.11           Last change: 1 Oct 2008                    2






Standards, Environments, and Macros                   kerberos(5)



     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 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  princi-
     pals. With host principals, the instance is the fully quali-
     fied hostname. Note  that  the  words  admin  and  host  are
     reserved keywords.


SEE ALSO
     kdestroy(1), kinit(1), klist(1),  kpasswd(1),  krb5.conf(4),
     krb5envvar(5)


     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 mes-
     sage:

       Principal unknown (kerberos)




     you have not been registered as a Kerberos  user.  See  your
     system  administrator  or  the  System Administration Guide:
     Security Services.



















SunOS 5.11           Last change: 1 Oct 2008                    3