Kerberos and PAM

Elvir Kuric,



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

Kerberos 5 implementations also are included in Microsoft Windows (2000 and later), in Sun's Solaris (SEAM, Solaris 2.6 and above) and Apple's Mac OS X. Also Kerberos is supported in *BSD implementations of Unix

Kerberos features

Main kerberos features can be presented as follows

  • Single sign-on This feature means that users should log-in only once and and gain access to all network resources that support kerberos
  • These features allows kerberos to be very good solution in network and enable it to be used in heterogenous environment of operating systems. Above mentioned three heads in Kerberos sense should simbolize
  • Kerberos messages We can differ the following types of messages kerberos use in communication

    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.

    Ticket Granting Service

    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

  • Kerberos implementation

    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.
            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
    	  LAB.FI.MUNI.CZ = {
              kdc =
        kdc_ports = 750,88
        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

    Kerberos Packet Filtering

    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


    Kerberos drawbacks


    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 filesystem layout

    PAM file system layout is like it is shown on picture below

    	  |            |
    	  |            |
    	  |            |
    	  |            ------security----| 
    	  |                              |
    	  |                              |
    	  |                              |  
    	  |               |   
    	  |               |
              |               |
              |               | 
    	  |               --pam.d-|
    	  |               |       |-----login
              |               |       |-----ssh
    	  |               |       |-----other    
    	  |               |
    	  |               |
    	  |               |-------security---|
    	  |                                  |
    	  |                                  |----access.conf
    	  |                                  |----pam_mount.conf

    The PAM aware applications are linked against PAM library and it is usually located in /lib directory 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 are

    PAM management groups

    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.

    With PAM, these management functions are performed from PAM modules. This allows an administrator to dyamically configure authentication schemes for all PAM-enabled system utilities and applications by adding and removing PAM modules on the running system. The four management groups shown above also provide the basis for configuring PAM. Each PAM-enabled program requires authentication tasks from one or more of these groups. The PAM configuration files specify which groups are required by each PAM-enabled application, and which PAM modules are to be invoked for each group within each application. The administrator can easily customize system authentication schemes by specifying alternate PAM module(s) to be invoked for particular applications. Programs that use PAM to perform authentication are said to be PAM-enabled. PAM-enabled programs can be third party applications such as samba, as well as standard system utilities and services such as login, passwd, and etc.

    Stacking in PAM

    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

    PAM control flags

    In PAM are the following control flags

    In version of Solaris leter than 8 there is richer set of control flags


  • The requisite control flag is the stronges one and this means if the module is flagged as requisite and not load succesfully PAM will report a failure
  • Required

  • The required control flag is executed and if it fails return value is remembered but execution is not stopped and continue to the next module. When all stack of modules is executed and at least one of required modules is not executed the failure is returned to application. In other words the failure is connected with the first failed module
  • Sufficient

  • The processing of flags is stopped if a sufficient module returns ok and any sufficient module before it did not failed. If there is any reqired modules after sufficient they are not called at all
  • Optional

  • When the module is flagged as optional a failure does not influence on execution of stack as in case of requisite flags. In this case return code is ignored
  • Planing PAM implemention

    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