SEAM man page on SunOS

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
SunOS logo
[printable version]

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 ser‐
			       vice,  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
	    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 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)
[top]

List of man pages available for SunOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net