unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

SEAM(5)               Standards, Environments, and Macros              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 transactions. (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 sys-
       tem, meaning that a user needs to provice a password only at the begin-
       ning of a session. SEAM is based on the Kerberos  system  developed  at
       MIT, and is compatible with Kerberos V5 systems over heterogeneous net-
       works.

       SEAM 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 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
       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  SEAM,  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 privi-
                               leged.



       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 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  inter-
       face (see rpcsec_gss(3NSL)).

EXAMPLES
       Example 1: Examples of valid principal names

       The following are examples of valid principal names:

            joe
            joe/admin
            joeATENG.COM
            joe/adminATENG.COM
            rlogin/bigmachine.eng.acme.comATENG.COM
            host/bigmachine.eng.acme.comATENG.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 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 ALSO
       kdestroy(1),    kinit(1),    klist(1),    kpasswd(1),     krb5.conf(4),
       krb5envvar(5)

       Sun Enterprise Authentication Mechanism Guide

NOTES
       If you enter your username and kinit responds with this message:


       Principal unknown (kerberos)

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



SunOS 5.10                        17 Nov 1999                          SEAM(5)