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
       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 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 principal 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 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 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 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 Authenti-
       cation 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 administrator or the System Administration Guide: Security Services.

SunOS 5.11							    1 Oct 2008							       kerberos(5)