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-17 at 01:36 +1000, Andrew Bartlett wrote:
> Just a quick note to let a few more people know that I am putting
> together a rough text document describing various things about kerberos.
> I'm sure parts are just complete fiction, but I'm still new to many
> parts of this game. :-)
>
> The idea is to write down the special things Samba4 will need from
> GSSAPI/Kerberos libraries and KDC implementations, however we end up
> producing things.

So, things have progressed a lot over the last week, and I want to fill
in the various concerned lists as to my current status, and the research
direction.  

KDC
---
The research direction so far shows that Samba4 can use Heimdal kerberos
for it's KDC needs: the only major remaining issue is the PAC
generation, and I know this is at least possible.  

We are currently looking at how we will start and plug into the KDC, and
I'm wondering if we can do so by linking the KDC code directly into the
main smbd process, just like our other services.

Linking directly 'in process' has a number of advantages, particularly
because I can then use many of the other facilities of Samba4 behind the
heimdal interfaces.  For example I can use our UTF8 manipulation code,
our full db layer (including ACLs as required for the password change
deamon), and not rely on getting all these bits into shared/static
libraries.

My current feeling is that Samba may well ship it's own KDC (based
either on Heimdal, our own code or potentially some other codebase) for
some time into the future.  To whatever extent Samba includes a
derivative of another distribution of kerberos, the aim would be to keep
the 'diff' between the two projects as small as possible, while
integrating the code for minimum administrative and engineering pain.

At an engineering level, this might entail a libkdc.a supplied either
with Samba, or perhaps at some long-future date, supplied by the
operating system.

Client Libs
-----------
A more open question surrounds the client libraries - Samba has very
particular needs for a 'state machine safe', 'asynchronous' and (to a
lesser extent) thread safe GSSAPI layer.  I'm still looking at what pain
it will take to modify Heimdal (mostly looking at the
gssapi_krb5_context) to meet these requirements.  I also need to look at
GNU GSS and the MIT libs here.   I intend to write some tests to show
the safety or otherwise of these libs, by constructing and using
parallel contexts.

In the short-term, my current research indicates that it should be
viable for Samba4 to ship a modified snapshot of Heimdal's
GSSAPI/Kerberos library, and use that library if the system libs are not
found suitable.  Indeed, my hope is that in the long-term, we will not
need to maintain these in Samba, and we will be able to use whichever
brand of system kerberos lib is available.  How this interacts with KDC
design will be another important point to watch.

> The current version (updated from SVN) is at:
> http://samba.org/ftp/unpacked/samba4/source/auth/kerberos/kerberos-
> notes.txt

I hope to keep this updated, as I make things more concrete.

In any case, this mail is a request for discussion - I want know if I'm
mad, and if so, what other solutions/suggestions do you have?

I do realise that the idea of a 'Samba KDC' still makes a number of
people uncomfortable, but I'm also at a loss to find software
engineering reasons to propose any other forward direction.  That is why
I'm writing this mail.

BTW, I also look forward to the public release of the code behind
http://web.mit.edu/jaltman/Public/Samba-XP-Presentation.pdf to see how
it compares/complements/contrasts with our current approach.  

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

Ken Hornstein
>My current feeling is that Samba may well ship it's own KDC (based
>either on Heimdal, our own code or potentially some other codebase) for
>some time into the future.  To whatever extent Samba includes a
>derivative of another distribution of kerberos, the aim would be to keep
>the 'diff' between the two projects as small as possible, while
>integrating the code for minimum administrative and engineering pain.

Just my $0.02:

I already have a hacked KDC (based on MIT) that has a number of custom
extensions that I need.  Running a Samba-supplied KDC is simply a
non-starter.  I know plenty of people who are in the same boat.  Just
as an aside - it seems when you do Kerberos for a while, you find that
you need to do some number of changes to make it fit better at your
site, so this sort of thing just tends to crop up.  This probably
isn't an issue for smaller sites, or sites that just want to run a KDC
to suppot Samba.

If you provide a chunk of code and say, "You need to integrate this",
then that's fine with me (if it's Heimdal-only, then that will be a
pain, but I can deal).  I know, I could always do cross-realm ... but
trust me, I have more experience with cross-realm than most people, and
I'm not going to run a seperate realm just for Samba.

--Ken
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

hartmans
In reply to this post by Andrew Bartlett
Andrew and I had this conversation on IRC, but I feel the need to
state the following publically for the record.

I think that Samba including a KDC based either on Heimdal or MIT is a
non-starter for several OS vendors.  They need to be able to treat
Samba as one Kerberos service that provides authorization, group
membership, etc.  However Samba will not be the only such service.
The OS vendors also have a strong requirement to have a single
Kerberos implementation.

That said, Samba needs to have a solution for users who are not OS
vendors.  Also, it seems reasonable that Samba does not want to do the
OS vendors work for them.


I do believe that linking the kdc into the smbd process really does
create an untenible situation for a lot of people and I think you will
find that the work required to get access to Samba facilities in a
native KDC is well worth the effort in the long run.

I do think it is reasonable and necessary at the current time for
Samba to include a KDC of some kind; I agree that Heimdal is the least
effort for Samba at the current time.

I think it is also important to work with OS vendors in this.  I think
you need to design Samba assuming that people will end up supplying
patches to plug Samba into the system KDC.  (Yes, I fully realize that
Samba will get involved in almost all aspects of handling a request).
I think it will be important to try and work with those vendors to
integrate their patches when such patches are written.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Andrew Bartlett
On Mon, 2005-05-23 at 14:50 -0400, Sam Hartman wrote:
> Andrew and I had this conversation on IRC, but I feel the need to
> state the following publically for the record.

And I'm glad to finally get a discussion going here, lest it be said
that we did our kerberos work in the shadows and the dark :-).  

> I think that Samba including a KDC based either on Heimdal or MIT is a
> non-starter for several OS vendors.  They need to be able to treat
> Samba as one Kerberos service that provides authorization, group
> membership, etc.  However Samba will not be the only such service.
> The OS vendors also have a strong requirement to have a single
> Kerberos implementation.
>
> That said, Samba needs to have a solution for users who are not OS
> vendors.  Also, it seems reasonable that Samba does not want to do the
> OS vendors work for them.
Indeed, I'm not going to 'do the OS vendors work for them', as I have
enough work to do getting this ship sailing at all, let along dealing
with the particular requirements of unnamed 'vendors'.  But I'm also at
a bit of a loss: aside from some desire 'not to ship more than one KDC',
I'm yet to hear what they feel 'they' need (or who these vendors are).  

It would be great if they could join in the discussion on samba-
technical.  Perhaps their requirements are more easily addressed than I
fear.

I would also like to see how this compares or contrasts with a desire to
'only ship one LDAP server', where we do hit a similar issue.  This is
something where we have had recent discussion.

> I do believe that linking the kdc into the smbd process really does
> create an untenible situation for a lot of people and I think you will
> find that the work required to get access to Samba facilities in a
> native KDC is well worth the effort in the long run.

I honestly don't see what we (or indeed an OS vendor) gains using a
'native' KDC (whatever that means).  Can you outline that in something
more concrete?

But I do by linking inside smbd (or other very close tying) we get to
control:
 - Startup/shutdown
 - network interfaces
 - configuration
all inside Samba itself.  This is perhaps the most tempting part -
knowing that the administrator cannot 'forget to start the kdc', or
'forget the magic lines in the /etc/krb5.conf'.  This makes our KDC fit
quite well with the overall design of Samba4 (one smbd to rule them
all...)

Also, by linking them closely, we can transparently access the same
routines for access control, PAC generation, string manipulation and the
like.  (Without trying to define static/shared library interfaces for
all of this, for the special case of the KDC only)  

Finally, if we ship our own KDC, we know what is on the other side of
the interface.  Vendor-supplied Kerberos libraries have been a nightmare
for us over the life of Samba3, I can't imagine what dealing with
plugins for an arbitrary vendor-supplied KDC would be like.  

> I do think it is reasonable and necessary at the current time for
> Samba to include a KDC of some kind; I agree that Heimdal is the least
> effort for Samba at the current time.
>
> I think it is also important to work with OS vendors in this.  I think
> you need to design Samba assuming that people will end up supplying
> patches to plug Samba into the system KDC.  (Yes, I fully realize that
> Samba will get involved in almost all aspects of handling a request).
> I think it will be important to try and work with those vendors to
> integrate their patches when such patches are written.
This all said, I am willing to work with anybody who can provide sane
patches, and can argue why they are a long-term viable proposition to
the project.  

I am not tied permanently to this direction, and good software
engineering arguments (preferably backed with patches) or unexpected
research results may certainly change my view.  

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 Ken Hornstein
On Mon, 2005-05-23 at 11:18 -0400, Ken Hornstein wrote:

> >My current feeling is that Samba may well ship it's own KDC (based
> >either on Heimdal, our own code or potentially some other codebase) for
> >some time into the future.  To whatever extent Samba includes a
> >derivative of another distribution of kerberos, the aim would be to keep
> >the 'diff' between the two projects as small as possible, while
> >integrating the code for minimum administrative and engineering pain.
>
> Just my $0.02:
>
> I already have a hacked KDC (based on MIT) that has a number of custom
> extensions that I need.  Running a Samba-supplied KDC is simply a
> non-starter.  I know plenty of people who are in the same boat.  Just
> as an aside - it seems when you do Kerberos for a while, you find that
> you need to do some number of changes to make it fit better at your
> site, so this sort of thing just tends to crop up.  This probably
> isn't an issue for smaller sites, or sites that just want to run a KDC
> to suppot Samba.
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, I'm targeting our KDC as a match for
the Microsoft interface, not as the new gold standard for KDCs in POSIX.

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.  

Now, I come at this whole area from rather a different direction than I
suspect you do, because I'm not steeped in the history of Kerberos, nor
do I run a large and complex site that uses it.  What is custom about
your kerberos setup, and given that I realise that having multiple
kerberos realms is the pits, what could we do to make your life easier?

> If you provide a chunk of code and say, "You need to integrate this",
> then that's fine with me (if it's Heimdal-only, then that will be a
> pain, but I can deal).  I know, I could always do cross-realm ... but
> trust me, I have more experience with cross-realm than most people, and
> I'm not going to run a seperate realm just for Samba.

Well, it will always be open source, so unlike AD you can hack it
however you please :-)

My observation is that sites fit into one of the these three boxes:

(98%) Never used Kerberos, or don't know what Kerberos is:
 - NT4 sites
 - Samba3 based sites
 - Low-clue AD networks (you don't need to understand Kerberos to use
AD)
 - Everybody else (most linux networks, workgroups)

(~1.75%) Large sites, which run AD, know what kerberos is and use it to
their advantage

(<.25%) Sites that chose to use unix-based kerberos systems, and have
integrated it properly into a majority of their systems.

My problem is that while I do *not* wish to exclude anybody, I need to
care about the first two categories far more than the clued-in SysAdmin
of a real kerberos site.  (Where I think that long-term, we can work
something out).

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

Howard Chu
In reply to this post by Andrew Bartlett
Andrew Bartlett wrote:

> On Mon, 2005-05-23 at 14:50 -0400, Sam Hartman wrote:
>>I think that Samba including a KDC based either on Heimdal or MIT is a
>>non-starter for several OS vendors.  They need to be able to treat
>>Samba as one Kerberos service that provides authorization, group
>>membership, etc.  However Samba will not be the only such service.
>>The OS vendors also have a strong requirement to have a single
>>Kerberos implementation.
>>
>>That said, Samba needs to have a solution for users who are not OS
>>vendors.  Also, it seems reasonable that Samba does not want to do the
>>OS vendors work for them.

> Indeed, I'm not going to 'do the OS vendors work for them', as I have
> enough work to do getting this ship sailing at all, let along dealing
> with the particular requirements of unnamed 'vendors'.  But I'm also at
> a bit of a loss: aside from some desire 'not to ship more than one KDC',
> I'm yet to hear what they feel 'they' need (or who these vendors are).  

The most fundamental principle of working in the Unix programming
environment is to create efficient single-purpose tools that play well
with other tools. The desire "not to ship more than one KDC" is not just
a petty foible, it's a key to efficiently deploying whatever limited
resources you have. Nobody wants to be wasting resources maintaining two
separate items with overlapping function.

And strange as it may seem, there will be plenty of sites out there that
want a KDC but don't want or need an SMB service. Moreover, there are
plenty of sites out there that already have a KDC that works for them.
It would be a waste of their resources to have to learn how to
use/administer yours. As Ken said, it would probably be more effort than
any sysadmin is willing to invest, to set up a cross-realm trust with
yours, when there should only be one realm in the first place. And they
may be stuck with something (like a DCE installation) where they already
have an irreplaceable KDC, and don't want to go through that heartburn
again. (Of course, a site running DCE won't play well with Samba4
anyway, since it will have its own rpc listener.)

Indeed, one should take a good hard look at DCE (and MS AD) and learn
from them, not make the same stupid mistakes over and over. It is
certainly important that your services are so well integrated that using
them is seamless. But it is also important that your services'
boundaries are so well defined that you can remove one component and
replace it with another one, at will.

> It would be great if they could join in the discussion on samba-
> technical.  Perhaps their requirements are more easily addressed than I
> fear.
>
> I would also like to see how this compares or contrasts with a desire to
> 'only ship one LDAP server', where we do hit a similar issue.  This is
> something where we have had recent discussion.

Yes... And as LDAP is a major piece of core infrastructure, it's another
example of "I have one working already, don't make me use another one."
People thought that meta-directories would be the solution to the
directory proliferation problem, but experience has shown that they just
turn the N-directory management problem into N+1. With that said, I'm
less worried about LDAP because there are valid reasons for keeping a
security management directory isolated from a general whitepages
directory, even if that creates redundant, overlapping directory namespaces.

> I honestly don't see what we (or indeed an OS vendor) gains using a
> 'native' KDC (whatever that means).  Can you outline that in something
> more concrete?
>
> But I do by linking inside smbd (or other very close tying) we get to
> control:
>  - Startup/shutdown
>  - network interfaces
>  - configuration
> all inside Samba itself.  This is perhaps the most tempting part -
> knowing that the administrator cannot 'forget to start the kdc', or
> 'forget the magic lines in the /etc/krb5.conf'.  This makes our KDC fit
> quite well with the overall design of Samba4 (one smbd to rule them
> all...)

Like I said, seamless operation is an admirable goal, but crossing
component boundaries and breaking abstraction layers is a mistake. The
biggest problem with asserting all the control you want here is that
Samba is not the only consumer of Kerberos service in a network. Also,
the simple reality of software complexity dictates that an integrated
KDC+SMB server will crash more frequently than separate standalone KDC
and SMB servers. It is inappropriate to deny Kerberos service to the
network due to an SMB failure.

> Finally, if we ship our own KDC, we know what is on the other side of
> the interface.  Vendor-supplied Kerberos libraries have been a nightmare
> for us over the life of Samba3, I can't imagine what dealing with
> plugins for an arbitrary vendor-supplied KDC would be like.  

> I am not tied permanently to this direction, and good software
> engineering arguments (preferably backed with patches) or unexpected
> research results may certainly change my view.  

Good software engineering practice dictates that when you have problems
working with someone's interface, the solution is to fix the interface,
not replace their backend with your own. I'm rather surprised that even
needs to be said, but apparently it does.

--
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support
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 18:23 +1000, James Peach wrote:
> On Tue, May 24, 2005 at 10:06:44AM +1000, Andrew Bartlett wrote:

> > It would be great if they could join in the discussion on samba-
> > technical.  Perhaps their requirements are more easily addressed than I
> > fear.
>
> I'm by no means even a Kerberos novice and I haven't been following the
> Samba4 code very closely, but maybe I can contribute some vendor
> perspective. These are personal opinions and do not necessarily reflect
> the official views or plans of SGI.
>
>     o Customers want a unified Kerberos infrastructure today. It would
>     be good if Samba4 brought us a step further to being able to
>     seamlessly use Kerberos for CIFS, NFS and local logins.
In this sense, Samba3 and Samba4 will be able to handle whatever KDC is
thrown at them, where they are just another kerberised service (just
accepting file shares).  What makes Samba4 different is that it is
trying to be compatible with Microsoft's Active Directory, so we have
sudden demand to 'provide' a KDC, because that's what our clients expect
(and they expect particular behaviours).

>     o Many vendors are already shipping multiple versions of Kerberos
>     and other crypto libraries for various reasons (not all of them
>     good). Each time this happens, there is a cost involved in code
>     maintenance, issuing security updates and patches, interop,
>     diagnosing customer problems, etc.
>
>     o The desire not to ship more that one KDC is pretty strong. I would
>     think that vendors supporting Heimdall and MIT KDCs feel they
>     already get enough support calls without a Samba KDC.

Is there a support call cost difference between a MIT or Heimdal KDC
with most facets of their operation influenced by a Samba module, and a
KDC built in and 'just working' inside Samba?  My argument is that where
Samba controls such a KDC from a logic perspective, it is already a
'different KDC'.

>     o Convincing customers to upgrade is (justifiably) hard. If I need
>     to upgrade Samba, will the customer be willing to risk the
>     corresponding KDC upgrade? If not, will I have to spin a
>     site-specific patch?

Samba4 will be a big change, but if you already have a KDC you are quite
happy with, you probably don't want to turn Samba4 on as a DC of any
sort anyway.  The fileserver will certainly not require it's own KDC.

>     o Finally, my guess is that vendors will eventually ship Samba4
>     whatever happens because there will be customer demand.

I think you are right on this one :-)

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 Ken Hornstein
On Mon, 2005-05-23 at 22:41 -0400, Jeffrey Hutzelman wrote:

> "What he said".  Seriously, I have strong reservations about such an
> approach from three standpoints:

"What tridge said".  But again on a serious point, I think tridge's post
may have missed some of you not on samba-technical, because the other
lists are subscriber posting only:

http://lists.samba.org/archive/samba-technical/2005-May/040869.html

> (1) From the point of view of a software engineer and protocol designer:
>
>     Kerberos is not part of your (or any) application; it is a core
>     infrastructure service which must be shared among many applications.

Perhaps I didn't make this point clear when I started this discussion,
but there seems to be a little confusion as to why Samba is suddenly
interested in the KDC space.  

Samba4 is an project with a very big goal - to provide a Free Software
implementation of the CIFS/SMB protocol, and all the other protocols
required in order to make it work with modern clients.  This has
extended to those protocols used by Active Directory.  

It is only in trying to meet the need for an 'AD-like' Kerberos service,
as required by Microsoft's clients, that we even enter this space.  It
is not Samba-as-a-file-server that moved us in that direction.

>     Good design requires a certain amount of modularity, with separate
>     tasks being performed by separate components communicating through
>     well-defined interfaces.  This allows each component to be managed
>     separately, and ensures that they will all interoperate.
>
>     Including the KDC in Samba will likely result in the two becoming
>     tightly coupled.  It will make it easier for smbd to violate all
>     sorts of abstractions and to depend on private interfaces which make
>     it fail to interoperate with standard KDC's.  If multiple applications
>     had such a requirement, they would be unable to coexist in the same
>     environment, because while a given Kerberos realm may support many
>     applications, it can have only one set of KDC's.
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).  

However, we also have a very different modal, where we are a domain
member, and in this modal we are much more relaxed as to what the KDC
is, and we will try and work with anybodies KDC.  The issues of managing
domains and trying to get Windows clients to accept our tickets will no
longer haunt us, and we can get on with life.

To make it clear, Samba4 as a member (non-DC) will have *no* special KDC
requirements, and I hope will be an even better Kerberos client citizen
than Samba3 is.

> (2) From the point of view of a Kerberos administrator:
>
>     As for Ken, that would be a total non-starter for me, due to both
>     security and maintainability considerations.  I'm uninterested in
>     incorporating into my KDC's a large pile of code which has nothing
>     at all to do with Kerberos and serves only as a source of potential
>     vulnerabilities.  I'm much more likely to run (or even port, if
>     necessary) a small, easily-analyzed plugin which provides only those
>     specialized Kerberos-related functions required by the application.

I suspect you would have no role for Samba4 leading an Active Directory
style domain, and nor would you wish the NTLM password algorithm
anywhere near your password database.

But I won't shut off the interfaces required to design such a plugin,
however I can assure you it will not be small.  (Particularly if you
consider the whole Samba4 suite that is required to be at the same IP).

> (3) From the point of view of someone who's faced similar issues before:
>
>     The primary purpose of OpenAFS is to provide a scalable, cross-platform
>     distributed filesystem.  

>     We want people to run a real KDC.  We've been in the business of
>     supporting a KDC unique to our filesystem application, and we didn't
>     like it one bit.  Just a friendly word of advice...

I appreciate the advise.  I think our situation is different, but I'll
no doubt look back in a few years and wonder what might have been... :-)

Thanks,

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

Howard Chu
Andrew Tridgell wrote:

> The motivation for building in a KDC and a LDAP server so it works
> 'out of the box' is to make life easy for the vast majority of Samba
> admins who have never setup kerberos or ldap before. When I first
> started on the ADS effort in Samba, I tried to get all the existing
> free software tools that implement the various protocols we need to
> work together. It took me several days of extreme frustration fighting
> with library versions, obscure error messages, protocols sniffs and
> new config formats to get to the point that I could make a simple
> kerberos authenticated ldapsearch request against a openldap server
> authenticated with my own MIT kerberos realm.

> It was possible, and it did eventually work, but it was
> extraordinarily painful. What was worse was that I was using a
> mainstream Linux varient and I was following step by step a howto on
> exactly how to set this up. If I tried to reproduce the same result on
> IRIX, AIX or Solaris I expect it would have taken far longer.

> I knew that if I told the Samba user community 'OK, to use Samba4 you
> need to go through all of that' then we would have reduced our user
> base by a factor of 100 or more. It is just too arcane.
>
> This is not just ancient history either. I attended a LUG talk a few
> weeks ago where the speaker demonstrated (over a period of about two
> hours) how to setup openldap with kerberos authentication, including
> creating a new realm etc. At the end of the two hours it still wasn't
> working.

The fact that you or some LUG presenter struggled with the process
doesn't mean that the process is broken or untenable. In the case of
whatever LUG talk you were at, they clearly hired the wrong speaker. I
can bring up a Heimdal KDC and OpenLDAP server playing together within
one minute from typing "make install". Of course, with Symas'
prepackaged OpenLDAP and Heimdal binaries, anyone can do it in a few
seconds after installing the depots/pkgs/RPMs/etc.

There are a lot of self-proclaimed LDAP experts out in the world making
money on their false claims, but their failure to produce results is no
indication of the true nature of the situation. There are a lot of bogus
HOWTOs out there claiming to give authoritative advice on setting up
Kerberos and OpenLDAP, but their authors are not active members of the
Kerberos or OpenLDAP software communities, and these authors obviously
have no idea what they're talking about.

Being a long-time active member of the Heimdal, Cyrus, OpenLDAP, and
OpenSSL communities, I must say I have never seen a question from you on
any of these lists regarding how to make OpenLDAP play with any
particular secure authentication mechanism, so I have to wonder where
you've been going for "expert" advice on the topics. It seems you've
gone to the wrong places thus far. When you work in isolation from the
community that develops this software, and complain of extraordinarily
painful experiences, I think you bring it on yourself. I find it rather
difficult to understand how someone who leads an open source project as
you do can have missed tapping into the abundant resources that open
source development provides.

Andrew Bartlett made a similar comment to your "mainstream Linux
variant"; it's common knowledge in the OpenLDAP community that major
distros like RedHat have been shipping extremely outdated OpenLDAP
releases. If you had simply checked the OpenLDAP web site, or the
mailing lists, it would have taken you no time at all to realize that
you were working with something obsoleted in 2002 and probably ought to
get something newer that worked reasonably.

It may be obnoxious to belabor the point, but it's something that has
puzzled me for quite some time; why does it take so long for people
using a software package to go back to the package's community for help
when they run into trouble? The READMEs, the INSTALL notes, everything
is plastered with URLs of where to find more information or ask
questions. And yet I still see people asking questions in obscure
corners of cyberspace, where there's little chance that anyone with an
answer will ever see the question.

Speaking as someone who first started working with Kerberos and AFS back
at UMich more than 15 years ago, I can tell you that "Having a really
simple KDC built in" would be a good way to invite security breaches
into a network. You might as well use eBones. When people who don't
understand security and encryption technology start rolling their own,
it's a recipe for disaster. (Just look at the fool who decided it was a
good idea to use the Unix crypt password as part of the AFS string2key
function. They only used the first 8 bytes of the crypt string, which
itself is a 13 character 6-bit-per-character encoding of a 56 bit DES
key. And the first two characters are just a salt. End result, the AFS
keys only have 36 bits of entropy, even though they thought they were
doing 56 bit DES. 15 years ago 56 bit DES was impractical to crack, but
36 bits? Anyone with an idle workstation could do it.)

The goals you've outlined for Samba4 are admirable. But worrying avout
losing your userbase should be secondary to worrying about getting the
job done right. If it takes a little longer to get it right, your
userbase will still come around in the end. If you muck it up at the
beginning and some high profile user's network gets compromised, you
will lose your userbase forever.

--
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Gerald Carter-4
In reply to this post by Andrew Bartlett
-----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.


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





cheers,  jerry
=====================================================================
Alleviating the pain of Windows(tm)      ------- http://www.samba.org
GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
"I never saved anything for the swim back."     Ethan Hawk in Gattaca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkyeMIR7qMdg1EfYRAr5GAKDi82AkLYaTnoNZvFQJC6hVUn3fqACgxqOF
GVuaXnptF81Yy9yYXF+JfCY=
=hQpk
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Howard Chu
In reply to this post by Howard Chu
Andrew Tridgell wrote:
> Howard,
>
> The type of users we are aiming at are not the ones who read
> documentation on ancillary packages. We have trouble enough getting
> our users to read the Samba docs, let alone reading the docs on half a
> dozen external services they would need to install to make Samba4
> work.

> For the types of end users we are aiming for, setting up a kerberos
> realm is like asking them to setup /etc/memcpy.conf. The fact that we
> call memcpy() in Samba is completely irrelevant to what our users are
> trying to achieve, which is to install a file server for their windows
> clients.  They don't care that we use memcpy(), and they don't care
> that recent versions of windows now send auth packets formatted
> according to krb5 standards.

We seem to have a basic philosophical disagreement here. I'll make one
more response in that regard and then let it drop. Yes, it is a Good
Thing to make software easier to use. But (IMO) it is Not a Good Thing
to cater to user ignorance. This is what the American entertainment
industry has been doing for decades. Yes, it makes that industry a tidy
profit year after year, and it also encourages more and more people to
turn off their brains.

As the developer of a piece of software that is extremely popular and
widely deployed, you are in a unique position to influence the world,
for good or ill. You can aim for the low engagement user, and drag the
rest of the world down to their level, or you can aim for a higher
grade, and encourage the world to come up to your standard. (Besides,
aiming to make software that even idiots can use is always a losing
proposition - as the saying goes, you can't make anything idiot-proof
because Nature will just make a better idiot.)

The issue is particularly critical here, because you're talking about
integrating a piece of security infrastructure. Security and ignorance
cannot coexist. Sure, people don't have to understand the 3-way
handshakes and all the encryption layers to be productive, but they do
have to understand the basic notions of Trust as it relates to
principals and realms. Nobody is going to just drop it in and turn it on
and go merrily on their way. Not even Windows administrators.

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

> One way of looking at this is that we are trying to protect the MIT
> and Heimdal communities from the hordes of Samba users asking you
> silly questions when Samba4 comes out :-)

Some times, hordes of annoying questions can be a good motivator for
projects to improve their docs and/or ease-of-use. It certainly exposes
weak spots...
--
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Ken Hornstein
In reply to this post by Andrew Bartlett
>Now, I come at this whole area from rather a different direction than I
>suspect you do, because I'm not steeped in the history of Kerberos, nor
>do I run a large and complex site that uses it.  What is custom about
>your kerberos setup, and given that I realise that having multiple
>kerberos realms is the pits, what could we do to make your life easier?

In terms of our Kerberos KDC ... we have the following customizations
(these are the ones I remember off-hand):

- Support for hardware preauthentication
- Special code to disable _some_ users if they don't kinit with the right
  enctypes
- Extended logging
- A weirdo protocol to support the use of a hardware token combined with the
  local host key (we have a special version of sudo that uses that).
- Special enctype selection code (to deal with breakage from older clients,
  but I suppose we don't need that anymore).

Those are just the ones I remember right now; there are probably others.
Oh, and you _do_ support IPv6, right? :-)

Note that none of these change the core protocol (well, hardware preauth
does, but while that protocol hasn't gone through the whole IETF process
yet, let's pretend it's standardized).

I think I've got more changes to the Kerberos codebase than most people
(well, except maybe for those losers at Stanford :-) ), but I try to adhere
to some rules.  First, no changes to the core protocol.  No changes to
existing APIs (except maybe the adding of flags, if the function takes
flags).  Adding new API functions is okay, but I try to avoid it if possible.
Changes to the KDC behavior (e.g., what enctypes the KDC decides to use)
are fine.  Changes to application servers are okay, but I prefer changing
the KDC.  Changes to the clients are to be avoided unless there is no
other way to accomplish what I need to do.

I guess the best thing to do would be to explain what I (as a site) need
to add in terms of functionality to the KDC.  If I need to generate PAC
information (for example), then that's one thing.  If you have code to
get out the group membership from your LDAP server (and if it worked
with MIT Kerberos), hey, even better :-)

>My observation is that sites fit into one of the these three boxes:
>[...]

I could believe your numbers, if we're talking about _sites_.  However,
if we throw number of users in the mix, I suspect the numbers will be
different (my experience is that some larger sites want more integration
and have already figured out Kerberos already).  But, for the sake of
this discussion, let's take your numbers as correct (they're probably
not far off).

>My problem is that while I do *not* wish to exclude anybody, I need to
>care about the first two categories far more than the clued-in SysAdmin
>of a real kerberos site.  (Where I think that long-term, we can work
>something out).

Hey, I understand your pain.  I mean, I basically spent a YEAR
messing around with Kerberos before I understood it well enough to
deal with deploying it at our site (at the end of that year, I
understood it all the way from the protocol level down to the APIs,
and had probably seen every Kerberos error message under the sun).
Is it reasonable to ask your typical guy who wants to run Samba to
do that?  Hell no!

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

--Ken
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

James F. Hranicky
In reply to this post by Andrew Bartlett
On Tue, 24 May 2005 19:56:33 +1000
Andrew Bartlett <[hidden email]> 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).  

I'm no expert on anything, but that's not going to stop me :->

Personally, I'm quite wary of seeing new KDC/LDAP implementations. We
already have good ones out there under active development, and I'd like
to see them used in the project instead of yet more code duplication.

I don't know the intimate details of what AD clients expect from an AD
controller, but I wonder if perhaps the requirements could be addressed
by a meta-smbd of sorts? The meta-smbd acts as an AD controller, but
passes off requests for various services to the respective daemons,
something like this:


  XP -- TGT/PAC req -->             -- AS_REQ --> Heimdal/MIT KDC
                                    <-- TGT --
                        meta-smbd
     <-- TGT/PAC                    -- Group LDAP req --> OpenLDAP
                        (genPAC)    <-- groups

That's just one example. I don't know how feasible it is, but I
just thought I'd throw the idea out.

Since one of the motivating factors for the integration of services is
the difficulty experienced when trying to integrate the various packages
to work together, perhaps this should be the area of focus for an AD
controller clone: scripts/configuration systems that make it easy to
combine all the various packages out there (Heimdal/SASL/OpenLDAP/etc)
to work together in a conherent way to form the basis for a production-level
AD controller. I know how hard it can be having done it myself, but I don't
know if that's a good reason to try to re-implement functions that are
already available in stable, actively-maintained packages. Focusing on
easing the integration seems a better route IMO.

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| [hidden email]                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Douglas E. Engert
In reply to this post by Andrew Bartlett
So far all the respondents to this thread represent the 2% of the sites
and have all be active with Kerberos and AFS for years, but do understand
the issues of the other 98%.

You have suggested a libkdc, and shipping someone else KDC. What about
the other way around, where you work with the KDC vendors, to add the hooks
needed to support your needs. In this way you could work your way gradually
into an existing Kerberos environment, and could also ship or point at
the KDC vendors to use.

It really comes down to what are the real requirements for the KDC
and what are the minimal changes required.

It would appear that the first thing needed is to add a PAC to a Kerberos
ticket for a samba server, or even to a TGT. From a first glance, a KDC
could make a simple call out to your libs to do this.

Also to start with, you may want to consider letting the KDC use its
own databases for its authentication information separate from
the authorization information you need for the PAC. This would
also make is much simpler on the KDC or existing sites.

I would really like to see them separate. Your AD replacement could
use the kadmin interfaces to update the KDC's databases much like the
kadmind does today if really needed.

This is only a first cut, but I would suspect that the authentication
and AD like authorization could be separated out keeping the KDC and
the AD functions pretty much separate.

I am sure the the Kerberos vendors would be glad to work with you.

As Howard and others have said, don't fall into the traps that DCE
and AD have falling into of tightly combining authentication and
authorization into a single server.


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, I'm targeting our KDC as a match for
> the Microsoft interface, not as the new gold standard for KDCs in POSIX.
>
> 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.  
>
> Now, I come at this whole area from rather a different direction than I
> suspect you do, because I'm not steeped in the history of Kerberos, nor
> do I run a large and complex site that uses it.  What is custom about
> your kerberos setup, and given that I realise that having multiple
> kerberos realms is the pits, what could we do to make your life easier?
>
>
>
> Well, it will always be open source, so unlike AD you can hack it
> however you please :-)
>
> My observation is that sites fit into one of the these three boxes:
>
> (98%) Never used Kerberos, or don't know what Kerberos is:
>  - NT4 sites
>  - Samba3 based sites
>  - Low-clue AD networks (you don't need to understand Kerberos to use
> AD)
>  - Everybody else (most linux networks, workgroups)
>
> (~1.75%) Large sites, which run AD, know what kerberos is and use it to
> their advantage
>
> (<.25%) Sites that chose to use unix-based kerberos systems, and have
> integrated it properly into a majority of their systems.
>
> My problem is that while I do *not* wish to exclude anybody, I need to
> care about the first two categories far more than the clued-in SysAdmin
> of a real kerberos site.  (Where I think that long-term, we can work
> something out).
>
> Andrew Bartlett
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

James F. Hranicky
In reply to this post by James F. Hranicky
On Tue, 24 May 2005 13:15:57 -0400
"Alan DeKok" <[hidden email]> wrote:

>   If we had a "uber-DB" underlying all of the daemons, this would be
> easy.  This is the implementation Microsoft has, which influenced
> their design.  I don't know if it was intentional, but the endless
> protocol integration makes it much more difficult for Samba to
> inter-operate with AD.

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?

Jim
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:
>
> 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?

Ciao, Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Ken Hornstein
In reply to this post by Andrew Bartlett
>Kerberos isn't easy to use or set up - period. Unless you're
>using a Windows KDC. That's just an unpleasant fact of life
>currently.

I can't argue that, unfortunately.  Whatever else we say about Microsoft,
they do a good job at putting a friendly face on a complicated technology
like Kerberos (I did once try getting some useful Kerberos logs out of
an AD server and I failed, but probably few people would need to do that).
This is the point where the open-source crowd is at it's weakest.

One additional point: _most_ (but maybe not all) open-source Kerberos
implementations support DNS SRV records to find the KDC (the same
way Windows finds it's KDC).  So at least for clients, the issue
of setting up krb5.conf correctly should be a non-issue.  Of course,
that doesn't really correct the OTHER half-billion error messages you
can run into when working with Kerberos :-)

--Ken
Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

hartmans
In reply to this post by Andrew Bartlett
>>>>> "Alan" == Alan DeKok <[hidden email]> writes:

    Alan> "James F. Hranicky" <[hidden email]> wrote:
    >> I don't know the intimate details of what AD clients expect
    >> from an AD controller, but I wonder if perhaps the requirements
    >> could be addressed by a meta-smbd of sorts? The meta-smbd acts
    >> as an AD controller, but passes off requests for various
    >> services to the respective daemons,

    Alan>   Except that AD requires that the other protocols talk to
    Alan> each other, too.  That is, they *all* share a common data
    Alan> set, and each protocol must server a view of the database,
    Alan> and that view must be consistent across all protocols.  This
    Alan> integration means that much of the internal state of each
    Alan> daemon must be exposed to others, and must be modifiable by
    Alan> others.

Yes, but keep in mind two things:

1) This state should be exposed through well-defined interfaces to
   allow for extensibity and code abstraction.  It should not be
   exposed through sticking everything together in one process.  Even
   Microsoft is finding that model is not working for them.



2) Long term, we need to allow our models to grow beyond the model
   Microsoft has provided for us.  The right model for a collection of
   Unix machines using NFSV4 isn't the same model as AD.  Clearly you
   need a way of exposing an AD schema to the AD protocols (including
   LDAP) but you also need a way to move beyond that schema internally
   so you can support all the environments that will run in your
   Kerberos infrastructure.

Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

hartmans
In reply to this post by Ken Hornstein
>>>>> "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.


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.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Current ideas on kerberos requirements for Samba4

Gerald Carter-4
In reply to this post by Gerald Carter-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henrik Nordstrom wrote:
| On Tue, 24 May 2005, Gerald (Jerry) Carter wrote:
|
|> 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 have always assumed the LDAP and KDC server componends
| of Samba4 is  only required if you run Samba as a domain
| controller, while in most if  not all interoperability
| situations Samba runs as a memberserver without
| the LDAP or KDC server components where this
| isn't an issue.
|
| Based on this I don't really see the concerns. But if
| the above isn't  true then I am truly concerned about
| how to deploy Samba4.

You are correct.  We are strictly talking about being an
AD DC here.

| If you want to run Samba as a AD domain controller (not
| as a member  server) then in my eyes is it quite reasonable
| that Samba provides a LDAP and KDC for this purpose.

My best guess is that the early adopters of Samba 4 will
be entirely for the AD  domain controller functionality.

I used to compare Samba 3 and 4 to apache 1.3 and 2.0.
But it really is not a good comparison.  Samba 3 and 4
are different code bases and in some ways different
projects with different goals.  I expect that Samba 3
and 4 will be deployed side by side for quite some time
until Samba 4 is able to completely replace all of the
crufty features that exist in Samba 3.





cheers, jerry
=====================================================================
Alleviating the pain of Windows(tm)      ------- http://www.samba.org
GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
"I never saved anything for the swim back."     Ethan Hawk in Gattaca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCk58LIR7qMdg1EfYRAl3NAJ0YVSXkuHH4kYsI3lYqacJl70RaigCfRX4Q
sqY6Vaow7LsMJAidhpeCB5w=
=IYKH
-----END PGP SIGNATURE-----
12