Re: Current ideas on kerberos requirements for Samba4

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
On Tue, 2005-05-24 at 19:57 +0200, Michael Ströder wrote:
> Andrew Bartlett wrote:
> >
> > This is the situation we are in currently, the Microsoft clients expect
> > a very tight interface between the KDC and the rest of the domain
> > controller (requiring coherent operations over multiple protocols, the
> > PAC and other fun things).  
>
> Are you also going to implement a DNS server?

From what I've see, DNS is the one part of the AD game that Microsoft
has allowed an external implementation of.  It appears that the clients
and servers all do DNS updates separately to their main record in AD.
So fortunately we get to avoid that one :-)

Now, we will have to patch and convince vendors to patch and ship an
updated DNS server running 'TSIG', just as we will need them to patch
and ship an NTP server for 'schannel signing'.

This is indeed slightly contradictory, but in the experimentation I've
done, the lack of these services isn't nearly as critical as Krb5, and
the changes we propose are much smaller than we require to krb5.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
In reply to this post by Andrew Bartlett
On Tue, 2005-05-24 at 15:07 -0400, Alan DeKok wrote:
> "James F. Hranicky" <[hidden email]> wrote:
> > Well, my first reaction is that since Heimdal and Samba can currently both
> > share an LDAP database for PDC support, could it be possible to do the
> > same with AD?
>
>   1) Investigate what AD needs from protocol data sharing

Wrote the thesis:
http://samba.org/samba/news/articles/abartlet_thesis.pdf

>   2) Investigate how this would be put into LDAP

We have done so, and implemented our own 'ldap like' interface backing
onto either LDAP or an in-memory database.

>   3) Investigate how it would be implemented in Heimdal, etc.

Done that.  See the version of Heimdal in 'lorikeet'
svn co svn://svnanon.samba.org/lorikeet/trunk/heimdal lorikeet-heimdal

>   4) Report back.

This series of notes.  I was certainly not going to be so silly as to
talk about this before I had spent time to actually implement a viable
proposal.

>   My bet is that you'd need (0) to do this:
>
>   0) Get contract to spend 6 months working on the following

Yes, it took about 6 months, on and off.  

We do actually, already implement a good series of interfaces which
keeps the KDC separate.  Currently they don't even share any source code
aside from standard shared/static libraries we provide.  

However, to finish off the job, I'm proposing to integrate at the object
link level (with lukeh tells me he has done before) and to handle some
things consistently across the whole suite (no user config errors).  

Now, the mistake I made was opening my big trap before I had just
quietly finished the libkdc part (which is a few days integration, I
hope, and actually doesn't change Heimdal's internal structure very much
anyway).  

Jeremy is right about kerberos patches, and it has been a right pain in
Samba3.  This is why I've tried not to promise the world to those
running their own KDCs.  I know their plight, and I'll be receptive to
patches, but I'm just going to try and get mine working first.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
In reply to this post by Gerald Carter-4
On Tue, 2005-05-24 at 08:09 -0500, Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Bartlett wrote:
>
> | Perhaps we should make something clear from the
> | outset.  Just as Samba4's LDAP server is not
> | intended to be a world-class (or even standards-conforming)
> | LDAP server,
>
> Andrew,
>
> I'm not getting into this thread for obvious reasons, but
> I think this is a very dangerous statement (and assumption)
> to make. You are claiming to match against AD.  That's a
> big order from the LDAP side of things.  People will expect
> you to get the LDAP part right if you are taking it over.
Indeed, and this is actually something that I do worry about with Samba4
going forward.  I do wish we had more directory experts working with the
team, so we don't make more of a muddle of ourselves in the process.

I'll also pass the blame along on that one, the standard on the LDAP
server was set by others, I'm just repeating it (and trying not to
promise the world.  As we all so painfully know, this is a very small
team doing a lot of work...).

> If you want to add interoperability back to the buffet, then
> the Samba4 kdc implementation (and LDAP implementation)
> will have to be world class, scalable implementations.
> I think you might also be ignoring the fact that while CIFS
> is primarily a Windows protocol, LDAP and Kerberos will be
> used by non-MS clients and so at some point you will
> have to support them as well.

This is actually why I have pushed to work with Heimdal, rather than the
more appealing (at times) option of doing it ourselves.  At least I know
that when we started, we worked from a well respected KDC in production
use for this kind of task already.  My intention is to (despite linking
for unification of service control and socket infrastructure) keep the
codebases separable along existing or new interfaces in the Heimdal
code.  In that way, I hope to keep those qualities in Heimdal, even as
we integrate it.  I was just hoping not to promise the world to a
community that each holds their sites specific kerberos infrastructure
very near and dear :-)

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Keith Matthews
In reply to this post by Gerald Carter-4
This originally sent to Jerry by mistake.


I too do not wish to stoke any flames, but Jerry has made a point I
support (albeit not a kerberos one for which I apologise).

On Tue, 24 May 2005 08:09:32 -0500
"Gerald (Jerry) Carter" <[hidden email]> wrote:


> The other side of the fence is to reimplement AD.  A
> very admirable goal.  But to be 100%, you are not longer
> acting as a thin layer of glue.  In some ways, Samba
> no longer acts as an interoperability tool.  It the network
> portion of the OS.
>
> At this point the justification to install Samba is
> not based on interoperability because Samba is acting
> just like AD.  Not solving existing interoperability issues
> between Unix and AD.  The justification of installing
> Samba is based on license fees.
>
> If you want to add interoperability back to the buffet, then
> the Samba4 kdc implementation (and LDAP implementation)
> will have to be world class, scalable implementations.
> I think you might also be ignoring the fact that while CIFS
> is primarily a Windows protocol, LDAP and Kerberos will be
> used by non-MS clients and so at some point you will
> have to support them as well.
>


I don't work with any sites that use AD. I do inhabit mailing lists that
are heavily into mail systems. An increasingly common subject is how to
sensibly run serious MTAs as protection for MS Exchange server. This
requires the MTA to know about the users in the system and requires
seriously scalable access to the LDAP side of AD.  For big sites, the
problems are major in that lack of scalability can result in their email
system going down under a spammers' dictionary attack.
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
In reply to this post by Howard Chu
On Tue, 2005-05-24 at 07:32 -0700, Howard Chu wrote:

> Andrew Tridgell wrote:
> > I think that Samba3 is far to hard too install and configure. I want
> > to make Samba4 much easier, and my fear is that it will in fact become
> > much harder as we start to become dependent on more external tools.
>
> You can create a nicely integrated package from multiple components
> without needing to reimplement all of the components. Symas has done it
> with our CDS packages (OpenLDAP+BerkeleyDB+Cyrus SASL+Heimdal+OpenSSL),
> and PADL has done it with XAD. You get far more mileage out of your own
> time and resources by leveraging what already exists. When you run into
> rough edges, you beat them into submission and move on...  ;)
Just p

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

The 'perfect' LDAP+Krb5+glue setup (was: Re: Current ideas on kerberos requirements for Samba4)

Andrew Bartlett
In reply to this post by Howard Chu
On Tue, 2005-05-24 at 07:32 -0700, Howard Chu wrote:

> Andrew Tridgell wrote:
> > I think that Samba3 is far to hard too install and configure. I want
> > to make Samba4 much easier, and my fear is that it will in fact become
> > much harder as we start to become dependent on more external tools.
>
> You can create a nicely integrated package from multiple components
> without needing to reimplement all of the components. Symas has done it
> with our CDS packages (OpenLDAP+BerkeleyDB+Cyrus SASL+Heimdal+OpenSSL),
> and PADL has done it with XAD. You get far more mileage out of your own
> time and resources by leveraging what already exists. When you run into
> rough edges, you beat them into submission and move on...  ;)
(now where did that send button jump out from...)

Just picking up this point for a moment:  Aside from your fine
commercial products, is there any public document that describes how to
do this?  

As you know, I've been working to make Samba3 play nicer in such a
setup, in the hope that I might one day get the time to deploy it at
Hawker (I deploy parts of this mix, to mixed success).  Entirely aside
from my Samba4 work I would love to be able to point admins,
particularly of Unix-oriented sites to a known working description of
how to do this.  

As you said before, it should be just 'make install', and we shouldn't
be so easily mislead by those 'self-proclaimed LDAP experts'.

I would love to be able to brow-beat the vendors we are still on
speaking terms with into actually shipping this combination *configured
correctly*, and I would love to see vendors taking advantage of the
'just add water' Heimdal KDC (0.7pre) when using the Samba3 LDAP schema
(removing the 're-enter the password' battle that scares off most first-
time kerberos admins).

Are there vendors other than Symas (I'm thinking Operating System/Linux
Distribution vendors in particular), who get this right, out of the box?

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
In reply to this post by hartmans
On Tue, 2005-05-24 at 16:30 -0400, Sam Hartman wrote:

> >>>>> "Jeremy" == Jeremy Allison <[hidden email]> writes:
>
>     Jeremy> On Tue, May 24, 2005 at 11:34:52AM -0400, Ken Hornstein
>     Jeremy> wrote:
>     >> I think given your requirements, shipping a _basic_ KDC is
>     >> probably unavoidable.  I just wanted to point out that there is
>     >> a number of us who really want to use our own KDCs with Samba4,
>     >> and we'd like you to be able to deal with that at some point.
>     >> I don't think there's a huge amount of work you have to do to
>     >> make that happen (at least, I hope not).
>
>     Jeremy> We'll try and accomodate this, as we have accommodated
>     Jeremy> people who want to use their own keytabs in Samba3. But
>     Jeremy> let me tell you that this code (in Samba3) has taken 90%
>     Jeremy> of the work for less than 10% of the users. Even people
>     Jeremy> wanting this to work send incorrect, memory-leaking
>     Jeremy> patches.
>
> If you actually do this, I think we'll all be happy.  If you even
> design to support this model but demand that the people who want it to
> work with their own KDCs send in working code, I think we'll be happy.
> I completely agree that you need some sort of KDC in the samba
> distribution that is known to work with Samba and that is easy to set
> up and that hopefully the user doesn't even notice.
Then I think we all can be happy.

> However I'm hearing from Andrew that he's choosing a design that will
> make it very challenging for people to supply their own KDC and that
> is where I have concerns.

I'm really not trying to screw MIT (or anybody else) over, and the
current work is nicely isolated behind various interfaces.   The future
work should be as well, if I ever want a hope of continuing to update to
newer versions of Heimdal.  The use of linking will help me comply with
the Samba4 policy of 'one smbd', and handle a few startup/sockets
issues, I don't expect it to drastically alter the structure of the
code, or provide interfaces which are 'impossible' to export to a
different KDC.

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

hartmans
>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:

    >> own KDC and that is where I have concerns.

    Andrew> I'm really not trying to screw MIT (or anybody else) over,


I certainly have never gotten that impression.  Your phrasing of
certain things has made things challenging on a political level but I
understand your goal is to get a good technical solution not to play
politics.


I do think the discussion here is mostly technical and I'd like to
keep it that way.

As an aside, I've invited some vendors to join in and contribute
requirements.  I hope they will join, but more importantly I hope they
will contribute the necessary resources (or fund others) to make their
requirements a reality.  That's the only way technical problems get
solved.



Let me summarize the requirements I'm hearing today and see if we're on the same page:

1) Samba must be usable.  It must provide a single integrated solution
   that works for users with no knowledge of Kerberos, LDAP and other
   protocols.

2) Samba needs to be involved in most aspects of the KDC request handling.  It needs to add PAC data.  It needs  to authorize or deny requests.

3) Samba needs to keep account data in sync between Kerberos, LDAP and
   other protocols that access that data.  Passwords are particularly
   challenging to sync.  Samba plans to meet this need by storing all
   the data in a Samba-managed database and to manage password->key operations itself.

4) Vendors and sites want a single Kerberos implementation from a
   security patch, local extension and maintainability standpoint.

5) Vendors want to integrate Samba as one protocol frontend/data
   producer into larger systems.  We haven't really heard from the
   vendors on this one; it is mostly me babling on this point.


6) Kerberos implementers want to minimize code forks.

7) Kerberos implementers want to minimize the number of
   interoperability test targets.

Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Michael Ströder
In reply to this post by Andrew Bartlett
Andrew Bartlett wrote:

> On Tue, 2005-05-24 at 08:09 -0500, Gerald (Jerry) Carter wrote:
>
>>Andrew,
>>
>>I'm not getting into this thread for obvious reasons, but
>>I think this is a very dangerous statement (and assumption)
>>to make. You are claiming to match against AD.  That's a
>>big order from the LDAP side of things.  People will expect
>>you to get the LDAP part right if you are taking it over.
>
> Indeed, and this is actually something that I do worry about with Samba4
> going forward.

Will Samba4 implement the very same LDAP schema like MS AD? You might
have to since some LDAP-based management applications assuming to access
AD might expect certain schema elements. And maybe you also have to
implement some very special things like handling of attribute
'unicodePwd' etc.

Tough and ugly thing to do...maybe also for legal reasons.

> I do wish we had more directory experts working with the
> team, so we don't make more of a muddle of ourselves in the process.

The LDAP server in Samba4 is on my radar for interoperability tests with
my own tool web2ldap. But I didn't have the time to test it yet. This is
simply a problem of limited spare time. Now if there are many Open
Source LDAP server implementations each of it will not receive enough
testing because spare time has to be divided. But testing by the
community is really essential for success...

Ciao, Michael.

--
Michael Ströder
E-Mail: [hidden email]
http://www.stroeder.com
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Stefan (metze) Metzmacher
In reply to this post by Gerald Carter-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerald (Jerry) Carter schrieb:

> Andrew Bartlett wrote:
>
> | Perhaps we should make something clear from the
> | outset.  Just as Samba4's LDAP server is not
> | intended to be a world-class (or even standards-conforming)
> | LDAP server,
>
> Andrew,
>
> I'm not getting into this thread for obvious reasons, but
> I think this is a very dangerous statement (and assumption)
> to make. You are claiming to match against AD.  That's a
> big order from the LDAP side of things.  People will expect
> you to get the LDAP part right if you are taking it over.
>
>
> | I'm targeting our KDC as a match for the Microsoft
> | interface, not as the new gold standard for KDCs in POSIX.
>
> Again, I think this is a dangerous assumption to make.
> .
> | I'm trying to fill the space currently filled
> | by Microsoft's Active Directory, not trying
> | (particularly in the first release of Samba4) to
> | replace an existing corporate Kerberos infrastructure.
>
> But in a way you are and I think that is the concern that
> is expressed.  This is a tough road.
>
> I think there are two basic philosophies at work here.
> One is to use Samba as a bridge between Windows and Unix.
> Here Samba is a thin layer of glue.  We have posix
> mappings of ACLs, lpr print queues exported to clients,
> and posixAccounts integrated with Samba accounts.
>
> The other side of the fence is to reimplement AD.  A
> very admirable goal.  But to be 100%, you are not longer
> acting as a thin layer of glue.  In some ways, Samba
> no longer acts as an interoperability tool.  It the network
> portion of the OS.
>
> At this point the justification to install Samba is
> not based on interoperability because Samba is acting
> just like AD.  Not solving existing interoperability issues
> between Unix and AD.  The justification of installing
> Samba is based on license fees.
>
> If you want to add interoperability back to the buffet, then
> the Samba4 kdc implementation (and LDAP implementation)
> will have to be world class, scalable implementations.

I strongly agree here! (but we might not able to get to that stage for the first releases...)

> I think you might also be ignoring the fact that while CIFS
> is primarily a Windows protocol, LDAP and Kerberos will be
> used by non-MS clients and so at some point you will
> have to support them as well.
yes! as a MS ADS LDAP Server also support every LDAPv3 client...
So we also have to support all basic LDAPv3 features!

- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClJe8m70gjA5TCD8RArMqAKDGJiBxWBYKJTcBbHRpE6KVqncbqwCfRb1M
xYAlvIeWx557dU84UVWBC9E=
=NUqh
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Stefan (metze) Metzmacher
In reply to this post by Michael Ströder
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ströder schrieb:

> Andrew Bartlett wrote:
>
>>On Tue, 2005-05-24 at 08:09 -0500, Gerald (Jerry) Carter wrote:
>>
>>
>>>Andrew,
>>>
>>>I'm not getting into this thread for obvious reasons, but
>>>I think this is a very dangerous statement (and assumption)
>>>to make. You are claiming to match against AD.  That's a
>>>big order from the LDAP side of things.  People will expect
>>>you to get the LDAP part right if you are taking it over.
>>
>>Indeed, and this is actually something that I do worry about with Samba4
>>going forward.
>
>
> Will Samba4 implement the very same LDAP schema like MS AD? You might
> have to since some LDAP-based management applications assuming to access
> AD might expect certain schema elements. And maybe you also have to
> implement some very special things like handling of attribute
> 'unicodePwd' etc.
yes, but we still need to analyse what is so special with this attribute...

the current idea is this:
a) we are the first DC in the ADS Forest:
   then we provide a very small part of the real MS AD schema,
   just enough to provide services for standard MS Clients
b) if we are not the first DC in the Forest, we just fetch the Schema Partition in the first
   replication cycle from an existing DC in the forest. And then we have the same schema
   as all other DC's


- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFClJ1Qm70gjA5TCD8RArTKAJ9cJT465qzQrRF8IC8V+aQgB3WB3QCYrIjW
EAFJvrNUEIJQeU9QOkK0aw==
=ee6e
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
In reply to this post by hartmans
On Tue, 2005-05-24 at 22:48 -0400, Sam Hartman wrote:

> >>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:
>
>     >> own KDC and that is where I have concerns.
>
>     Andrew> I'm really not trying to screw MIT (or anybody else) over,
>
>
> I certainly have never gotten that impression.  Your phrasing of
> certain things has made things challenging on a political level but I
> understand your goal is to get a good technical solution not to play
> politics.
>
>
> I do think the discussion here is mostly technical and I'd like to
> keep it that way.
Indeed.

> As an aside, I've invited some vendors to join in and contribute
> requirements.  I hope they will join, but more importantly I hope they
> will contribute the necessary resources (or fund others) to make their
> requirements a reality.  That's the only way technical problems get
> solved.
>
>
>
> Let me summarize the requirements I'm hearing today and see if we're on the same page:

This set of requirements seems pretty correct to me.

> 1) Samba must be usable.  It must provide a single integrated solution
>    that works for users with no knowledge of Kerberos, LDAP and other
>    protocols.
>
> 2) Samba needs to be involved in most aspects of the KDC request handling.  It needs to add PAC data.  It needs  to authorize or deny requests.
>
> 3) Samba needs to keep account data in sync between Kerberos, LDAP and
>    other protocols that access that data.  Passwords are particularly
>    challenging to sync.  Samba plans to meet this need by storing all
>    the data in a Samba-managed database and to manage password->key operations itself.
>
> 4) Vendors and sites want a single Kerberos implementation from a
>    security patch, local extension and maintainability standpoint.
>
> 5) Vendors want to integrate Samba as one protocol frontend/data
>    producer into larger systems.  We haven't really heard from the
>    vendors on this one; it is mostly me babling on this point.
>
>
> 6) Kerberos implementers want to minimize code forks.
>
> 7) Kerberos implementers want to minimize the number of
>    interoperability test targets.
>
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The 'perfect' LDAP+Krb5+glue setup (was: Re: Current ideas on kerberos requirements for Samba4)

hartmans
In reply to this post by Andrew Bartlett
Apple gets what they want to do right out of the box.  However there
goals are a bit different than the goals you describe.

Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Stefan (metze) Metzmacher
In reply to this post by Douglas E. Engert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Williams schrieb:

> On Tue, May 24, 2005 at 07:14:54PM -0400, Wyllys Ingersoll wrote:
>
>>I work for one of the "Vendors" described earlier and I am
>>uncomfortable with the idea that SAMBA would include their
>>own KDC.
>>
>>My thoughts when I first read this thread were much like what
>>Doug has suggested - instead of creating a whole new KDC,
>>why not open up some interfaces on both sides - other KDCs
>>(MIT, Heimdal) and in SAMBA so that the necessary communication
>>can be exchanged and SAMBA can integrate with pre-existing
>>KDCs.   I know there are alot of people in the Kerberos
>>community that would probably be able to help define these
>>interfaces and make sure that they get implemented
>>by the various implementors.
>>
>>By having SAMBA provide a new KDC puts people currently using
>>MIT or Heimdal in the same position that they are today with
>>AD - they must maintain 2 KDC and REALMS or drop their
>>existing KDC infrastructure (MIT or Heimdal) and go with
>>SAMBA.
>>
>>Anyway, I applaud your efforts in the area of making a
>>fully compliant AD-like server, but I am not so supportive
>>of creating yet another KDC and further fracturing the
>>Kerberos community by forcing a choice like this.
>
>
> What Wyllys said.
>
> The Samba team can go and do what they like -- there's plenty of KDC
> source code with sufficiently friendly licensing to go around.  But I'd
> much rather see cooperation (and cooperate) in the design of pluggable
> interfaces for KDCs, such as pluggable backends, pluggable
> pre-authentication provides, and pluggable authorization-data providers
> (particularly AD-KDCIssued containees), and later, when extensions comes
> along, pluggable ticket extensions providers.

yep, I think that is what we are aiming for...
and just also an interface to hook into the kdc packet parse functions,
so that we can controll the network interface and raw data from the wire in our
async event driven infrastructure...

so the design would be like this:

[wire] -> [samba socket lib] -> [samba kdc server service] -> [KDC library]
[wire] <- [samba socket lib] <- [samba kdc server service] <- [KDC library]

or as alternative if the admin wants to run the kdc seperate, he just starts the [KDC binary]
which is internally also uses its [KDC library], and on some Platforms/Systems the Vendors
can make the [KDC library] shared. So for security updates just need an update of the shared library.

- From the [KDC library] it looks like this:

[KDC library]-> [db backend] -> [samba ldb backend]
[KDC library]-> [pre-auth]   -> [samba pre-auth backend]
[KDC library]-> [auth-data]  -> [samba auth-data backend]
...

- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClrdxm70gjA5TCD8RAp+7AKCYBQhYCMr6oPgqLVuR39AzPfiOHwCeOb01
bF/uOkVcqDeu9Xi+V2XlayQ=
=8PSt
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
On Fri, 2005-05-27 at 01:16 -0500, Nicolas Williams wrote:

> On Fri, May 27, 2005 at 01:06:55AM -0500, Nicolas Williams wrote:
> > On Fri, May 27, 2005 at 08:00:18AM +0200, Stefan (metze) Metzmacher wrote:
> > > so the design would be like this:
> > >
> > > [wire] -> [samba socket lib] -> [samba kdc server service] -> [KDC library]
> > > [wire] <- [samba socket lib] <- [samba kdc server service] <- [KDC library]
> >
> > I suppose I don't mind a "KDC library too much..." but, methinks that this
> > is going too far.  My first reaction, really, is "ick."
>
> BTW, I think coding services in such a way that they can be made into a
> library with ease is a good idea.  But usually existing code has not
> been written that way...  I think you'll find the alternative easier to
> implement.
I'll let you know in a few days, but for Heimdal this seems to be mostly
sane, and as I may have said elsewhere, it fits with the other Samba4
requirements I am under.

I actually hope that vendors *do not* create and ship their own libkdc,
particularly in the early days of Samba4.

The reason I hope this is because while high-clue, large site sysadmins
have a good chance of getting it right, and testing within their own
site, I am not looking forward to the text matrix explosion that will
occur if every vendor rips out and replaces the few thousand lines of
KDC.

I won't block it by overly silly design, and I will look reasonably at
real patches, but I'm just trying not to encourage it.  (There is only
one of me to manage all this complexity).

I also just expect that in the early days of Samba4, the interfaces and
expectations will wobble around, as we try and build one KDC that
works...

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
12