Zurück

Configure Oracle Clients to use KERBEROS for Authentication

 

Overview

Kerberos provides a secure, single-sign-on, trusted, third-party mutual authentication service. Kerberos is secure since it never transmits passwords over the network in the clear. Kerberos is unique in its use of tickets, time-limited cryptographic messages that prove a user's identity to a given server without sending passwords over the network or caching passwords on the local user's hard disk. Single-sign-on means that end users only need to log in once to access all network resources that support Kerberos. Once a user has authenticated to Kerberos at the start of her login session, her credentials are transparently passed to every other resource she accesses during the day. Trusted third-party refers to the fact that Kerberos works through a centralized authentication server that all systems in the network inherently trust. All authentication requests are routed through the centralized Kerberos server. Mutual authentication ensures that not only is the person behind the keyboard who he claims to be, but also proves that the server he is communicating with is who it claims to be. Mutual authentication protects the confidentiality of sensitive information by ensuring that the service the user is communicating with is genuine.

In this article we show how to use the MIT Kerberos-5 Key Distribution Center to authenticate Oracle Clients.

Kerberos Principals

A Kerberos principal is a unique identity to which Kerberos can assign tickets. Principals can have an arbitrary number of components. Each component is separated by a component separator, generally a «/». The last component is the realm, separated from the rest of the principal by the realm separator, generally «@». If there is no realm component in the principal, then it will be assumed that the principal is in the default realm for the context in which it is being used.

Traditionally, a principal is divided into three parts: the primary, the instance, and the realm. The format of a typical Kerberos 5 principal is primary/instance@REALM.

  • The primary is the first part of the principal. In the case of a user, it's the same as your username. For a host, the primary is the word host.
     
  • The instance is an optional string that qualifies the primary. In the case of a user, the instance is usually null, but a user might also have an additional principal. In the case of a host, the instance is the fully qualified hostname.
     
  • The realm is your Kerberos realm. In most cases, your Kerberos realm is your domain name, in upper-case letters.

Examples

zahn@AKADIA.COM

 This is the simplest form a principal can take, and is a valid principal under both Kerberos 4 and Kerberos 5. This principal represents the username zahn, with no instance, and a realm of AKADIA.COM.

zahn/admin@AKADIA.COM

 This example is similar to the one above, with the exception that this principal contains an instance—in this case, admin.

host/rabbit.akadia.com@AKADIA.COM

 Kerberos 5 host and service principals include the fully qualified domain name (FQDN) of the host that the service is installed on. By embedding the FQDN in the principal, Kerberos 5 allows administrators to have more than one host with the same hostname, but with different domain components located in the same realm.

The Key Distribution Center

The Kerberos Key Distribution Center, or KDC for short, is an integral part of the Kerberos system. The KDC consists of three logical components: a database of all principals and their associated encryption keys, the Authentication Server, and the Ticket Granting Server. While each of these components are logically separate, they are usually implemented in a single program and run together in a single process space.

Each Key Distribution Center contains a database of all of the principals contained in the realm, as well as their associated secrets. Most KDC software also stores additional information for each principal in this database, such as password lifetimes, last password change, and more. Windows 2000/2003 keep this database in the Active Directory, its LDAP store. Open source implementations, including MIT and Heimdal, keep this database in a specialized, lightweight database file on the KDC's filesystem.

The Authentication Server

The Authentication Server (AS) issues an encrypted Ticket Granting Ticket (also known as a TGT) to clients who wish to log in to the Kerberos realm. The client does not have to prove its identity to the KDC; instead, the TGT that is sent back to the client is encrypted in the user's password. Since only the user and the KDC know the user's password, when the login process attempts to decrypt the ticket using the password supplied by the user, only the correct password will correctly decrypt the ticket. If an incorrect password is used, the ticket will decrypt into garbage, and the user is prompted to try again.

The Ticket Granting Server

Not to be confused with the Ticket Granting Ticket, the Ticket Granting Server (TGS) issues individual service tickets to clients as they request them. The Ticket Granting Server takes in two pieces of data from the client: a ticket request that includes the principal name representing the service the client wishes to contact, and a Ticket Granting Ticket that has been issued by the Authentication Server. The TGS verifies the TGT is valid by checking to ensure that it is encrypted with the Kerberos server's TGT key, and then issues the user the service ticket he requested.

Tickets

Kerberos introduces the concept of tickets. Conceptually, a Kerberos ticket is an encrypted data structure issued by the Key Distribution Center that includes a shared encryption key that is unique for each session, and ticket flags that indicate, for example, if the ticket can be forwarded to another service, along with other fields. Tickets serve two purposes: to confirm identity of the end participants and to establish a short-lived encryption key that both parties can share for secure communication (called the session key).

The best way to think about tickets is as a license (issued by the KDC) that confirms your identity. Just like a license in the real world, each ticket issued by Kerberos includes data about you, how long the license (or ticket) is valid, and restrictions on its use. The major fields that Kerberos includes in every ticket are:

  • The requesting principal name (the user's principal)
  • The service's principal name
  • When the ticket becomes valid, and when the ticket expires
  • A list of IP addresses the ticket can be used from
  • A shared secret encryption key (session key) for user/application communication

Some of these fields are filled in by the KDC; for example, the KDC enforces a maximum ticket lifetime, and the KDC generates a unique session key each time it issues a ticket. The other fields are filled in by the client and passed to the KDC when it makes a ticket request. When a ticket is generated by the KDC, it is encrypted to ensure that attackers cannot take a valid ticket and modify it; for example, to increase its lifetime or the validated client principal name.

Tickets are relatively short-lived. A typical maximum lifetime for a Kerberos ticket is 10-24 hours. This relatively short lifetime balances the convenience of single-sign-on with the security threat of an attacker stealing credentials and using them for a long period of time. By limiting the lifetime of Kerberos tickets, the damage of a stolen ticket is minimized, while the user still enjoys the convenience of single-sign-on during the working day.

KDC Installation

Now, with the basic knowledge, we can setup a KDC. We use the MIT Kerberos 5 distribution on GENTOO Linux.

Download and Install the Software (Automatically done with emerge)

# emerge mit-krb5
 Manuals installed in /usr/share/man
Dok installed in /usr/share/doc/mit-krb5-1.3.1
Programs installed in /usr/sbin, /usr/bin
Libraries installed in /usr/lib
Configuration Files installed in /etc

Choose a REALM name (usually the DNS domain)

# vi /etc/krb5.conf

 

[libdefaults]
        ticket_lifetime = 600
        default_realm = AKADIA.COM
        default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
        default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc

[realms]
        AKADIA.COM = {
        kdc = 192.168.136.16:88
        admin_server = 192.168.136.16:749
        }

[domain_realm]
        .example.com = AKADIA.COM
        example.com = AKADIA.COM

[kdc]
        profile = /etc/krb5kdc/kdc.conf

[logging]
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmin.log
        default = FILE:/var/log/krb5lib.log

# vi /etc/krb5kdc/kdc.conf