The word kerberos have a roots in Greek mithology and it is connected to legend of Cerberus and simboloze a three-head dog. Today kerberos stands for strong and powerfull protocol that enables secure, once signed and trusted third-party authentaticion service in network environment independent by its size or operating system used.This is accomplished without relaying on authentication by host operating system,without basing trust on host addresses,without requiring physical security and under assumption that packets traveling along the network can be read, modified and inserted at will. The Kerberos project was started by MIT in USA and idea of Kerberos protocol was borned there as try to resolove authentacition and security problems in network. In years leter kerberos become very popular security system and is used by many universities and corporations around the world. The Kerberos was initaly developed in the USA but US laws imposing some restrictions on use programs/functions that have possiblily of cripting. Limited by use of kerberos outside the USA, people at Royal Institute of Technology in Sweden developed version of kerberos which has not any export restrictions which has a name Heimdal. Today, two Kerberos implementations are freely available
Main kerberos features can be presented as follows
"Kerberos client" is any entity that gets a service ticket for a Kerberos service. A client is typically a user, but any principal can be a client (unless the administrator has explicitly forbidden this principal to be a client)
Kerberos server" generally refers to the Key Distribution Center,or the KDC for short. The KDC implements the Authentication Service (AS)and the Ticket Granting Service (TGS). The KDC has a copy of every password associated with every principal. For this reason, it is absolutely vital that the KDC be as secure as possible.
The term "application server" generally refers to Kerberized programs that clients communicate with using Kerberos tickets for authentication.The Kerberos telnet daemon (telnetd) is an example of an application server.
The authentication process proceeds as follows: A client sends a request to the authentication server (AS) requesting "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The client transmits the ticket (which contains the client's identity and a copy of the session key, all encrypted in the server's key) to the server. The session key (now shared by the client and server) is used to authenticate the client,and may optionally be used to authenticate server.
Kerberos requires you to run two deamons on a secure server. The Key Distribution Center (KDC) deamon handles all password verification requests and the generation of Kerberos credentials, called Ticket Granting Tickets (TGTs). A second deamon, the Kerberos Administration deamon, allows you to add, delete and modify accounts remotely without logging in to the computer running the Kerberos deamons. It also handles password change requests from users. With Kerberos, only a password change ever requires transmitting a strongly encrypted password over the network.
The Kerberos KDC grants a temporary credential, a TGT, to the account during the process of authenticating the user. Typically, these credentials have a lifetime of 10 or 24 hours. This lifetime can be configured and should be no longer than 24 hours, in case the TGT is stolen; a thief could use it only for the remaining TGT lifetime. The credential expiration causes no issues if you are using Kerberos only for authentication, as described in this article. However, if you are using Kerberized services, you need to train your users to obtain new credentials after their current ones expire, even though they still are logged in.
Kerberos introduced a new service, called the ticket granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. They are often referred to collectively as the KDC--the Key Distribution Center. The purpose of the TGS is to add an extra layer of indirection so that the user only needs to enter in a password once; the ticket and session key obtained from that password is used for all further tickets. Before accessing any regular service, the user requests a ticket from the AS to talk to the TGS. This ticket is called the ticket granting ticket, or TGT; it is also sometimes called the initial ticket. The session key for the TGT is encrypted using the user's long-term key, so the password is needed to decrypt it from the AS's response to the user. After receiving the TGT, any time that the user wishes to contact a service, must requests a ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with the user's secret key, but with the session key that came with the TGT, so the user's password is not needed to obtain the new session key (the one that will be used with the end service). The advantage of this method is that while passwords usually remain valid for defined period of time, the TGT is good only for a fairly shorter defined period. Afterwards, the TGT is not usable by anyone, including the user or any attacker. This TGT, as well as any tickets that you obtain using it, are stored in the credentials cache
For this case we can can use various GNU/Linux, Unix system. Debian GNU/Linux using apt-get tool we get all packets needed for this. Debian version support both MIT version and Heimdal version of Kerberos. Set-up is similar for both. We use MIT's Kerberos distribution for this case and first get neccesary packets using Debian apt-get tool
apt-get install -s krb5-admin-server Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: krb5-config krb5-kdc krb5-user The following NEW packages will be installed: krb5-admin-server krb5-config krb5-kdc krb5-user 0 upgraded, 4 newly installed, 0 to remove and 92 not upgraded. Inst krb5-config (1.17 Debian:testing) Inst krb5-user (1.6.dfsg.1-7 Debian:testing) Inst krb5-kdc (1.6.dfsg.1-7 Debian:testing) Inst krb5-admin-server (1.6.dfsg.1-7 Debian:testing) Conf krb5-config (1.17 Debian:testing) Conf krb5-user (1.6.dfsg.1-7 Debian:testing) Conf krb5-kdc (1.6.dfsg.1-7 Debian:testing) Conf krb5-admin-server (1.6.dfsg.1-7 Debian:testing)
We have to change and configure files krb5.conf and kdc.conf
and arrage them to suit to our system.
krb5.conf
[libdefaults]
default_realm = LAB.FI.MUNI.CZ
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
LAB.FI.MUNI.CZ = {
kdc = speo.lab.fi.muni.cz
admin_server =speo.lab.fi.muni.cz
kdc.conf
[kdcdefaults]
kdc_ports = 750,88
[realms]
LAB.FI.MUNI.CZ = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type =des3-hmac-sha1
supported_enctypes=des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4
des:norealm des:onlyrealm des:afs3
default_principal_flags= +preauth
In case we have some kind of firewall in our network it is necessary to know which ports/protocols use kerberos server when comunicate with client/s and vise-versa
PAM stands for Plugable Authentication Module and was developed by SUN in 1997. Today PAM is included in almost all GNU/Linux and Unix distributions. PAM reduces authentication problems and system administrator can use the same database for every login proces on system.
PAM file system layout is like it is shown on picture below
/---------|
|
|-----lib--------libpam.so.0
| |
| |
| |
| ------security----|
| |
| |----------pam_unix.so
| |----------pam_deny.so
|
|
|----------etc----pam.conf
| |
| |
| |
| |
| --pam.d-|
| | |-----login
| | |-----ssh
| | |-----other
| |
| |
| |-------security---|
| |
| |----access.conf
| |----pam_mount.conf
|
|
-----usr---|
|---include---|
|
|----security---|
|
|----pam_modules.h
The PAM aware applications are linked against PAM library and it is usually located in /lib directory libpam-X.so.0 where X is version number. Any PAM implementation is consisted by set of modules. The modules are shared objects and can be dinamicaly loaded as the PAM configuration requests them. The shared objects are tipicaly located in the lib/security ( for GNU/Linux ) or /usr/lib ( FreeBSD ) and have pam suffix as their names. The cofiguration of pam can be done on two ways. First to put all parameters into one file pam.conf or split configuration by service under pam.d directory
The four types of PAM services areVerifies the validity of the account, whether it's expired, enabled, if login for that service is possible for that particular account. This is when you should check for /etc/nologin, presence in /etc/ftpusers, valid shell, and so on
Handle the authentication of users: asks and checks password values, One-Time Passwords, smartcards, biometric scans, USB keys, and so on. This is probably the most critical facility as a mistake done by this chain might allow an attacker to spoof the identity of an user.
Manages the session opened for the user, by setting up and destroying the environment as needed, this is the only chain that is called twice: at login and logout. Here you should call modules that handle mounting, chrooting, or changing various permissions.
Takes care of changing the authentication data for the user
Each service can use PAM in four different stages of authentication proces and in PAM these stages are called management groups. A module provides the functionality for one or more management groups but it it easier to think about it as different module for each group.
Stacking in PAM is very useful feature and this means that we can for each management group define a set of stack modules that can be called. When application call PAM library function the PAM runtime function will call each authentication function in each module. Here is important to say that the order of calling is defined in configuration file and that order should be very carefully designed because different orders means different
In PAM are the following control flags
Requisite
Required
Sufficient
Optional
It is very important to make plan of PAM implementation because in case of misconfigured of pam config files it will not be possible to log into system ( sulogin command does not use PAM and in that case the root password would be required to boot machine into single user mode and fix problem ) Some factors about which should take care can be
Futher process is adjusting PAM for specific needs of particular system and that can be varios from one system to another depending on what is purpose and required level of security