MIT support for site specific SRV records
Jeremy Allison
jeremy.allison at hp.com
Tue Mar 2 16:49:14 EST 2004
Sam Hartman wrote:
>>>>>>"Lars" == Lars <lh120 at hotmail.com> writes:
>
>
> Lars> Hi Any plans for implementing support in MIT Kerberos for
> Lars> Active Directory site awareness?
>
> In general, MIT is interested in Implementing IETF standards or
> ongoing work within the IETF for Kerberos. We aren't really
> interested in Microsoft-specific extensions unless and until these
> extensions go through the standards process.
>
> That said, we understand people would like to use MIT Kerberos as part
> of both clients of AD domains and servers to replace AD domains. We
> understand certain work needs to be done to make that easier. For
> non-IETF things, our preference is to create plugin architectures
> where new authorization data, preauthentication data, etc can be
> handled.
>
> We do support SRV records for locating KDCs as specified in
> draft-ietf-krb-wg-kerberos-clarifications-06.txt.
I hope I don't sound too presumptuous here, but I think this is a mistake
(IMHO).
Samba admittedly is a special case, our reason for existance is to
interoperate with Windows systems, but every time you adopt this stance,
(and I've seen it with the OpenLDAP people too) you force people to chose
all-Windows environments simply to get things to work.
There's no point in being a "clean" standards based implementation if
by doing so you become just a reference, unused by anyone.
What would be the harm in adding these extensions into the code, but
using a configuration parameter to have them turned off by default ?
Then the people requireing Microsoft compatibility could use MIT kerberos
out of the box, without plug-ins or third party extensions, and sites
wanting "pure" standards support could leave the extensions turned off.
What would serve your user community best ? What is your purpose with
this project ?
We in the Samba Team answered this question long ago, our reason is to
serve our users - "pure" compliance comes second.
Jeremy Allison,
Samba Team.
More information about the Kerberos
mailing list