directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r850141 - in /websites/staging/directory/trunk/content: ./ apacheds/kerberos-ug/
Date Sun, 10 Feb 2013 17:20:39 GMT
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>&lt;primary&gt; [&#39;/&#39; &lt;instance&gt;]*
&#39;@&#39; &lt;realm&gt;
 </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>



Mime
View raw message