1.1.1 - Realms

A Realm is associated with a Kerberos administrative domain. In other words, it covers everything the Kerberos server manage :
+

A Realm is associated with a Kerberos administrative domain. In other words, it covers everything the Kerberos server manages :
Users
Services

-

Note that if a Kerberos Server manage one Realm only, a Realm can be managed by more than one Kerberos server : this is mandatory to avoid created a single point of failure, if the Kerberos server halts for any reason. Usually, the Kerberos servers are sharing the database - or in our case, the database is being replicated between the Kerberos Servers.

+

Note that a Kerberos Server manages one Realm only, a Realm can be managed by more than one Kerberos server : this is mandatory to avoid a single point of failure, if a Kerberos server halts for any reason.

Realm name

In order to distinguish the Realms, we give them a unique name. This name can be anything, but a convention is to use the DNS name of the Kerberos server, and to use uppercase.

-

For instance, say that th Kerberos server is installed on a machine which domain name is apache.org, then we will use APACHE.ORG as the Realm name (but you could have used Apache.org or even MyApacheDomain).

+

For instance, say that th Kerberos server is installed on a machine whose domain name is apache.org, then we will use APACHE.ORG as the Realm name (but you could use Apache.org or even MyApacheDomain).

Note that the name is case sensitive. apache.org is a different realm than APACHE.ORG.

The Realm name wil be used all over Kerberos to name Principals and Services

Default Realm for ApacheDS Kerberos Server

-

When you set up an ApacheDS Kerberos Server, the Realm name is set to EXAMPLE.COM. This can be changed either through Studio, by accessing the server configuration and changing the 'Primary KDC Realm', as show in this picture :

+

When ApacheDS Kerberos Server installed, the default Realm name is set to EXAMPLE.COM. This can be changed either using Studio, by accessing the server configuration and changing the 'Primary KDC Realm', as show in this picture :

The Kerberos Principal is any entity to which the server can assign a Ticket. Typically, we can think of three kinds of Principals :

*Users*Services
-*hosts
+*Hosts

Each Principal is unique in the Kerberos database. This is the way we identify the entity.

-

A Kerberos Principal is a combinaison of three parts :

+

A Kerberos Principal is a combination of three parts :

*thename(theprimary)*anoptionalinstance*therealmtheyareassociatedwith

-

The optional instance is used to provide more than one role to an entity, without having to create N Principal for a single user (an administrator is also a normal user, and it's good to qualify the user by adding his admin qualificiation in one Principal to create a new and easy to remember Principal)

+

The optional instance is used to provide more than one role to an entity, without having to create N Principals for a single user (an administrator is also a normal user, and it's good to qualify the user by adding his admin qualificiation in one Principal to create a new and easy to remember Principal)

1.1.3 - Keys

The Kerberos server generates keys based on the password we provide. Those keys are stored in the KDC and used to encrypt and decrypt the data being exchanged with the client.

+

The Kerberos server generates keys based on the password we provide. Those keys are stored in the server and used to encrypt and decrypt the data being exchanged with the client.

The Key is computed using either the user's password or a random value, and is salted with the realm.

-Using the realm as the salt is a protection : if one's key is broken on a realm, that does not mean the password is compromised. The key on another realm would still be safe.
+Using the realm as the salt offers a level of protection : if one's key is broken on a realm, that does not mean the password is compromised. The key on another realm would still be safe.

How it works in ApacheDS ?

When you add a new entry in the server, it generates a secret key using the password and the Principal of the added entry. For instance, say we add this entry :

@@ -161,13 +161,21 @@ sn: Nelson
-

the server will compute the krb5key values automatically, and add it the the entry.

+

the server will automatically create the keys (each one is encoded in ASN.1 BER format), set them as values of krb5key attribute and add to the entry.

+

Each value of krb5Key attribbute will be in the following ASN.1 format :

There is a special case : if the password is "randomkey", the key will be generated using a random number created on the fly.

-Note that we will generate more than one key : we generate one key per configured cipher.
-

ApacheDS Kerberos server supported set of ciphers is :

+Note that we will generate more than one key : we generate one key for each of the supported encryption types.
+

ApacheDS Kerberos server supports the following set of encryption types :

*DES_CBC_MD5*DES3_CBC_SHA1_KD*RC4_HMAC
@@ -176,22 +184,9 @@ Note that we will generate more than one

-

The default cipher is DES_CBC_MD5, so if you want to use another one, you must add it to the list of supported EncryptionTypes.
-

-

-Note that the key generation is an extremely costly operation. If you have many supported ciphers, you will multiply the time it takes to generate the keys by the number of ciphers. It's smart to limit the configured ciphers to the minimal, accordingly to your needs.
-

Provisionning thousands of users will inheritently be a slow operation.
+

The default encryption types used by the server are, aes128-cts-hmac-sha1-96, des-cbc-md5 and des3-cbc-sha1-kd DES_CBC_MD5. The supported encryption types can be added or removed by modifying the Kerberos server configuration.

-

Once the keys have been computed, we modify the entry to inject an ASN.1 BER encoded EncryptionKey instance into it.

1.1.4 - KDC (Key Distribution Center)

The KDC contains three components :
- the Authentication Server
- the database (ApacheDS)
-* and the Ticket Granting Server

-

The KDC role is to distribute tickets and to authenticate users, based on the informations stored into its database.

-

In some way, the Apache Kerberos Server is a KDC.

+ an Authentication Service
+ a Ticket Granting Service
+* a database (ApacheDS)
+

The KDC role is to authenticate users and distribute tickets based on the information stored in its database.

+

The Apache Kerberos Server contains all these three components and hence is a KDC.

We could allow the Kerberos Server to manage more than one KDC, but this is not currently possible.

@@ -152,8 +152,8 @@ We could allow the Kerberos Serv

-

In order to use a service, the client will grab a ticket for this service on the KDC. This requires a two steps process, where the client first authenticate, and then get back a ticket to use with the targeted server.

-

In the previous schema, the TGS is a service that will expect a Ticket to be delivered in order to generate new tickets for any other services. It can sound weird that the authentication process does not deliver a Ticket for the targeted server, but there is no reason for the Autehntication Server to be the same server than the Ticket Granting Server.

+

In order to use a service, the client needs to get a ticket for this service from the KDC. This requires a two step process, where the client first authenticates himself, and then get back a ticket to use with the targeted server.

1.1.5 - Database

-

This is the place where all the private keys are stored. This is pretty natural to store all those keys in a LDAP server, even more natural when the Kerberos server is built as a part of an existing LDAP server, as for *Apache Directory Server !

+

This is the place where all the private keys are stored. It is very common to store all the keys in an LDAP server, even more natural when the Kerberos server is a part of an existing LDAP server, like *Apache Directory Server !

When Apache Directory Server was started, it was also thought as a repository for Kerberos keys, so we just had to develop the logic to manage those keys, and the Kerberos protocol.

In other words, you have everything embedded in a single server :
- The LDAP server to store the keys and other related informations
+ The LDAP server to store the keys and other related information
The Kerberos protocol
The Authentication Server
The Ticket Granting Server

Structure

-

There is an existing LDAP schema to manage the keys and other informations, named krb5kdc. It contains 3 ObjectClasses and 15 AttributeTypes.

+

There is an existing LDAP schema to manage the keys and other information, named krb5kdc. It contains 3 ObjectClasses and 15 AttributeTypes.

All the ObjectClasses are auxilliary.

krb5Principal

This ObjectClass is used to store a Principal. It contains one mandatory AttributeType, krb5PrincipalName, and two optionnal (cn and krb5PrincipalRealm)