sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2025-02-04 17:47:26 +03:00
Code

r12422: Some kerberos comments and clarifications.

Browse Source 
Andrew Bartlett
(This used to be commit 31046cd22b45de6c62c9f122a81cfc898e818308)
This commit is contained in:
Andrew Bartlett 2005-12-22 06:50:04 +00:00 committed by Gerald (Jerry) Carter
parent 8e0948bbad
commit 9a9cb35cbd
2 changed files with 22 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
source4/auth/kerberos/kerberos-notes.txt
View 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
----------------------------

7
source4/auth/kerberos/kerberos_util.c
View 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);