🌐 🇵🇱 Polski · 🇬🇧 EN
Kerberos is a network authentication protocol. It was designed to provide strong authentication for client/server applications using secret-key cryptography. A free implementation of this protocol was created at the Massachusetts Institute of Technology (MIT). Many commonly used network protocols lack any security during data transmission. This fact is exploited by malicious hackers using network sniffing tools. Kerberos provides a solution that significantly increases the security of data transmitted over the network. It allows for verifying the identity of a client trying to access a server, and vice versa – the server can prove its identity to the client. This protocol also enables the encryption of all communication while maintaining data integrity.
Kerberos is a secure network authentication system based on verifying permissions using so-called tickets, which are secured with a secret encryption key. When using this mechanism, the relationship typically involves three components:
- KDC - Key Distribution Center
- Application Server
- Client (machines, user terminals)
Tickets are issued by a central server called the KDC (Key Distribution Server). A local domain consists of all hosts using the same KDC to issue tickets, which can be compared to a NIS or LDAP domain. By default, the DNS domain for all members is named KERBEROS. For example, the KERBEROS domain for hosts in the example.com domain might be EXAMPLE.COM.
Every host running a network service that supports Kerberos authentication is called an application server. Each application server and each Kerberos user has an identity and a password assigned to it. The KDC stores the passwords of all users and services operating within a given domain. Users initially log in using their password, after which they are issued tickets by the KDC. Such a ticket allows the user to authenticate within the Kerberos domain and provides access to a specific service on another host where that service is running, assuming that host is also in the Kerberos domain (realm). Access to the service is possible without re-entering the password. It is standard practice to refer to a Kerberos domain as a - Kerberos realm
PRINCIPALS
Principals - a unique name, an identifier in the Kerberos realm that defines a user or a network service. A principal consists of three parts: primary, instance, and realm. Each principal has a key-encrypted password that must be remembered by the user. In the case of services, their passwords are stored in a keytab file. The KDC knows all passwords.
Each principal takes the following form:
primary/instance@REALM
where the "instance" element is optional, and if "REALM" is not provided, it takes the value defined in the file: /etc/krb5.conf.
For users, the "primary" value is their username. The "instance" value is usually not present and is used to describe roles or types of administrative access.
testowy@EXAMPLE.COM
testowy/admin@EXAMPLE.COM
The above forms of "principals" can be used for the same user, however, from the Kerberos point of view, they have separate passwords. The first version uses standard authentication. The second version is used when there is a need to perform work with administrative privileges.
A machine that is a service provider - an application server - must also have its own "principals" database. Here, however, we are talking about "principals" defining services, e.g.:
http/host1.example.com@EXAMPLE.COM
ftp/host1.example.com@EXAMPLE.COM
The above "principals" can belong to the httpd and ftp services running on the host1 machine. This host must allow network logins using sshd and rlogind. Services store their passwords in a keytab file.
AUTHENTICATION
The Key Distribution Center consists of:
- Authentication Server (AS) - grants TGTs to clients who want to use services available within the environment secured by Kerberos
- Ticket-Granting-Service (TGS) - a service that grants tickets based on a TGT
TGT - this is a special ticket (token) granted to a client (principal) with a confirmed identity in the Kerberos environment. This ticket allows the client to request further tickets for individual services.
Authorization process
- The user enters their login and password
- The service the client is logging into sends a request for a TGT for this "principal" to the KDC
- The KDC sends back a TGT encrypted with the user's password to the service
- If the service can decrypt the password contained in the TGT using the password provided by the user, the user will be logged into the service.
So, upon the first login, the user provides their username and password, which they use to authenticate with the Kerberos service. The username is converted into a "principal" format, and then a request is sent to the KDC for a TGT for the user, allowing them to request further tickets for selected services. The KDC creates a session encryption key, which will be used as the TGT. It keeps one copy locally, encrypts the second copy with the user's password, and sends it to the client.
- The client sends a request for a ticket for a given service to the KDC using the previously received TGT
- The KDC sends two identical copies to the client
- One copy is encrypted using the TGT
- The second copy is encrypted with the service's password
- The client sends to the service
- The ticket encrypted with the service's password
- A timestamp encrypted using the ticket
The client uses the current TGT to decrypt the first copy of the ticket. Then, it creates an authenticator by encrypting the current timestamp using the previously decrypted ticket. The client sends the second copy of the ticket (encrypted with the service's password) along with the authenticator to the target service.
After receiving the ticket, the service decrypts it with its own password, which is stored in the keytab file. Since only the service and the KDC know the password, the service is certain that the ticket originated from the KDC. Next, the service decrypts the authenticator using the decrypted ticket. If the operation is successful, the service is certain that the client was able to decrypt the ticket received from it using a password matching the one stored in the KDC.
TICKET AND AUTHENTICATOR
A ticket allows a client to access a given service. A ticket consists of:
- Server name
- Client name
- Client IP address
- Timestamp
- Ticket lifetime
- Session key
A ticket is valid as long as its lifetime allows and can be used multiple times during that period.
The authenticator's task is to confirm that a given ticket is genuine. The authenticator is created every time a client wants to access a service. The authenticator contains:
- Client name
- Client IP address
- Client timestamp
The authenticator is encrypted with the session key. The timestamp in the authenticator serves as protection against automated (looped) attacks. Therefore, all hosts in the Kerberos realm must have accurate time synchronization (NTP).
The main Kerberos service configuration file is /etc/krb5.conf. This file stores information regarding settings and KDC locations. By default, the file is located in /etc/, but this can be changed by setting the KRB5_CONFIG environment variable.
Sections of the krb5.conf file :
By default, the /etc/krb5.conf file looks like this:
[root@station1 ~]# vim /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com
admin_server = kerberos.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
The system must have the appropriate krb5-server and krb5-libs packages. Basic settings are implemented in the /etc/krb5.conf file. Additional settings are configured in /var/kerberos/krb5kdc/kdc.conf, where we can control various specific settings. Finally, there is access control, which can be set in the /var/kerberos/krb5kdc/kadm5.acl file.
Step 1 - installing the required packages.
# yum install krb5-server
# yum install krb5-libs
# kdb5_util create -r STATION1.EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'STATION1.EXAMPLE.COM',
master key name 'K/M@STATION1.EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
KERBEROS SERVICE COMPONENTS
- Packages
- krb5-server
- krb5-libs
- Services
- krb5kdc - (/usr/kerberos/sbin/krb5kdc) - Key Distribution Service
- kadmind - (/usr/kerberos/sbin/kadmind) - Administrative database service
- kpropd - (/usr/kerberos/sbin/kpropd) - Database maintenance service on slave servers
- Ports
- UDP : 88, 464
- TCP : 88, 749, 754
- Configuration files
- /etc/krb5.conf - Main configuration file
- /var/kerberos/krb5kdc/
- kdc.conf - Server configuration specification
- kadm5.acl - Access control to the administrative database
- kpropd.acl - Slave machine permissions
- principal - Kerberos service database
- Related topics
- krb5-workstation
- pam_krb5
- ntp
MAIN CONFIGURATION FILE /etc/krb5.conf
The main Kerberos service configuration file is /etc/krb5.conf. This file stores information regarding settings and KDC locations. By default, the file is located in /etc/, but this can be changed by setting the KRB5_CONFIG environment variable.
Sections of the krb5.conf file :
- [libdefaults] - controls default Kerberos libraries.
- [realms] - settings regarding the Kerberos "realm" (domain).
- [domain-realm] - settings defining connection maps to remote hosts in the domain
- [capaths] - authentication paths for non-hierarchical cross-realm
- [appdefaults] - Kerberos settings for selected applications and services
- [plugins] - controls settings for additional modules
By default, the /etc/krb5.conf file looks like this:
[root@station1 ~]# vim /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com
admin_server = kerberos.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
INSTALLING KDC (KEY DISTRIBUTION CENTER)
The system must have the appropriate krb5-server and krb5-libs packages. Basic settings are implemented in the /etc/krb5.conf file. Additional settings are configured in /var/kerberos/krb5kdc/kdc.conf, where we can control various specific settings. Finally, there is access control, which can be set in the /var/kerberos/krb5kdc/kadm5.acl file.
Step 1 - installing the required packages.
# yum install krb5-server
# yum install krb5-libs
You will also need a Kerberos database, which we must create.
Step 2 - Creating the Kerberos database
To create the database, we use the kdb5_util tool, which allows the administrator to perform low-level operations regarding the Kerberos database.
# kdb5_util create -r REALM -s
example:
# kdb5_util create -r station1.example.com -s
NOTE!
If you are doing this for educational or testing purposes, you may wait a long time for the prompt asking for the database password. This happens because random data generated based on disk or network operations is needed, and these types of operations must take place in the system. On a machine set up in, for example, VirtualBox, not much will be happening, and we must trigger such operations artificially.
Such a trigger can look like this:
# for i in `seq 1 10000`; do echo $i > dupa$i; sync; sync; done
After performing the above operation, you will be asked to provide the master database password:
# kdb5_util create -r STATION1.EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'STATION1.EXAMPLE.COM',
master key name 'K/M@STATION1.EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Step 3 - Editing the kdc.conf file
In the /var/kerberos/krb5kdc/kdc.conf file, we edit the [realms] section:
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[realms]
STATION1.EXAMPLE.COM = {
master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
Step 5 - Configuration in the kadm5.acl file
BIBLIOGRAPHY
- Kerberos (Tomasz Okniński)
- Explain like I'm 5: Kerberos
- Configuring a Kerberos 5 server - RedHat Customer Portal
- Documentation located in /usr/share/doc/krb5-server-1.10.3
- The MIT Kerberos Administration's - How to (PDF)
- Kerberos-based NIS authorization (PDF)
- Using the DirectControl Kerberos Tools (PDF)
- Secure your system with Kerberos
- krb5.conf - MIT Kerberos Documentation
Comments