👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

OpenSolaris 2009.06 - man page for kerberos (opensolaris section 5)

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," authen-
       ticates 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  net-
       work  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. Poli-
       cies 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  kde-
       stroy(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 security service: integrity, which authen-
       ticates	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 principals, even if the same user uses them; joe/admin has differ-
       ent 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 principals. 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 Authentication 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 Sys-
       tem Administration Guide: Security Services.

SunOS 5.11				    1 Oct 2008				      kerberos(5)


All times are GMT -4. The time now is 07:19 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password