directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kayyag...@apache.org
Subject svn commit: r1444569 - in /directory/site/trunk/content/apacheds/kerberos-ug: 1.1.1-realms.mdtext 1.1.2-principals.mdtext 1.1.3-keys.mdtext 1.1.4-kdc.mdtext 1.1.5-database.mdtext
Date Sun, 10 Feb 2013 17:20:32 GMT
Author: kayyagari
Date: Sun Feb 10 17:20:32 2013
New Revision: 1444569

URL: http://svn.apache.org/r1444569
Log:
more editing

Modified:
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.1-realms.mdtext
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.2-principals.mdtext
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.3-keys.mdtext
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.mdtext
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.5-database.mdtext

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.1-realms.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.1-realms.mdtext?rev=1444569&r1=1444568&r2=1444569&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.1-realms.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.1-realms.mdtext Sun Feb 10 17:20:32
2013
@@ -24,17 +24,17 @@ Notice: Licensed to the Apache Software 
 
 # 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**).
 
 <DIV class="info" markdown="1">
 Note that the name is case sensitive. **apache.org** is a different realm than **APACHE.ORG**.
@@ -44,7 +44,7 @@ The **Realm** name wil be used all over 
 
 ## 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 :
 
 <DIV align="center">
 ![Kerberos Realm Configuration](images/kerberos-realm-config.png)
@@ -56,5 +56,4 @@ or by modifying the LDIF configuration d
     dn: ads-serverId=kerberosServer,ou=servers,ads-directoryServiceId=default,ou=config
     ...
     ads-krbprimaryrealm: EXAMPLE.COM
-    ...
-
+    ...
\ No newline at end of file

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.2-principals.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.2-principals.mdtext?rev=1444569&r1=1444568&r2=1444569&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.2-principals.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.2-principals.mdtext Sun Feb 10 17:20:32
2013
@@ -28,17 +28,17 @@ The Kerberos **Principal** is any entity
 
     * 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 :
     
     * the name (the primary)
     * an optional instance
     * the realm they are associated with
 
-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**)
 
 The **Principal** syntax is the following :
 
@@ -56,5 +56,3 @@ Those are examples of valid **Principals
     john/admin@APACHE.ORG                       A user who is an admin
     host/www.apache.org/apache.org@APACHE.ORG   A host with two hostnames
     ldap/www.apache.org@APACHE.ORG              A service (Ldap server)
-
-

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.3-keys.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.3-keys.mdtext?rev=1444569&r1=1444568&r2=1444569&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.3-keys.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.3-keys.mdtext Sun Feb 10 17:20:32
2013
@@ -24,12 +24,12 @@ Notice: Licensed to the Apache Software 
 
 # 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. 
 
 <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>
 
 ## How it works in ApacheDS ?
@@ -51,16 +51,24 @@ When you add a new entry in the server, 
     cn: Horatio Nelson
     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 :
+    
+    ::text
+    EncryptionKey   ::= SEQUENCE {
+        keytype         [0] Int32 -- actually encryption type --,
+        keyvalue        [1] OCTET STRING
+    }
 
 <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>
 
 <DIV class="INFO" mardown="1">
-Note that we will generate more than one key : we generate one key per configured cipher.

+Note that we will generate more than one key : we generate one key for each of the supported
encryption types. 
 
-ApacheDS Kerberos server supported set of ciphers is :
+ApacheDS Kerberos server supports the following set of encryption types :
 
     * DES_CBC_MD5
     * DES3_CBC_SHA1_KD
@@ -68,26 +76,11 @@ ApacheDS Kerberos server supported set o
     * AES128_CTS_HMAC_SHA1_96
     * AES256_CTS_HMAC_SHA1_96
 
-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.
+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>
 
-<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.
-
-Provisionning thousands of users will inheritently be a slow operation.
-</DIV>
-
-Once the keys have been computed, we modify the entry to inject an ASN.1 BER encoded EncryptionKey
instance into it.
-
-The EncryptionKey structure is the following ASN.1 desciption :
-    
-    ::text
-    EncryptionKey   ::= SEQUENCE {
-        keytype         [0] Int32 -- actually encryption type --,
-        keyvalue        [1] OCTET STRING
-    }
 
-The modified entry will now looks like :
+The modified entry will now look like :
 
     :::text
     dn: uid=hnelson,ou=users,dc=example,dc=com

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.mdtext?rev=1444569&r1=1444568&r2=1444569&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.4-kdc.mdtext Sun Feb 10 17:20:32
2013
@@ -25,13 +25,13 @@ Notice: Licensed to the Apache Software 
 # 1.1.4 - KDC (Key Distribution Center)
 
 The **KDC** contains three components :
-* the Authentication Server
-* the database (ApacheDS)
-* and the Ticket Granting Server
+* an Authentication Service
+* a Ticket Granting Service
+* a database (ApacheDS)
 
-The **KDC** role is to distribute tickets and to authenticate users, based on the informations
stored into its database.
+The **KDC** role is to authenticate users and distribute tickets based on the information
stored in its database.
 
-In some way, the **Apache Kerberos Server** is a **KDC**.
+The **Apache Kerberos Server** contains all these three components and hence is a **KDC**.
 
 <DIV class="info" markdown="1">
 We could allow the **Kerberos Server** to manage more than one **KDC**, but this is not currently
possible.
@@ -45,6 +45,6 @@ The following schema expose the way the 
 ![KDC usage](images/kerberos-auth.png)
 </DIV>
 
-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 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.
 
-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.
+Though the Autehntication and Ticket Granting services look like running in separate servers,
a signle Kerberos server implementation oftent contains both.

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.5-database.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.5-database.mdtext?rev=1444569&r1=1444568&r2=1444569&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.5-database.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.5-database.mdtext Sun Feb 10 17:20:32
2013
@@ -24,19 +24,19 @@ Notice: Licensed to the Apache Software 
 
 # 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.
 



Mime
View raw message