You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by bu...@apache.org on 2013/02/10 18:20:39 UTC
svn commit: r850141 - in /websites/staging/directory/trunk/content: ./
apacheds/kerberos-ug/
Author: buildbot
Date: Sun Feb 10 17:20:38 2013
New Revision: 850141
Log:
Staging update by buildbot for directory
Modified:
websites/staging/directory/trunk/content/ (props changed)
websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.1-realms.html
websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.2-principals.html
websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.3-keys.html
websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.html
websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html
Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Feb 10 17:20:38 2013
@@ -1 +1 @@
-1444494
+1444569
Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.1-realms.html
==============================================================================
--- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.1-realms.html (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.1-realms.html Sun Feb 10 17:20:38 2013
@@ -138,19 +138,19 @@
<h1 id="111-realms">1.1.1 - Realms</h1>
-<p>A <strong>Realm</strong> is associated with a Kerberos administrative domain. In other words, it covers everything the Kerberos server manage :
+<p>A <strong>Realm</strong> is associated with a Kerberos administrative domain. In other words, it covers everything the Kerberos server manages :
<em> Users
</em> Services</p>
-<p>Note that if a Kerberos Server manage one <strong>Realm</strong> only, a <strong>Realm</strong> 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.</p>
+<p>Note that a Kerberos Server manages <strong>one</strong> 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.</p>
<h2 id="realm-name">Realm name</h2>
<p>In order to distinguish the <strong>Realms</strong>, 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.</p>
-<p>For instance, say that th Kerberos server is installed on a machine which domain name is <strong>apache.org</strong>, then we will use <strong>APACHE.ORG</strong> as the <strong>Realm</strong> name (but you could have used <strong>Apache.org</strong> or even <strong>MyApacheDomain</strong>).</p>
+<p>For instance, say that th Kerberos server is installed on a machine whose domain name is <strong>apache.org</strong>, then we will use <strong>APACHE.ORG</strong> as the <strong>Realm</strong> name (but you could use <strong>Apache.org</strong> or even <strong>MyApacheDomain</strong>).</p>
<p><DIV class="info" markdown="1">
Note that the name is case sensitive. <strong>apache.org</strong> is a different realm than <strong>APACHE.ORG</strong>.
</DIV></p>
<p>The <strong>Realm</strong> name wil be used all over Kerberos to name <strong>Principals</strong> and <strong>Services</strong></p>
<h2 id="default-realm-for-apacheds-kerberos-server">Default Realm for ApacheDS Kerberos Server</h2>
-<p>When you set up an <strong>ApacheDS Kerberos Server</strong>, the <strong>Realm</strong> name is set to <strong>EXAMPLE.COM</strong>. This can be changed either through <strong>Studio</strong>, by accessing the server configuration and changing the 'Primary KDC Realm', as show in this picture :</p>
+<p>When <strong>ApacheDS Kerberos Server</strong> installed, the default <strong>Realm</strong> name is set to <strong>EXAMPLE.COM</strong>. This can be changed either using <strong>Studio</strong>, by accessing the server configuration and changing the 'Primary KDC Realm', as show in this picture :</p>
<p><DIV align="center">
<img alt="Kerberos Realm Configuration" src="images/kerberos-realm-config.png" />
</DIV></p>
Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.2-principals.html
==============================================================================
--- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.2-principals.html (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.2-principals.html Sun Feb 10 17:20:38 2013
@@ -141,19 +141,19 @@
<p>The Kerberos <strong>Principal</strong> is any entity to which the server can assign a <strong>Ticket</strong>. Typically, we can think of three kinds of <strong>Principals</strong> :</p>
<div class="codehilite"><pre><span class="o">*</span> <span class="n">Users</span>
<span class="o">*</span> <span class="n">Services</span>
-<span class="o">*</span> <span class="n">hosts</span>
+<span class="o">*</span> <span class="n">Hosts</span>
</pre></div>
<p>Each <strong>Principal</strong> is unique in the Kerberos database. This is the way we identify the entity.</p>
-<p>A Kerberos <strong>Principal</strong> is a combinaison of three parts :</p>
+<p>A Kerberos <strong>Principal</strong> is a combination of three parts :</p>
<div class="codehilite"><pre><span class="o">*</span> <span class="n">the</span> <span class="n">name</span> <span class="p">(</span><span class="n">the</span> <span class="n">primary</span><span class="p">)</span>
<span class="o">*</span> <span class="n">an</span> <span class="n">optional</span> <span class="n">instance</span>
<span class="o">*</span> <span class="n">the</span> <span class="n">realm</span> <span class="n">they</span> <span class="n">are</span> <span class="n">associated</span> <span class="n">with</span>
</pre></div>
-<p>The optional instance is used to provide more than one role to an entity, without having to create N <strong>Principal</strong> 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 <strong>Principal</strong> to create a new and easy to remember <strong>Principal</strong>)</p>
+<p>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 <strong>Principal</strong> to create a new and easy to remember <strong>Principal</strong>)</p>
<p>The <strong>Principal</strong> syntax is the following :</p>
<div class="codehilite"><pre><primary> ['/' <instance>]* '@' <realm>
</pre></div>
Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.3-keys.html
==============================================================================
--- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.3-keys.html (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.3-keys.html Sun Feb 10 17:20:38 2013
@@ -138,10 +138,10 @@
<h1 id="113-keys">1.1.3 - Keys</h1>
-<p>The <strong>Kerberos</strong> server generates keys based on the password we provide. Those keys are stored in the <strong>KDC</strong> and used to encrypt and decrypt the data being exchanged with the client.</p>
+<p>The <strong>Kerberos</strong> 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.</p>
<p>The Key is computed using either the user's password or a random value, and is salted with the realm. </p>
<p><DIV class="INFO" markdown="1">
-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.
</DIV></p>
<h2 id="how-it-works-in-apacheds">How it works in ApacheDS ?</h2>
<p>When you add a new entry in the server, it generates a secret key using the password and the <strong>Principal</strong> of the added entry. For instance, say we add this entry :</p>
@@ -161,13 +161,21 @@ sn: Nelson
</pre></div>
-<p>the server will compute the krb5key values automatically, and add it the the entry. </p>
+<p>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. </p>
+<p>Each value of krb5Key attribbute will be in the following ASN.1 format :</p>
+<div class="codehilite"><pre>EncryptionKey ::= SEQUENCE {
+ keytype [0] Int32 -- actually encryption type --,
+ keyvalue [1] OCTET STRING
+}
+</pre></div>
+
+
<p><DIV class="INFO" mardown="1">
There is a special case : if the password is "randomkey", the key will be generated using a random number created on the fly.
</DIV></p>
<p><DIV class="INFO" mardown="1">
-Note that we will generate more than one key : we generate one key per configured cipher. </p>
-<p>ApacheDS Kerberos server supported set of ciphers is :</p>
+Note that we will generate more than one key : we generate one key for each of the supported encryption types. </p>
+<p>ApacheDS Kerberos server supports the following set of encryption types :</p>
<div class="codehilite"><pre><span class="o">*</span> <span class="n">DES_CBC_MD5</span>
<span class="o">*</span> <span class="n">DES3_CBC_SHA1_KD</span>
<span class="o">*</span> <span class="n">RC4_HMAC</span>
@@ -176,22 +184,9 @@ Note that we will generate more than one
</pre></div>
-<p>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.
-</DIV></p>
-<p><DIV class="WARN" mardown="1">
-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.</p>
-<p>Provisionning thousands of users will inheritently be a slow operation.
+<p>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.
</DIV></p>
-<p>Once the keys have been computed, we modify the entry to inject an ASN.1 BER encoded EncryptionKey instance into it.</p>
-<p>The EncryptionKey structure is the following ASN.1 desciption :</p>
-<div class="codehilite"><pre>EncryptionKey ::= SEQUENCE {
- keytype [0] Int32 -- actually encryption type --,
- keyvalue [1] OCTET STRING
-}
-</pre></div>
-
-
-<p>The modified entry will now looks like :</p>
+<p>The modified entry will now look like :</p>
<div class="codehilite"><pre>dn: uid=hnelson,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.html
==============================================================================
--- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.html (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.html Sun Feb 10 17:20:38 2013
@@ -139,11 +139,11 @@
<h1 id="114-kdc-key-distribution-center">1.1.4 - KDC (Key Distribution Center)</h1>
<p>The <strong>KDC</strong> contains three components :
-<em> the Authentication Server
-</em> the database (ApacheDS)
-* and the Ticket Granting Server</p>
-<p>The <strong>KDC</strong> role is to distribute tickets and to authenticate users, based on the informations stored into its database.</p>
-<p>In some way, the <strong>Apache Kerberos Server</strong> is a <strong>KDC</strong>.</p>
+<em> an Authentication Service
+</em> a Ticket Granting Service
+* a database (ApacheDS)</p>
+<p>The <strong>KDC</strong> role is to authenticate users and distribute tickets based on the information stored in its database.</p>
+<p>The <strong>Apache Kerberos Server</strong> contains all these three components and hence is a <strong>KDC</strong>.</p>
<p><DIV class="info" markdown="1">
We could allow the <strong>Kerberos Server</strong> to manage more than one <strong>KDC</strong>, but this is not currently possible.
</DIV></p>
@@ -152,8 +152,8 @@ We could allow the <strong>Kerberos Serv
<p><DIV align="center">
<img alt="KDC usage" src="images/kerberos-auth.png" />
</DIV></p>
-<p>In order to use a service, the client will grab a ticket for this service on the <strong>KDC</strong>. This requires a two steps process, where the client first authenticate, and then get back a ticket to use with the targeted server.</p>
-<p>In the previous schema, the <strong>TGS</strong> 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.</p>
+<p>In order to use a service, the client needs to get a ticket for this service from the <strong>KDC</strong>. This requires a two step process, where the client first authenticates himself, and then get back a ticket to use with the targeted server.</p>
+<p>Though the Autehntication and Ticket Granting services look like running in separate servers, a signle Kerberos server implementation oftent contains both.</p>
<div class="nav">
Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html
==============================================================================
--- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html Sun Feb 10 17:20:38 2013
@@ -138,15 +138,15 @@
<h1 id="115-database">1.1.5 - Database</h1>
-<p>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 <strong>Kerberos</strong> server is built as a part of an existing LDAP server, as for *<em>Apache Directory Server</em> !</p>
+<p>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 <strong>Kerberos</strong> server is a part of an existing LDAP server, like *<em>Apache Directory Server</em> !</p>
<p>When <strong>Apache Directory Server</strong> was started, it was also thought as a repository for <strong>Kerberos</strong> keys, so we just had to develop the logic to manage those keys, and the Kerberos protocol. </p>
<p>In other words, you have everything embedded in a single server :
-<em> The LDAP server to store the keys and other related informations
+<em> The LDAP server to store the keys and other related information
</em> The Kerberos protocol
<em> The Authentication Server
</em> The Ticket Granting Server</p>
<h2 id="structure">Structure</h2>
-<p>There is an existing <strong>LDAP</strong> schema to manage the keys and other informations, named <strong>krb5kdc</strong>. It contains 3 ObjectClasses and 15 AttributeTypes.</p>
+<p>There is an existing <strong>LDAP</strong> schema to manage the keys and other information, named <strong>krb5kdc</strong>. It contains 3 ObjectClasses and 15 AttributeTypes.</p>
<p>All the ObjectClasses are auxilliary.</p>
<h3 id="krb5principal">krb5Principal</h3>
<p>This ObjectClass is used to store a Principal. It contains one mandatory AttributeType, <em>krb5PrincipalName</em>, and two optionnal (<em>cn</em> and <em>krb5PrincipalRealm</em>)</p>