SEAM(5)

NAME

     SEAM - overview of Sun Enterprise Authentication Mechanism

DESCRIPTION

     SEAM (Sun Enterprise Authentication Mechanism) authenticates
     clients  in a network environment, allowing for secure tran-
     sactions.  (A client may be a user  or  a  network  service)
     SEAM validates the identity of a client and the authenticity
     of transferred data. SEAM is a single-sign-on system,  mean-
     ing  that  a  user  needs  to provice a password only at the
     beginning of a session. SEAM is based on the Kerberos system
     developed at MIT, and is compatible with Kerberos V5 systems
     over heterogeneous networks.

     SEAM works by granting clients tickets, which uniquely iden-
     tify  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 SEAM ticket may rlogin into another machine  running
     SEAM  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  SEAM
     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 tran-
     sparently, the user need not worry about  their  management.
     Current  tickets  may  be viewed by using the  klist(1) com-
     mand.

     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  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.

     Under SEAM, a client is referred to as a principal. A  prin-
     cipal 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. SEAM 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),  SEAM  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  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.ACME.COM
          joe/admin@ENG.ACME.COM
          rlogin/bigmachine.eng.acme.com@ENG.ACME.COM
          host/bigmachine.eng.acme.com@ENG.ACME.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  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(5)

     Sun Enterprise Authentication Mechanism Guide

NOTES

     If you enter your username and kinit responds with this mes-
     sage:

     Principal unknown (kerberos)

     you haven't been registered as a SEAM user. See your  system
     administrator or the Sun Enterprise Authentication Mechanism
     Guide.