Authentication to ADS

[Ken Raeburn]

Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:

> This brings up a question I've been wondering - when is MIT going
> to include TCP support, at least on the client side, so that they can
> receive and process TCP responses from AD ?

Next non-bug-fix release, currently labelled 1.3.  I've written the
basic code already, but support for tuning some parameters (e.g.,
minimum size of client-side request before we don't even bother trying
UDP) via the config file is still needed, although I think the
compiled-in defaults should be adequate for most environments.  If
people want to try out the daily snapshots and let us know of any
problems, please do -- but remember that they *are* automatic
snapshots, and are not tested before being made available.

Also, I may revamp the request loop so that TCP connections may be
tried before the UDP code times out or gets an error back -- for
example, in case the UDP packets are too large and simply get
discarded or completely corrupted, with no feedback to the client.
Something like, send a packet to each UDP KDC port, waiting a second
or so at each, if no replies, then start connecting to TCP ports, but
still retry the UDP ports if the TCP connections don't come through
quickly enough.

(Anyone familiar with T/TCP?  Are many systems implementing it?  Is it
worth trying to support in this client-side code?)


The server support is something I'm also looking into.  It's less of a
priority right now, but my understanding is cross-realm authentication
starting in a MS realm where the user has lots of groups will result
in a large cross-realm TGT, so server-side support could be important
for that case.  On the other hand, the denial-of-service issues can't
be ignored....

Ken