|
Hopefully, this page is exactly what you are looking for, but if not, you can always find further assistance on Unix/Linux Forum!
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 provice a password only at the beginning of a
session. The Solaris Kerberos implementation is based on the
Kerberos 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 Ker-
beros 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 tran-
sparently, 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 life-
time 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 for-
wardable, 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:
SunOS 5.10 Last change: 1 Jun 2006 1
Standards, Environments, and Macros kerberos(5)
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 authenti-
cates 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 privileges from joe. The
SunOS 5.10 Last change: 1 Jun 2006 2
Standards, Environments, and Macros kerberos(5)
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 quali-
fied 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 mes-
sage:
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.10 Last change: 1 Jun 2006 3
Man(1) output converted with
man2html and wrapped by fishsponge
This page was generated on Wed Sep 12 11:27:50 GMT 2007
|
Your favourite pages:
No pages logged yet.
Trying to save cookie... Top 10 most popular pages:
CPAN man page (4290 hits)
(Suse Linux 10.1)
ssh man page (4160 hits)
(Suse Linux 10.1)
adv_cap_autoneg man page (3470 hits)
(Solaris 10 11_06)
sqlite3 man page (3370 hits)
(openSUSE 10.2)
svn man page (3036 hits)
(FreeBSD 6.2)
startproc man page (1856 hits)
(Suse Linux 10.1)
pprosetup man page (1576 hits)
(Solaris 10 11_06)
signal man page (1541 hits)
(Suse Linux 10.1)
netcat man page (1508 hits)
(Suse Linux 10.1)
ssh-socks5-proxy-connect man page (1450 hits)
(Solaris 10 11_06)
|
Man Pages 
