kerberos-notes.txt

samba最新软件

gss_krb5_context per process, and multiple GSSAPI encrypted sessions
at a time) but these may not matter in practice.

In the short-term, we deal with blocking by taking over the network
send() and recv() functions, therefore making them 'semi-async'.  This
doens't apply to DNS yet.

GSSAPI and Kerberos extensions
------------------------------

This is a general list of the other extensions we have made to / need from
the kerberos libraries

 - DCE_STYLE

 - gsskrb5_get_initiator_subkey() (return the exact key that Samba3
   has always asked for.  gsskrb5_get_subkey() might do what we need
   anyway)

 - gsskrb5_acquire_creds() (takes keytab and/or ccache as input
   parameters, see keytab and state machine discussion)

 - gss_krb5_copy_service_keyblock() (get the key used to actually
   encrypt the ticket to the server, because the same key is used for
   the PAC validation).
 - gsskrb5_extract_authtime_from_sec_context (get authtime from
   kerberos ticket)
 - gsskrb5_extract_authz_data_from_sec_context (get authdata from
   ticket, ie the PAC.  Must unwrap the data if in an AD-IFRELEVENT)
 - gsskrb5_wrap_size (find out how big the wrapped packet will be,
   given input length).

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, 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
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 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
----------------------------
(an attempt to list some of the Heimdal-specific functions I know we use)

krb5_free_keyblock_contents()

also a raft of prinicpal manipulation functions:

Prncipal Manipulation
---------------------

Samba makes extensive use of the principal manipulation functions in
Heimdal, including the known structure behind krb_principal and
krb5_realm (a char *).

Authz data extraction
---------------------

We use krb5_ticket_get_authorization_data_type(), and expect it to
return the correct authz data, even if wrapped in an AD-IFRELEVENT container.


KDC/hdb Extensions
--------------

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 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.

Callbacks:
 In addition, I have added a new interface hdb_fetch_ex(), which
 returns a structure including callbacks, which provide the hook for
 the PAC, as well as a callback into the main access control routines.

 A new callback should be added to increment the bad password counter
 on failure.

 Another possability for a callback is to obtain the keys.  This would
 allow the plaintext password to only be hashed into the encryption
 types we need.  This idea from the eDirectory/MIT DAL work.

 This probably should be combined with storing the hashed passwords in
 the supplementalCredentials attribute. If combined with a kvno
 parameter, this could also allow changing of the krbtgt password
 (valuable for security).

libkdc
------

Samba4 needs to be built as a single binary (design requirement), and
this should include the KDC.  Samba also (and perhaps more
importantly) needs to control the configuration environment of the
KDC.  

The interface we have defined for libkdc allow for packet injection
into the post-socket layer, with a defined krb5_context and
kdb5_kdc_configuration structure.  These effectively redirect the
kerberos warnings, logging and database calls as we require.

Using our socket lib
--------------------

An important detail in the use of libkdc is that we use our own socket
lib.  This allows the KDC code to be as portable as the rest of samba
(this cuts both ways), but far more importantly it ensures a
consistancy in the handling of requests, binding to sockets etc.

To handle TCP, we use of our socket layer in much the same way as
we deal with TCP for CIFS.  Tridge created a generic packet handling
layer for this.

For the client, we likewise must take over the socket functions, so
that our single thread smbd will not lock up talking to itself.  (We
allow processing while waiting for packets in our socket routines).

Kerberos logging support
------------------------

Samba now (optionally in the main code, required for the KDC) uses the
krb5_log_facility from Heimdal.  This allows us to redirect the
warnings and status from the KDC (and client/server kerberos code) to
Samba's DEBUG() system.

Similarly important is the Heimdal-specific krb5_get_error_string()
function, which does a lot to reduce the 'administrator pain' level,
by providing specific, english text-string error messages instead of
just error code translations.


Short name rules
----------------

Samba is highly likely to be misconfigured, in many weird and
interesting ways.  As such, we have a patch for Heimdal that avoids
DNS lookups on names without a . in them.  This should avoid some
delay and root server load.

PAC Correctness
---------------

We now put the PAC into the TGT, not just the service ticket.  

Forwarded tickets
-----------------

We extract forwarded tickets from the GSSAPI layer, and put
them into the credentials.  We can then use them for proxy work.


Kerberos TODO
=============

(Feel free to contribute to any of these tasks, or ask
[e-mail] about them).

Lockout Control
--------------

We need to get (either if PADL publishes their patch, or write our
own) access control hooks in the Heimdal KDC.  We need to lockout
accounts, and perform other controls.

Gssmonger
---------

Microsoft has released a testsuite called gssmonger, which tests
interop.  We should compile it against lorikeet-heimdal, MIT and see
if we can build a 'Samba4' server for it.

Kpasswd server
--------------

I have a partial kpasswd server which needs finishing, and a we need a
client testsuite written, either via the krb5 API or directly against
GENSEC and the ASN.1 routines.

Currently it only works for Heimdal, not MIT clients.  This may be due
to call ordering constraints.


Correct TCP support
-------------------

Our current TCP support does not send back 'too large' error messages
if the high bit is set.  This is needed for a proposed extension
mechanism, but is likewise unsupported in both current Heimdal and MIT.