v5srvtab man page on DigitalUNIX

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

v5srvtab(4)							   v5srvtab(4)

NAME
       v5srvtab - Contains the service key table

SYNOPSIS
       /krb5/v5srvtab

DESCRIPTION
       The /krb5/v5srvtab file is the default service key table file that con‐
       tains the principal entries that you extract from the  principal	 data‐
       base  on the Key Distribution Center (KDC). Each service principal must
       have a principal entry in the principal database.

       Unattended services that must authenticate using	 a  service  principal
       account	require that a key be added to the service key table file. The
       secured application sends the service ticket to	the  secured  service,
       requesting  a connection. The secured service decrypts the ticket using
       its key found in the service key table file. If the service can decrypt
       the  ticket, it knows that the user was previously authenticated and is
       who the user claims to be.  The	service	 then  performs	 authorization
       checks. If the checks are successful, a connection is established.

   Data Types
       There are many types of service key table files; available types depend
       on compile-time definitions. The available types include the following:
       A  memory-based	service	 key table file stores credentials in volatile
       memory. It is useful in environments where no file  system  exists,  or
       for  applications  that require only temporary use of the extracted key
       (or where putting those keys on disk can cause problems).

	      A typical use of a memory-based service key table file is	 as  a
	      temporary	 storage location for use by applications that need to
	      merge, edit, or consolidate a file-based service key table  file
	      without incurring the overhead of file-based I/O.

	      In  most environments, a MEM service key table is not persistent
	      and lives only as long as the process that created  the  service
	      key  table.  Thus, it is not suitable to store keys that must be
	      passed between processes. You can, however, use it to pass  keys
	      within a process.

	      Multiple	accesses  to  the service key table file are supported
	      through reference	 counting.  As	long  as  the  file  has  been
	      accessed by csfC5resolve_kt() at least one more time than it has
	      been closed by csfC5close_kt(), it will not be  destroyed	 by  a
	      call  to csfC5close_kt(). To allow opening of an existing memory
	      service key table file by additional calls to csfC5resolve_kt(),
	      the  kt  structure  name	contains  a  special  name that can be
	      resolved with the memory service key table file address. To cre‐
	      ate  a  name  string that csfC5resolve_kt() can use, concatenate
	      the kt.tname field, a ':', and the kt.name field. This technique
	      works  for  the  FILE  service  key table as well.  A file-based
	      (nonvolatile) service key table file stores keys in a disk file.
	      For multiuser systems, the file allows access only to the appli‐
	      cations needing access to the service key table file.   Identify
	      FILE type to indicate that the service key table file should not
	      be modified by the operation.  A file-based  (nonvolatile)  ser‐
	      vice  key	 table	stores	keys in a disk file. Both the FILE and
	      WFILE types can be used to refer to the same file storage	 loca‐
	      tion.  However,  use the WFILE type to indicate that the service
	      key table file should be treated as a writable file  during  the
	      operation.

       Specify	a  service  key	 table file with a name in the form TYPE:name,
       where all components are optional. The  type  specifies	MEM,  FILE  or
       WFILE;  the  interpretation of the name is specific to a type. The name
       specifies the name of the service key table file. The default name  for
       the  FILE  and WFILE types is /krb5/v5srvtab. The names NULL, "", and :
       are all equivalent, and all specify that the default service key	 table
       name should be used.

       The  type or name component can be empty. The following table lists the
       possible combinations and results:

       ───────────────────────────────────────────────────────────────────────
       Component Type	Component Name	 Behavior      Key  Table  Type	  and
						       Name
       ───────────────────────────────────────────────────────────────────────
       Empty		Empty		 Default       FILE:/krb5/v5srvtab
					 type	 and
					 name.
       Specified	Empty		 Default       FILE:/krb5/v5srvtab
					 name	 for
					 type.	       WFILE:/krb5/v5srvtab

						       MEM: no default name.
       Empty		Specified	 Default       FILE:/keytablename
					 type	with
					 specified
					 name.
       Specified	Specified	 Use  speci‐   TYPE:/keytablename
					 fied	type
					 and name.
       ───────────────────────────────────────────────────────────────────────

SEE ALSO
       Commands: kinit(1) ktutil(1)

								   v5srvtab(4)
[top]

List of man pages available for DigitalUNIX

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