Re: Current ideas on kerberos requirements for Samba4

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Michael Ströder
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
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
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-----
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
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-----
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Henrik Nordstrom-2
In reply to this post by Andrew Tridgell
On Wed, 25 May 2005, Andrew Tridgell wrote:

> Our typical user profile has changed a lot over the years. These days
> the typical Samba site has no sysadmin. It is installed by doctors,
> teachers and other professionals who are smart in their own field, but
> don't care about the intricacies of how Samba works, they just want it
> to serve files. Typically they have a network of just a few Windows
> PCs in a single realm (though they don't know what a 'realm' is).

After following this thread for some time and thinking on the deployment
cenarios I am not entirely sure this will be the case for Samba-4 in the
same sense.

As already mentioned initial adopters of Samba-4 is likely those wanting
to run it as an AD DC. In my view these is quite likely the same people
who have a reasonable understanding of what krb5 is and how LDAP works,
and now looking at Samba-4 to see if it can fit their existing
environments better than MS AD.

For those just wanting to serve files they quite likely already have an
Microsoft domain and mainly wants Samba to act in the existing domain as
an member server, not as the DC.

So I actually expect the 'enterprise' users to be among the first looking
at Samba-4 AD DC capabilities, with all the intrict details of krb5
integration etc. There is obviously also the odd "noob admin" which
attempts this, but hopefully most who do so is interested in learning.

Then when the Samba AD technology is slightly more prooven & documented
the masses will follow ;-)

This should give a quite reasonable window for OS maintainers to catch up,
provided the Samba requirements on the KDC and LDAP where applicable is
well documented with working reference implementations.

One sticky issue to consider is licensing if the OS maintainers are
supposed to include/link certain components of Samba into their KDC and/or
LDAP servers.

> It really is quite common that Samba is the first free software package
> that a site tries. If you think about it, I think you would agree that
> kerberos is almost never the first free software package someone tries.
> We have to make a good first impression, and that means making stuff as
> easy as we possibly can.

Agreed.

But at the same time do not forget that both LDAP and KDC servers is
common components of the OS:es these days.

Regards
Henrik
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

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.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Nicolas Williams
In reply to this post by Wyllys Ingersoll
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.

Cheers,

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Stefan (metze) Metzmacher
-----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-----
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Nicolas Williams
On Fri, May 27, 2005 at 08:00:18AM +0200, Stefan (metze) Metzmacher wrote:

> Nicolas Williams schrieb:
> > 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]

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

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

That's more like it I think.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

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

What I don't understand is why you want everything in one process --
what's wrong with IPC in this case?

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
123