kerberos man page on Solaris

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

kerberos(5)	      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  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/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. 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(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)

NOTES
       In  previous releases of the Solaris operating system, the Solaris Ker‐
       beros implementation was referred to as the "Sun Enterprise Authentica‐
       tion Mechanism" (SEAM).

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

	 Principal unknown (kerberos)

       you have not been registered as a Kerberos user. See your system admin‐
       istrator or the .

SunOS 5.10			  1 Jun 2006			   kerberos(5)
[top]

List of man pages available for Solaris

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