diff options
| -rw-r--r-- | source4/auth/kerberos/kerberos-notes.txt | 26 | ||||
| -rw-r--r-- | source4/auth/kerberos/kerberos_util.c | 7 |
2 files changed, 22 insertions, 11 deletions
diff --git a/source4/auth/kerberos/kerberos-notes.txt b/source4/auth/kerberos/kerberos-notes.txt index 58a4159a7e..43881a20d3 100644 --- a/source4/auth/kerberos/kerberos-notes.txt +++ b/source4/auth/kerberos/kerberos-notes.txt @@ -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 ---------------------------- diff --git a/source4/auth/kerberos/kerberos_util.c b/source4/auth/kerberos/kerberos_util.c index d8c650b098..d3edd1b26c 100644 --- a/source4/auth/kerberos/kerberos_util.c +++ b/source4/auth/kerberos/kerberos_util.c @@ -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); |