r12422: Some kerberos comments and clarifications.
authorAndrew Bartlett <abartlet@samba.org>
Thu, 22 Dec 2005 06:50:04 +0000 (06:50 +0000)
committerGerald (Jerry) Carter <jerry@samba.org>
Wed, 10 Oct 2007 18:47:36 +0000 (13:47 -0500)
Andrew Bartlett

source/auth/kerberos/kerberos-notes.txt
source/auth/kerberos/kerberos_util.c

index 58a4159a7e83ae428725a775d694ae2a1dba3f73..43881a20d33d69aa1ea6166b8e8a86c35a7c3fdf 100644 (file)
@@ -99,6 +99,13 @@ Jean-Baptiste.Marchand@hsc.fr reminds me:
 
 We implement this in hdb-ldb.
 
+Implicit names for Win2000 Accounts
+-----------------------------------
+
+Despite not having a DNS name, nor a servicePrincipalName on accounts
+created by computers running win2000, it appears we are expected to
+have an implicit mapping from host/computer.full.name and
+host/computer to it's entry.
 
 Returned Salt for PreAuthentication
 -----------------------------------
@@ -276,12 +283,8 @@ DCE-RPC service) and when interacting on a kerberos basis, the
 password is salted by the client.  (That is, no salt infromation
 appears to be convayed from the KDC to the member).
 
-In dealing with this modal, the traditional file keytab seems
-outmoded, because it is not the primary source of the keys, and as
-such we have replaced it with an IN-MEMORY keytab.  This avoids Samba4
-needing to deal with system files for it's internal operation.  (We
-will however forward-port parts of Samba3's net ads keytab, for the
-benifit of other applications).
+In dealing with this modal, we leverage both the traditional file
+keytab and in-MEMORY keytabs.  
 
 When dealing with a windows KDC, the behaviour regarding case
 sensitivity and canonacolisation must be accomidated.  This means that
@@ -296,9 +299,14 @@ cifs/foo@realm (winxp clients, using netbios)
 
 as well as all case variations on the above.  
 
-Because that all got 'too hard' to put into a real keytab (and because we
-still wanted to supply a keytab to the GSSAPI code), we use in-memory
-keytabs, and specify the target name.
+Because that all got 'too hard' to put into a keytab in the
+traditional way (with the client to specify the name), we either
+pre-compute the keys into a traditional keytab or make an in-MEMORY
+keytab at run time.  In both cases we specifiy the principal name to
+GSSAPI, which avoids the need to store duplicate principals.
+
+We use a 'private' keytab in our private dir, referenced from the
+secrets.ldb by default.
 
 Extra Heimdal functions used
 ----------------------------
index d8c650b0989acb68993343b64c186f4a46d53df0..d3edd1b26c94be2566713187f658c08c8def5fe5 100644 (file)
@@ -89,6 +89,8 @@ krb5_error_code salt_principal_from_credentials(TALLOC_CTX *parent_ctx,
        } 
 
        if (ret == 0) {
+               /* This song-and-dance effectivly puts the principal
+                * into talloc, so we can't loose it. */
                mem_ctx->smb_krb5_context = talloc_reference(mem_ctx, smb_krb5_context);
                mem_ctx->principal = *salt_princ;
                talloc_set_destructor(mem_ctx, free_principal);
@@ -115,7 +117,8 @@ krb5_error_code principal_from_credentials(TALLOC_CTX *parent_ctx,
        
        princ_string = cli_credentials_get_principal(credentials, mem_ctx);
 
-       /* A NULL here has meaning, as the gssapi server case will then use the principal from the client */
+       /* A NULL here has meaning, as the gssapi server case will
+        * then use the principal from the client */
        if (!princ_string) {
                talloc_free(mem_ctx);
                princ = NULL;
@@ -548,7 +551,7 @@ static krb5_error_code remove_old_entries(TALLOC_CTX *parent_ctx,
                         * because deletes during enumeration may not
                         * always be consistant.
                         *
-                        * Also, the enumeration locks the keytab
+                        * Also, the enumeration locks a FILE: keytab
                         */
                
                        krb5_kt_end_seq_get(smb_krb5_context->krb5_context, keytab, &cursor);