How to configure Slave KDC (Backup KDC)

At this point, you will want to setup a backup or “slave” KDC.

Host Principal

First, add a host principal for each slave KDC. If you followed the instructions above for the primary KDC, then you will already have a host principal for the primary.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  addprinc -randkey host/second.example.com
 NOTICE: no policy specified for host/second.example.com@ EXAMPLE.COM; assigning "default"
 Principal "host/second.example.com@ EXAMPLE.COM " created.

Copy Configuration Files

Copy the following files from the primary KDC to each of the slave KDCs.

• /etc/krb5.conf
• /var/kerberos/krb5kdc/kdc.conf
• /var/kerberos/krb5kdc/kadm5.acl
• /etc/gssapi_mech.conf

Create kpropd.acl

Create an ACL file with all of the KDCs listed (both primary and backups). This file is /var/kerberos/krb5kdc/kpropd.acl and should look something like this.
host/coma.example.com@ EXAMPLE.COM

host/ second.example.com@ EXAMPLE.COM
Don’t put this file on the primary KDC or kadmin will not start.

Add Host Principal to Slave Key Table

On each slave KDC, add the host principal to the local key table.
 [root@second ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  ktadd host/ second.example.com

Start the Kerberos Propagation Daemon

On RHEL4 it is not necessary to create the database on the slave prior to starting the daemon. It was reported (thanks Louis) that on Fedora and perhaps Centos it is required. If the kprop daemon doesn’t start, you may need to create the database with the “kdb5_util create -s” command before starting it.
On each slave KDC, use the following command to enable the receipt of the kerberos database.
[root@second ~]# chkconfig kprop on
[root@second ~]# service kprop start
Starting Kerberos 5 Propagation Server:                    [  OK  ]

Propagate the Database

The next step is to propagate the database (manually) to each slave KDC. This is a two step process. First, dump the database to a file. Next, propogate the dumped file to each slave KDC.
 

[root@coma ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
 [root@coma ~]# kprop -f /var/kerberos/krb5kdc/slave_datatrans second.physik.unizh.ch
 Database propagation to second.physik.unizh.ch: SUCCEEDED

Create a Stash File

On each KDC you need to create a stash file. You will need the (really long and random) master key that you entered when you initially created the kerberos database.
 [root@second ~]# kdb5_util stash
 kdb5_util: Cannot find/read stored master key while reading master key
 kdb5_util: Warning: proceeding without master key
 Enter KDC database master key:

Start the Kerberos 5 KDC on each Slave

Now that the database is there, and you have created the stash file, you are ready to start the KDC Daemon.
 [root@second ~]# chkconfig krb5kdc on
 [root@second ~]# service krb5kdc start
 Starting Kerberos 5 KDC:                                   [  OK  ]
Do not start the Administration Daemon (kadmin) on the slaves. The Administration Daemon is used to add/remove/modify principals and to change passwords. When the database is replicated to the slaves, any changes that were made on the slaves would be lost. This also means that if the primary KDC goes down, it is not possible to make changes, or for users to modify their password.
If the primary KDC will be down for an extended period, you can make any slave the primary, but you will have to replicate the database back to the old primary when it becomes available. This requires manual intervention.

[ Read More ]

How to Create the Kerberos database

Create the database with the following command.

 [root@coma ~] kdb5_util create -s

This will prompt you for a password. You will only have to enter this password when you initially configure a slave KDC, so choose something large and random and store it in a secure place. Really, you may only have to enter this once more, so make it secure.

Add the first Administrative User

I do administration as root, so the first user I add is root/admin. The default realm is appended automatically, so the command to use is as follows.
 [root@coma ~] kadmin.local -q "addprinc root/admin"
Enter a password when prompted. You will need this password every time you administer the database.

Starting the Services

At this point it is necessary to enable and start the kerberos services.

 [root@coma ~] chkconfig kadmin on
 [root@coma ~] service kadmin start
 [root@coma ~] chkconfig krb5kdc on
 [root@coma ~] service krb5kdc start

To test if everything is working, run kadmin. By default, the current user appended with ‘/admin’ is used as the principle.
 [root@coma ~] kadmin
 Authenticating as principal root/admin@PHYSIK.UNIZH.CH with password.
 Password for root/admin@PHYSIK.UNIZH.CH:
 kadmin:  listprincs
 K/M@PHYSIK.UNIZH.CH
 kadmin/admin@PHYSIK.UNIZH.CH
 kadmin/changepw@PHYSIK.UNIZH.CH
 kadmin/history@PHYSIK.UNIZH.CH
 krbtgt/PHYSIK.UNIZH.CH@PHYSIK.UNIZH.CH
 root/admin@PHYSIK.UNIZH.CH
The additional principles have been created by the tool. They are required so leave them be.

Create a Host Principal for the KDC

Now you will want to create a host principal for the KDC. This is required for replication (see below). You also need to add this principal to the local key table.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@EXAMPLE.COM with password.
 Password for root/admin@EXAMPLE.COM:
 kadmin: addprinc -randkey host/coma.EXAMPLE.COM
 NOTICE: no policy specified for host/coma.example.com@EXAMPLE.COM; assigning "default"
 Principal "host/coma.example.com@EXAMPLE.COM" created.
 kadmin: ktadd host/coma.example.com

Setup the default Policy

You will want to create the default password policy at this point. All new accounts will have this policy enforced.
 [root@coma ~] kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin: add_policy -maxlife 180days -minlife 2days -minlength 8 -minclasses 3 -history 10 default
You can also add other policies and apply different policies to different principles. The different flags and their meaning are as follows.

Flag	Description
-maxlife	The is the maximum period before the password must be changed.
-minlife	This is the minimum time after a password change before it can be changed again. Without a minimum time, users can change their password multiple times and overflow the history (see below) and end up back with the same password.
-minclasses	This is the number of distinct character classes that must appear in the password. Character classes are uppercase letters, lowercase letters, number and symbols. Setting this to 2 for example would mean a password with at least one lowercase letter and a number would be valid.
-history	This is the number of previous passwords to keep. A password may not duplicate a prior password.

Changing the Maximum Renewal Time

Each principal has its own maximum renewal life. On RHEL4, new principals are created with a maximum renewal time of zero. This means you can get a renewable ticket, but they can never be renewed. Each principal must be manually changed to the desired maximum renewal time. In addition, the special principal krbtgt/REALM@REALM must be changed to reflect the maximum renewal time that any principal will have.
 [root@coma ~]# kadmin
 Authenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin:  modprinc -maxrenewlife 2weeks krbtgt/ EXAMPLE.COM @ EXAMPLE.COM
 Principal "krbtgt/ EXAMPLE.COM @ EXAMPLE.COM " modified.

Adding Principals

 [root@coma ~] kadmin
 uthenticating as principal root/admin@ EXAMPLE.COM with password.
 Password for root/admin@ EXAMPLE.COM:
 kadmin: addprinc -maxrenewlife 7days doug
The various options allow you to tune your password policy. 

[ Read More ]

Edit /var/kerberos/krb5kdc/kadm5.acl & /etc/gssapi_mech.conf

This file determines who can modify the kerberos database. You need to change the realm. 

*/admin@EXAMPLE.COM *
A brief note on kerberos users (called principles) is in order at this point. All standard users will be of the form username@REALM. When one tries to run the administration tool, it takes the current username, appends ‘/admin’ and uses that as the principle. If there is no username/admin@REALM principle, then that user cannot modify the database.

Change /etc/gssapi_mech.conf

There is a problem with this file on 64-bit architectures. It specifies the “lib” library path instead of the “lib64” path. You can just remove the path altogether and it will work on either. This is more important on a kerberos client, but a server can be a client as well, so you may as well change it on all machines.
# library                               initialization function
# ================================      ==========================
# The MIT K5 gssapi library, use special function for initialization.
libgssapi_krb5.so                       mechglue_internal_krb5_init

[ Read More ]

Edit /var/kerberos/krb5kdc/kdc.conf

In this file, only the realms section needs to be modified. it is important to change the key types as well. I can confirm that the setting below work perfectly in our environment. You may want to decide on appropriate values for the maximum life of each ticket, and for how long each ticket can be renewed. Reasonable values are 1 day and 1 week but your needs will vary. The values here are the absolute maximum that the KDC will issue. Each principal has its own maximum as well. 

[realms]
EXAMPLE.COM = {
 master_key_type = des3-hmac-sha1
 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal
 max_life = 25h
 max_renewable_life = 4w
}

[ Read More ]

Edit file /etc/krb5.com

There are a number of files that have to be manually edited on the server.

Edit /etc/krb5.conf

The stock version of this file will have EXAMPLE.COM or example.com everwhere you want to put your own realm or domain name. The two sections in question are libdefaults and domain_realm. The other sections do not need to be changed. In libdefaults, enter your own kerberos realm name. You may want to set the clock skew to a lower value (provided you are synchronizing time with ntp).
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
clockskew = 120
The realms section contains the settings for each realm. We have only one realm so it would look like the following. Note that you enter a kdc line for each Kerberos Domain Controller. You should have at least two.
[realms]
EXAMPLE.COM = {
 kdc = coma.example.com:88
 kdc = second.example.com:88
 admin_server = coma.example.com:749
 default_domain = example.com
}
In domain_realm, enter the mapping between DNS domains and your kerberos realm. If you are serving multiple DNS domains, you need to put them all here.
[domain_realm]
.zbox.example.com = EXAMPLE.COM
zbox.EXAMPLE.COM = EXAMPLE.COM
.example.com = EXAMPLE.COM
example.com = example.com
Finally, you may want to tweak the application defaults, for example to change the renew lifetime.
[appdefaults]
pam = {
  debug = false
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
  krb4_convert = false
}
kinit = {
  ticket_lifetime = 36000
  renew_lifetime = 36000
  forwardable = true
}

[ Read More ]

How to Domain-to-Realm Mapping

When a client attempts to access a service running on a particular server, it knows the name of the service (host) and the name of the server (foo.example.com), but because more than one realm may be deployed on your network, it must guess at the name of the realm in which the service resides. By default, the name of the realm is taken to be the DNS domain name of the server, upper-cased.

foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM

In some configurations, this will be sufficient, but in others, the realm name which is derived will be the name of a non-existant realm. In these cases, the mapping from the server's DNS domain name to the name of its realm must be specified in the domain_realm section of the client system's krb5.conf. For example:

[domain_realm]

.example.com = EXAMPLE.COM

example.com = EXAMPLE.COM

The above configuration specifies two mappings. The first mapping specifies that any system in the "example.com" DNS domain belongs to the EXAMPLE.COM realm. The second specifies that a system with the exact name "example.com" is also in the realm. (The distinction between a domain and a specific host is marked by the presence or lack of an initial ".".) The mapping can also be stored directly in DNS.

[ Read More ]

How to configuring a Kerberos 5 Client

Setting up a Kerberos 5 client is less involved than setting up a server. At a minimum, install the client packages and provide each client with a valid krb5.conf configuration file. While ssh and slogin are the preferred method of remotely logging in to client systems, Kerberized versions of rsh and rlogin are still available, though deploying them requires that a few more configuration changes be made.

1.     Be sure that time synchronization is in place between the Kerberos client and the KDC. Refer to "configuring kerberos 5 server" for more information. In addition, verify that DNS is working properly on the Kerberos client before configuring the Kerberos client programs.

2.     Install the krb5-libs and krb5-workstation packages on all of the client machines. Supply a valid /etc/krb5.conf file for each client (usually this can be the same krb5.conf file used by the KDC).

3.     Before a workstation in the realm can use Kerberos to authenticate users who connect using ssh or Kerberized rsh or rlogin, it must have its own host principal in the Kerberos database. The sshd, kshd, and klogind server programs all need access to the keys for the host service's principal. Additionally, in order to use the kerberized rsh and rlogin services, that workstation must have the xinetd package installed.

4.     Using kadmin, add a host principal for the workstation on the KDC. The instance in this case is the hostname of the workstation. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:

addprinc -randkey host/blah.example.com

5.     Now that the principal has been created, keys can be extracted for the workstation by running kadmin on the workstation itself, and using the ktadd command within kadmin:

ktadd -k /etc/krb5.keytab host/blah.example.com

6.     To use other kerberized network services, they must first be started. Below is a list of some common kerberized services and instructions about enabling them:

·        ssh — OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have GSSAPIAuthentication enabled. If the client also has GSSAPIDelegateCredentials enabled, the user's credentials are made available on the remote system.

·        rsh and rlogin — To use the kerberized versions of rsh and rlogin, enable klogin, eklogin, and kshell.

·        Telnet — To use kerberized Telnet, krb5-telnet must be enabled.

·        FTP — To provide FTP access, create and extract a key for the principal with a root of ftp. Be certain to set the instance to the fully qualified hostname of the FTP server, then enable gssftp.

·        IMAP — To use a kerberized IMAP server, the cyrus-imap package uses Kerberos 5 if it also has the cyrus-sasl-gssapi package installed. The cyrus-sasl-gssapi package contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP should function properly with Kerberos as long as the cyrus user is able to find the proper key in /etc/krb5.keytab, and the root for the principal is set to imap (created with kadmin). An alternative to cyrus-imap can be found in the dovecot package, which is also included in Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support GSS-API and Kerberos.

·        CVS — To use a kerberized CVS server, gserver uses a principal with a root of cvs and is otherwise identical to the CVS pserver.

[ Read More ]

How to Configuring a Kerberos 5 Server

When setting up Kerberos, install the KDC first. If it is necessary to set up slave servers, install the master first.

To configure the first Kerberos KDC, follow these steps:

1.      Ensure that time synchronization and DNS are functioning correctly on all client and server machines before configuring Kerberos. Pay particular attention to time synchronization between the Kerberos server and its clients. If the time difference between the server and client is greater than five minutes (this is configurable in Kerberos 5), Kerberos clients can not authenticate to the server. This time synchronization is necessary to prevent an attacker from using an old Kerberos ticket to masquerade as a valid user.

2.      It is advisable to set up a Network Time Protocol (NTP) compatible client/server network even if Kerberos is not being used. Red Hat Enterprise Linux includes the ntp package for this purpose. Refer to /usr/share/doc/ntp-<version-number>/index.html (where <version-number> is the version number of the ntp package installed on your system) for details about how to set up Network Time Protocol servers, and http://www.ntp.org for more information about NTP.

3.      Install the krb5-libs, krb5-server, and krb5-workstation packages on the dedicated machine which runs the KDC. This machine needs to be very secure — if possible, it should not run any services other than the KDC.

4.      Edit the /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf configuration files to reflect the realm name and domain-to-realm mappings. A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with the correct domain name — being certain to keep uppercase and lowercase names in the correct format — and by changing the KDC from kerberos.example.com to the name of the Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. For full details about the formats of these configuration files, refer to their respective man pages.

5.      Create the database using the kdb5_util utility from a shell prompt:

6.      /usr/kerberos/sbin/kdb5_util create –s The create command creates the database that stores keys for the Kerberos realm. The -s switch forces creation of a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc) prompts the user for the master server password (which can be used to regenerate the key) every time it starts.

7.      Edit the /var/kerberos/krb5kdc/kadm5.acl file. This file is used by kadmind to determine which principals have administrative access to the Kerberos database and their level of access. Most organizations can get by with a single line:

8.      */admin@EXAMPLE.COM  *  Most users are represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). In this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) are able to wield full power over the realm's Kerberos database.

9.      After kadmind has been started on the server, any user can access its services by running kadmin on any of the clients or servers in the realm. However, only users listed in the kadm5.acl file can modify the database in any way, except for changing their own passwords.

Note  :-- The kadmin utility communicates with the kadmind server over the network, and uses Kerberos to handle authentication. Consequently, the first principal must already exist before connecting to the server over the network to administer it. Create the first principal with the kadmin.local command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication. Type the following kadmin.local command at the KDC terminal to create the first principal:

/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"

10.  Start Kerberos using the following commands:

·         /sbin/service krb5kdc start

·         /sbin/service kadmin start

·         /sbin/service krb524 start

·         Add principals for the users using the addprinc command within kadmin. kadmin and kadmin.local are command line interfaces to the KDC. As such, many commands — such as addprinc — are available after launching the kadmin program. Refer to the kadmin man page for more information.

·         Verify that the KDC is issuing tickets. First, run kinit to obtain a ticket and store it in a credential cache file. Next, use klist to view the list of credentials in the cache and use kdestroy to destroy the cache and the credentials it contains.

Note

By default, kinit attempts to authenticate using the same system login username (not the Kerberos server). If that username does not correspond to a principal in the Kerberos database, kinit issues an error message. If that happens, supply kinit with the name of the correct principal as an argument on the command line (kinit <principal>).

 Once these steps are completed, the Kerberos server should be up and running.

 

[ Read More ]

Some important information about Kerberos

Warning

The Kerberos system can be compromised if a user on the network authenticates against a non Kerberos aware service by transmitting a password in plain text. The use of non-Kerberos aware services is highly discouraged. Such services include Telnet and FTP. The use of other encrypted protocols, such as SSH or SSL-secured services, however, is preferred, although not ideal.

Note
Kerberos depends on the following network services to function correctly.

·         Approximate clock synchronization between the machines on the network. :--  A clock synchronization program should be set up for the network, such as ntpd. Refer to /usr/share/doc/ntp-<version-number>/index.html for details on setting up Network Time Protocol servers (where <version-number> is the version number of the ntp package installed on your system).

·         Domain Name Service (DNS). :--  You should ensure that the DNS entries and hosts on the network are all properly configured. Refer to the Kerberos V5 System Administrator's Guide in /usr/share/doc/krb5-server-<version-number> for more information (where <version-number> is the version number of the krb5-server package installed on your system).

Tip

Administrators should be careful not to allow users to authenticate to most network services using Kerberos passwords. Many protocols used by these services do not encrypt the password before sending it over the network, destroying the benefits of the Kerberos system. For example, users should not be allowed to authenticate to Telnet services with the same password they use for Kerberos authentication.

[ Read More ]

How Kerberos Works

Kerberos differs from username/password authentication methods. Instead of authenticating each user to each network service, Kerberos uses symmetric encryption and a trusted third party (a KDC), to authenticate users to a suite of network services. When a user authenticates to the KDC, the KDC sends a ticket specific to that session back to the user's machine, and any Kerberos-aware services look for the ticket on the user's machine rather than requiring the user to authenticate using a password.  

When a user on a Kerberos-aware network logs in to their workstation, their principal is sent to the KDC as part of a request for a TGT from the Authentication Server. This request can be sent by the log-in program so that it is transparent to the user, or can be sent by the kinit program after the user logs in.  The KDC then checks for the principal in its database. If the principal is found, the KDC creates a TGT, which is encrypted using the user's key and returned to that user.  The login or kinit program on the client then decrypts the TGT using the user's key, which it computes from the user's password. The user's key is used only on the client machine and is not transmitted over the network.  The TGT is set to expire after a certain period of time (usually ten to twenty-four hours) and is stored in the client machine's credentials cache. An expiration time is set so that a compromised TGT is of use to an attacker for only a short period of time. After the TGT has been issued, the user does not have to re-enter their password until the TGT expires or until they log out and log in again. Whenever the user needs access to a network service, the client software uses the TGT to request a new ticket for that specific service from the TGS. The service ticket is then used to authenticate the user to that service transparently. 

[ Read More ]

Kerberos Terminology explanation

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.

1.      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 key distribution center (KDC).

2.      Cipher text  :-- Encrypted data.

3.      Client  :-- An entity on the network (a user, a host, or an application) that can receive a ticket from Kerberos.

4.      Credentials  :--  A temporary set of electronic credentials that verify the identity of a client for a particular service. Also called a ticket.

5.      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.

6.      Crypt hash  :--  A one-way hash used to authenticate users. These are more secure than using unencrypted data, but they are still relatively easy to decrypt for an experienced cracker.

7.      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.

8.      Hash :--  Also known as a hash value. A value generated by passing a string through a hash function. These values are typically used to ensure that transmitted data has not been tampered with.

9.      Hash function :--  A way of generating a digital "fingerprint" from input data. These functions rearrange, transpose or otherwise alter data to produce a hash value.

10.  Key :--  Data used when encrypting or decrypting other data. Encrypted data cannot be decrypted without the proper key or extremely good fortune on the part of the cracker.

11.  Key distribution center (KDC) :-- A service that issues Kerberos tickets, and which usually run on the same host as the ticket-granting server (TGS).

12.  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).

13.  Kinit :--  The kinit command allows a principal who has already logged in to obtain and cache the initial ticket-granting ticket (TGT). Refer to the kinit man page for more information.

14.  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.

15.  Realm  :-- A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients.

16.  Service  :-- A program accessed over the network.

17.  Ticket :-- A temporary set of electronic credentials that verify the identity of a client for a particular service. Also called credentials.

18.  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.

19.  Ticket-granting ticket (TGT)  :--  A special ticket that allows the client to obtain additional tickets without applying for them from the KDC.

20.  Unencrypted password  :--  A plain text, human-readable password. 

[ Read More ]

Kerberos and PAM

Kerberos-aware services do not currently make use of Pluggable Authentication Modules (PAM) — these services bypass PAM completely. However, applications that use PAM can make use of Kerberos for authentication if the pam_krb5 module (provided in the pam_krb5 package) is installed. The pam_krb5 package contains sample configuration files that allow services such as login and gdm to authenticate users as well as obtain initial credentials using their passwords. If access to network servers is always performed using Kerberos-aware services or services that use GSS API, such as IMAP, the network can be considered reasonably safe.

[ Read More ]

Advantages & Disadvantages of Kerberos

Advantages of Kerberos

Most conventional network services use password-based authentication schemes. Such schemes require a user to authenticate to a given network server by supplying their username and password. Unfortunately, the transmission of authentication information for many services is unencrypted. For such a scheme to be secure, the network has to be inaccessible to outsiders, and all computers and users on the network must be trusted and trustworthy. Even if this is the case, a network that is connected to the Internet can no longer be assumed to be secure. Any attacker who gains access to the network can use a simple packet analyzer, also known as a packet sniffer, to intercept usernames and passwords, compromising user accounts and the integrity of the entire security infrastructure. The primary design goal of Kerberos is to eliminate the transmission of unencrypted passwords across the network. If used properly, Kerberos effectively eliminates the threat that packet sniffers would otherwise pose on a network.

Disadvantages of Kerberos

Although Kerberos removes a common and severe security threat, it may be difficult to implement for a variety of reasons:

1.     Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious, as there is no automated mechanism to perform this task.

2.     Kerberos has only partial compatibility with the Pluggable Authentication Modules (PAM) system used by most Red Hat Enterprise Linux servers. Refer to  "kerberos and pam" for more information about this issue.

3.     Kerberos assumes that each user is trusted but is using an untrusted host on an untrusted network. Its primary goal is to prevent unencrypted passwords from being transmitted across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication — called the Key distribution center (KDC) -- the entire Kerberos authentication system is at risk.

4.     For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. Applications modified in this way are considered to be Kerberos-aware, or kerberized. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client communicate. Again, this may require extensive programming. Closed-source applications that do not have kerberos support by default are often the most problematic. 
5.   Kerberos is an all-or-nothing solution. If Kerberos is used on the network, any unencrypted passwords transferred to a non-Kerberos aware service is at risk. Thus, the network gains no benefit from the use of Kerberos. To secure a network with Kerberos, one must either use Kerberos-aware versions of all client/server applications that transmit passwords unencrypted, or not use any such client/server application at all.

[ Read More ]

What is Kerberos?

System security and integrity within a network can be unwieldy. It can occupy the time of several administrators just to keep track of what services are being run on a network and the manner in which these services are used.

Further, authenticating users to network services can prove dangerous when the method used by the protocol is inherently insecure, as evidenced by the transfer of unencrypted passwords over a network using the traditional FTP and Telnet protocols.
Kerberos is a way to eliminate the need for protocols that allow unsafe methods of authentication, thereby enhancing overall network security.

Kerberos is a network authentication protocol created by MIT, and uses symmetric-key cryptography to authenticate users to network services, which means passwords are never actually sent over the network.
Consequently, when users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted.

[ Read More ]