1kerberos(5) Standards, Environments, and Macros kerberos(5)
2
6 kerberos - overview of Solaris Kerberos implementation
7
9 The Solaris Kerberos implementation, hereafter sometimes shortened to
10 "Kerberos," authenticates clients in a network environment, allowing
11 for secure transactions. (A client may be a user or a network service.)
12 Kerberos validates the identity of a client and the authenticity of
13 transferred data. Kerberos is a single-sign-on system, meaning that a
14 user needs to provide a password only at the beginning of a session.
15 The Solaris Kerberos implementation is based on the Kerberos(TM) system
16 developed at MIT, and is compatible with Kerberos V5 systems over het‐
17 erogeneous networks.
18 Kerberos works by granting clients tickets, which uniquely identify a
21 client, and which have a finite lifetime. A client possessing a ticket
22 is automatically validated for network services for which it is enti‐
23 tled; for example, a user with a valid Kerberos ticket may rlogin into
24 another machine running Kerberos without having to identify itself.
25 Because each client has a unique ticket, its identity is guaranteed.
26 To obtain tickets, a client must first initialize the Kerberos session,
29 either by using the kinit(1) command or a PAM module. (See
30 pam_krb5(5)). kinit prompts for a password, and then communicates with
31 a Key Distribution Center (KDC). The KDC returns a Ticket-Granting
32 Ticket (TGT) and prompts for a confirmation password. If the client
33 confirms the password, it can use the Ticket-Granting Ticket to obtain
34 tickets for specific network services. Because tickets are granted
35 transparently, the user need not worry about their management. Current
36 tickets may be viewed by using the klist(1) command.
37 Tickets are valid according to the system policy set up at installation
40 time. For example, tickets have a default lifetime for which they are
41 valid. A policy may further dictate that privileged tickets, such as
42 those belonging to root, have very short lifetimes. Policies may allow
43 some defaults to be overruled; for example, a client may request a
44 ticket with a lifetime greater or less than the default.
45 Tickets can be renewed using kinit. Tickets are also forwardable,
48 allowing you to use a ticket granted on one machine on a different
49 host. Tickets can be destroyed by using kdestroy(1). It is a good idea
50 to include a call to kdestroy in your .logout file.
51 Under Kerberos, a client is referred to as a principal. A principal
54 takes the following form:
55 primary/instance@REALM
57 primary A user, a host, or a service.
61 instance A qualification of the primary. If the primary is a host —
64 indicated by the keyword host— then the instance is the
65 fully-qualified domain name of that host. If the primary is
66 a user or service, then the instance is optional. Some
67 instances, such as admin or root, are privileged.
68 realm The Kerberos equivalent of a domain; in fact, in most cases
71 the realm is directly mapped to a DNS domain name. Kerberos
72 realms are given in upper-case only. For examples of prin‐
73 cipal names, see the EXAMPLES.
74 By taking advantage of the General Security Services API (GSS-API),
78 Kerberos offers, besides user authentication, two other types of secu‐
79 rity service: integrity, which authenticates the validity of transmit‐
80 ted data, and privacy, which encrypts transmitted data. Developers can
81 take advantage of the GSS-API through the use of the RPCSEC_GSS API
82 interface (see rpcsec_gss(3NSL)).
83
85 Example 1 Examples of valid principal names
86 The following are examples of valid principal names:
89 joe
92 joe/admin
93 joe@ENG.ACME.COM
94 joe/admin@ENG.ACME.COM
95 rlogin/bigmachine.eng.acme.com@ENG.ACME.COM
96 host/bigmachine.eng.acme.com@ENG.ACME.COM
97 The first four cases are user principals. In the first two cases, it is
102 assumed that the user joe is in the same realm as the client, so no
103 realm is specified. Note that joeand joe/admin are different princi‐
104 pals, even if the same user uses them; joe/admin has different privi‐
105 leges from joe. The fifth case is a service principal, while the final
106 case is a host principal. The word host is required for host princi‐
107 pals. With host principals, the instance is the fully qualified host‐
108 name. Note that the words admin and host are reserved keywords.
109
112 kdestroy(1), kinit(1), klist(1), kpasswd(1), krb5.conf(4),
113 krb5envvar(5)
114 System Administration Guide: Security Services
117
119 In previous releases of the Solaris operating system, the Solaris Ker‐
120 beros implementation was referred to as the "Sun Enterprise Authentica‐
121 tion Mechanism" (SEAM).
122 If you enter your username and kinit responds with this message:
125 Principal unknown (kerberos)
127 you have not been registered as a Kerberos user. See your system admin‐
132 istrator or the System Administration Guide: Security Services.
133SunOS 5.11 1 Oct 2008 kerberos(5)