diff options
Diffstat (limited to 'source4/auth/kerberos')
| -rw-r--r-- | source4/auth/kerberos/kerberos-notes.txt | 109 |
1 files changed, 90 insertions, 19 deletions
diff --git a/source4/auth/kerberos/kerberos-notes.txt b/source4/auth/kerberos/kerberos-notes.txt index 993d5f5d0b..24e6ad2403 100644 --- a/source4/auth/kerberos/kerberos-notes.txt +++ b/source4/auth/kerberos/kerberos-notes.txt @@ -8,7 +8,7 @@ This is (my guess) to permit the userWorkstations field to work. 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,6 +30,9 @@ I'll be very interested if the DAL really works for eDirectory too. 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 @@ Welcome to the wonderful world of canonicalisation 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 @@ The short name of the realm seems to be accepted for at least AS_REQ 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,6 +79,8 @@ Jean-Baptiste.Marchand@hsc.fr reminds me: > 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 @@ So, what does it mean for a library to be state machine safe? This is 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. + +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. + +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. -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. +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. . -I had hoped to use the 'GSSAPI export context' function to transfer +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,9 +219,59 @@ the kerberos libraries - 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@realm (win2k clients) +HOST/foo@realm (win2k clients, using netbios) +cifs/foo.bar@realm (winxp clients) +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 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 @@ We have modified Heimdal's 'hdb' interface to specify the 'type' of 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 @@ lib. This allows the KDC code to be as portable as the rest of samba 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 ------------------------ |