19.2. Kerberos Terminology


Kerberos has its own terminology to define various aspects of the service. Before learning how kerberos works, it is important to learn the following terms.
authentication server (AS)
A server that issues tickets for a desired service which are in turn given to users for access to the service. The AS responds to requests from clients who do not have or do not send credentials with a request. It is usually used to gain access to the ticket-granting server (TGS) service by issuing a ticket-granting ticket (TGT). The AS usually runs on the same host as the KDC.
ciphertext
Encrypted data.
client
An entity on the network (a user, a host, or an application) that can receive a ticket from Kerberos.
credentials
A temporary set of electronic credentials that verify the identity of a client for a particular service. Also called a ticket.
credential cache or ticket file
A file which contains the keys for encrypting communications between a user and various network services. Kerberos 5 supports a framework for using other cache types, such as shared memory, but files are more thoroughly supported.
crypt hash
A one way hash used to authenticate users. While more secure than unencrypted data, it is fairly easy to decrypt for an experienced cracker.
GSS-API
The Generic Security Service Application Program Interface (defined in RFC-2743 published by The Internet Engineering Task Force) is a set of functions which provide security services. This API is used by clients and services to authenticate to each other without either program having specific knowledge of the underlying mechanism. If a network service (such as cyrus-IMAP) uses GSS-API, it can authenticate using Kerberos.
hash
A text generated number used to ensure that transmitted data has not been tampered with.
key
Data used when encrypting or decrypting other data. Encrypted data cannot be decrypted without the proper key or extremely good guessing.
key distribution center (KDC)
A service that issues Kerberos tickets, usually run on the same host as the ticket-granting server (TGS).
keytab (or key table)
A file that includes an unencrypted list of principals and their keys. Servers retrieve the keys they need from keytab files instead of using kinit. The default keytab file is /etc/krb5.keytab. The KDC administration server, /usr/kerberos/sbin/kadmind, is the only service that uses any other file (it uses /var/kerberos/krb5kdc/kadm5.keytab).
kinit
The kinit command allows a principal who has already logged in to obtain and cache the initial ticket-granting ticket (TGT). For more information about using the kinit command, refer to its man page.
principal (or principal name)
The principal is the unique name of a user or service allowed to authenticate using Kerberos. A principal follows the form root[/instance]@REALM. For a typical user, the root is the same as their login ID. The instance is optional. If the principal has an instance, it is separated from the root with a forward slash ("/"). An empty string ("") is considered a valid instance (which differs from the default NULL instance), but using it can be confusing. All principals in a realm have their own key, which for users is derived from a password or is randomly set for services.
realm
A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients.
service
A program accessed over the network.
ticket
A temporary set of electronic credentials that verify the identity of a client for a particular service. Also called credentials.
ticket-granting server (TGS)
A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC.
ticket-granting ticket (TGT)
A special ticket that allows the client to obtain additional tickets without applying for them from the KDC.
unencrypted password
A plain text, human-readable password.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.