svn commit: samba r7862 - in
branches/SAMBA_4_0/source/auth/kerberos: .
abartlet at samba.org
abartlet at samba.org
Fri Jun 24 01:13:35 GMT 2005
Author: abartlet
Date: 2005-06-24 01:13:35 +0000 (Fri, 24 Jun 2005)
New Revision: 7862
WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=7862
Log:
Updates to the Kerberos notes, based on recent changes and discoveries.
Andrew Bartlett
Modified:
branches/SAMBA_4_0/source/auth/kerberos/kerberos-notes.txt
Changeset:
Modified: branches/SAMBA_4_0/source/auth/kerberos/kerberos-notes.txt
===================================================================
--- branches/SAMBA_4_0/source/auth/kerberos/kerberos-notes.txt 2005-06-24 00:35:20 UTC (rev 7861)
+++ branches/SAMBA_4_0/source/auth/kerberos/kerberos-notes.txt 2005-06-24 01:13:35 UTC (rev 7862)
@@ -8,8 +8,8 @@
The KDC I imagine checks the netbios address against this value, in
the same way that the Samba server does this.
+The checking of this implies a little of the next question:
-
Is a DAL the layer we need?
---------------------------
@@ -30,7 +30,10 @@
Perhaps all we need to do is add in the same kludges as we have in
Samba 3.0 for eDirectory. Hmm...
+That said, the current layer provides us with a very good start, and
+any redefinition would occour from that basis.
+
GSSAPI layer requirements
-------------------------
@@ -39,7 +42,8 @@
The MIT GSSAPI libs do not support kinit returning a different
realm to what the client asked for, even just in case differences.
-Not looked into this on Heimdal quite yet.
+Heimdal has the same problem, and this applies to the krb5 layer, not
+just gssapi.
Principal Names, long and short names
@@ -54,6 +58,8 @@
operations, but because the server performs canonicalisation, this
causes pain for current client libraries.
+The canonicalisation of names matters not only for the KDC, but also
+for code that has to deal with keytabs.
HOST/ Aliases
-------------
@@ -73,7 +79,9 @@
> http://msdn.microsoft.com/library/en-us/adschema/adschema/a_spnmappings.asp
+We implement this in hdb-ldb.
+
Returned Salt for PreAuthentication
-----------------------------------
@@ -164,27 +172,38 @@
mostly a question of context, and how the library manages whatever
internal state machines it has. If the library uses a context
variable, passed in by the caller, which contains all the information
-about the current state of the library, then it is safe. A n example
+about the current state of the library, then it is safe. An example
of this state is the sequence number and session keys for an ongoing
encrypted session).
The other issue affecting state machines is 'blocking' (waiting for a
read on a network socket).
-Heimdal is not state machine safe for the GSSAPI layer in particular.
-Krb5 alone is much closer, as far as I can tell (the exception being the
-error string handling). Adding safety is so 'easy', it is very, very
-tempting to modify the APIs required and 'just do it'. Testing is a
-different problem however.
+Heimdal has this 'state machine safety' in parts, and we have modified
+the lorikeet branch to improve this behviour, when using a new,
+non-standard API.
-We may just use a fork()ed child to handle this, and have one process
-per context. This is primarily to solve the non-blocking issue.
+Heimdal uses a per-context variable for the 'krb5_auth_context', which
+controls the ongoing encrypted connection, but does use global
+variables for the ubiquitous krb5_context parameter.
-I had hoped to use the 'GSSAPI export context' function to transfer
+The modification that has added most to 'state machine safety' of
+GSSAPI is the addition of the gsskrb5_acquire_creds function. This
+allows the caller to specify a keytab and ccache, for use by the
+GSSAPI code. Therefore there is no need to use global variables to
+communicate this information.
+
+At a more theoritical level (simply counting static and global
+variables) Heimdal is not state machine safe for the GSSAPI layer.
+The Krb5 layer alone is much closer, as far as I can tell, blocking
+excepted. .
+
+To deal with blocking, we could have a fork()ed child per context,
+using the 'GSSAPI export context' function to transfer
the GSSAPI state back into the main code for the wrap()/unwrap() part
-of the operation, but we still hit issues of static storage (one
+of the operation. This will still hit issues of static storage (one
gss_krb5_context per process, and multiple GSSAPI encrypted sessions
-at a time).
+at a time) but these may not matter in practice.
GSSAPI and Kerberos extensions
@@ -200,10 +219,60 @@
- gsskrb5_get_authz_data()
- - case insensitive keytab
- - in-memory keytab
- - wildcard keytab (for in-memory operations)
+ - gsskrb5_acquire_creds() (takes keytab and/or ccache as input
+ parameters, see keytab and state machine discussion)
+Keytab requirements
+-------------------
+
+Because windows machine account handling is very different to the
+tranditional 'MIT' keytab operation. This starts when we look at the
+basis of the secrets handling:
+
+Traditional 'MIT' behaviour is to use a keytab, continaing salted key
+data, extracted from the KDC. (In this modal, there is no 'service
+password', instead the keys are often simply application of random
+bytes). Heimdal also implements this behaviour.
+
+The windows modal is very different - instead of sharing a keytab with
+each member server, a password is stored for the whole machine. The
+password is set with non-kerberos mechanisms (particularly SAMR, a
+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).
+
+When dealing with a windows KDC, the behaviour regarding case
+sensitivity and canonacolisation must be accomidated. This means that
+an incoming request to a member server may have a wide variety of
+service principal names. These include:
+
+machine$@REALM (samba clients)
+HOST/foo.bar at realm (win2k clients)
+HOST/foo at realm (win2k clients, using netbios)
+cifs/foo.bar at realm (winxp clients)
+cifs/foo at realm (winxp clients, using netbios)
+
+as well as all case variations on the above.
+
+Because that all got 'too hard' to put into a keytab (and because we
+still wanted to supply a keytab to the GSSAPI code), a 'wildcard'
+keytab was devised. MEMORY_WILDCARD: is much like MEMORY:, except it
+only matches on kvno, rather than on the principal name.
+
+Extra Heimdal functions used
+----------------------------
+(an attempt to list some of the Heimdal-specific functions I know we use)
+
+krb5_make_principal()
+krb5_free_keyblock_contents()
+
KDC Extensions
--------------
@@ -211,14 +280,16 @@
Principal being requested. This allows us to correctly behave with
the different 'classes' of Principal name.
-We currently define 3 classes:
- - krbtgt
+We currently define 2 classes:
- client (kinit)
- server (tgt)
I also now specify the kerberos principal as an explict parameter, not
an in/out value on the entry itself.
+Inside hdb-ldb, we add krbtgt as a special class of principal, because
+of particular special-case backend requirements.
+
libkdc
------
@@ -241,7 +312,7 @@
consistancy in the handling of requests, binding to sockets etc.
To handle TCP, we will use of our socket layer in much the same way as
-we deal with TCP for CIFS.
+we deal with TCP for CIFS. Tridge has promised this generalisation.
Kerberos logging support
------------------------
More information about the samba-cvs
mailing list