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

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

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

[hartmans]

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

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

[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

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

[Andrew Bartlett]

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

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

[Howard Chu]

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

[Jeffrey Hutzelman]

On Monday, May 23, 2005 11:18:00 AM -0400 Ken Hornstein
<[hidden email]> 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.
>
> 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

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


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

    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.


(2) From the point of view of a Kerberos administrator:

    Like Ken, I run Kerberos and other infrastructure for a site with
    fairly complex requirements.  Like Ken, my KDC's run modified
    software with a number of local extensions (not the same ones).
    My KDC's are carefully managed and tightly secured.  They run on
    dedicated, locked-down machines in locked cabinets in locked rooms
    with video surveillance and direct-to-paper logging.  Both network
    and physical access to the machines is tightly controlled, and only
    about 5 people have the ability to log in to them.  The KDC software
    is based on a distribution signed by someone personally known to me,
    and most of the other code has been carefully analyzed as well.

    I'll admit that most sites probably aren't quite as paranoid as we
    are, and certainly most don't chat with their KDC vendor on a daily
    basis.  But a good number of people are that paranoid, or more, and
    even those who don't have custom KDC modifications are unlikely to
    want to run some application-specific KDC with unknown properties.

    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.


(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.  Unfortunately, the OpenAFS distribution has
    traditionally included quite a number of tools which are not related
    to this purpose.  Among other things it includes an FTP server, inetd,
    login, an NTP server, rlogin/rsh, a software maintenance tool (package),
    and yes, an authentication service.

    All of these components are old, poorly maintained, and have been
    obsoleted newer, better software available elsewhere.  Some of them
    are downright dangerous, and building them requires the use of a
    special configure switch (--enable-insecure).  What's worse, most of
    these packages have _always_ been this way, since day one.  This
    stuff was in the Transarc distributions over a decade ago, and it
    was obsolete and insecure back then, too.

    We recently decided to remove nearly all of these independent packages
    from the OpenAFS tree, and concentrate more fully on our core purpose.
    Of the components I mentioned above, the only ones we haven't thrown
    away are package (which probably should be) and the kaserver, which
    we've kept around only because there are a few sites out there who
    still depend on it.  Note that anytime someone comes to us with a
    question of the form "we're running the kaserver and...", the answer
    is "don't do that; go get a real KDC".

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


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

[Andrew Tridgell]

Sam,

Perhaps I should explain a bit more what the motivation is for moving
services like ldap and krb5 inside of Samba.

The Samba user community is very diverse. Some of our users are the
sorts of people who are comfortable with setting up and diagnosing
openldap, MIT or heimdal kerberos, FreeDCE etc. The vast majority
would find having to setup all those services a big burden. By
comparison Samba3 is really easy to setup in the way that most people
operate it - which is either as a standalone server or a member of an
existing windows domain.

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 users we are aiming for in Samba4 would not know a realm if it hit
them in the face. They probably think a 'distinguished name' is
something given to people in the queens honours list. They certainly
don't know what kind of cheese to ask for in a SPNEGO sandwich :)

In implementing Samba4, we need to get all of the following protocols
to talk together perfectly:

  - SMB/CIFS
  - DCE/RPC over ncacn_np and ncacn_ip_tcp
  - DNS
  - krb5
  - LDAP
  - CLDAP
  - WINS
  - NBT name service
  - NBT datagram service

all of these are interwoven to a high degree, and they need to be
completely coherent with respect to their data storage. When a WinXP
box talks to us, it creates a lump of data with one protocol, queries
that data with a 2nd protocol in the next request then modifies the
same data using a 3rd protocol in the request after that.

The usual reaction from unix developers when they hear this is "well
don't use that windows crap then". The problem is that the point of
Samba is to allow people to use windows if they want to. We are
delighted to hear about people who have migrated their clients away
from Windows, but for those that haven't we try to provide a solution
that is as painless as possible.

It certainly would be less work for us as developers to just say 'use
openldap, use MIT or heimdal kerberos, use freedce'. Luke demonstrated
that the approach does work when he wrote XAD. If our aim was to
minimise developer time then that approach would quite possibly be the
correct one, but that isn't our aim. Our aim is to reduce the time and
effort required to deploy Samba for the vast majority of users who
don't have any of these services currently installed.

That doesn't mean we shouldn't be able to use existing services if
they exist. When I wrote ldb I also wrote a ldap backend for it, so
you can use ldb with an existing ldap database. So for those people
who just want ADS and don't care about having a standards compliant
ldap server they can use ldb with its tdb backend, and they don't have
to go through any pain in configuring it (with the tdb backend an
empty file is a valid database, ready to use). For those people who
have gone to the effort of setting up a good ldap infrastructure they
will be able to change one line in the Samba config and they can point
smbd at their existing ldap server. Then we just need some way to
match the schema, but that is a problem no matter what ldap server we
use, as the schema is mandated by the fact that you are using Windows
ADS clients.

It would be fantastic if we could do the same for kerberos. Having a
really simple kdc builtin would be a huge advantage for the majority
of users who have no kerberos infrastructure at the moment and don't
care at all about the fact that ADS uses kerberos. If we could
trivially point Samba at an existing KDC and still implement all the
bits we need to interoperate with Windows then that would be great.

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

[Russ Allbery]

I can only echo what everyone else has said, and also mention that not
everyone who does Kerberos does cross-realm.  There have been security
vulerabilities in the past, fixed now of course, that *only* affected
cross-realm, so sites that never needed it had good reasons not to run it.
And frankly, still do, since after all the best way to avoid potential
vulerabilities in code is to not run it in the first place when it's not
needed.

That being said, I do understand where you're coming from and why you
would need to tie into a KDC pretty intimately to accomplish what you're
trying to do.  However, the more independent you can keep that from the
rest of your application, I think the happier you will be in the long run.
The ideal case is if the minimum necessary KDC hooks could somehow be
determined and modularized and then integrated into an existing KDC
(Heimdal if that's the easiest) with the possibility that other KDC
implementations could pick them up.  That way, the KDCs could continue to
do the KDC thing and you could just use the results.

Jeffrey Hutzelman <[hidden email]> writes:

>     We recently decided to remove nearly all of these independent
>     packages from the OpenAFS tree, and concentrate more fully on our
>     core purpose.  Of the components I mentioned above, the only ones we
>     haven't thrown away are package (which probably should be) and the
>     kaserver, which we've kept around only because there are a few sites
>     out there who still depend on it.  Note that anytime someone comes
>     to us with a question of the form "we're running the kaserver
>     and...", the answer is "don't do that; go get a real KDC".

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

And just think what the world would look like today if AFS had never
contained a KDC and had always asked people to run an external one.  The
linkages wouldn't be as tight as they ended up being, I expect the
migration to K5 would have been easier because of that, the AFS KDC
wouldn't have ended up being a unique implementation with quirks that
differed from any other KDC, and the whole system would likely be more
modular and more robust at this point.

(On the other hand, we might not have had Ubik for the KDC, which would
have been a shame... but on the gripping hand, maybe that would have
sparked more work on separating Ubik from AFS so that other protocols
could have been using it.)

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

[James Peach]

On Tue, May 24, 2005 at 10:06:44AM +1000, Andrew Bartlett wrote:

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

    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.

    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?

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

--
James Peach | [hidden email] | SGI Australian Software Group
I don't speak for SGI.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

[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

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

[Andrew Bartlett]

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

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

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

[Gerald Carter-4]

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

[Andrew Tridgell]

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.

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.

Ideally krb5 and ldap would be like our lib/popt/ code. We detect if
the system has a working popt library, and if it does then we use
it. If it doesn't then we use the version we ship with the code.

That is the idea of ldb with the ldap backend. It means people who
don't care about the fact that their network now has an ldap server
can use the builtin ldb code. For those who do care, they can tell
Samba to use an existing ldap server. The default will be to use the
builtin one, as the defaults are meant for the majority who don't know
about the intricacies of ldap.

If we can achieve that with krb5 as well then that would be
great. Andrew Bartlett has been working with lha to try to achieve
that with Heimdal for quite a while. They have made a lot of progress,
but we still don't have anything we can usefully ship, although its
getting close.

We are not trying to replace the roles that MIT and Heimdal kerberos
have played over the years. If someone wants a KDC, they should
certainly install a real one, and not use Samba as their KDC. What we
want is something that is invisible for people who want to remain
blissfully unaware of the fact that krb5 packets are flying over their
network. They want the Windows admin tools to work and that is it.

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

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

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

[Ken Hornstein]

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

[James F. Hranicky]

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 [phone] |
| [hidden email]                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

[Douglas E. Engert]

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

[Jeremy Allison]

On Tue, May 24, 2005 at 07:32:30AM -0700, Howard Chu wrote:
>
> Nobody is going to just drop it in and turn it on
> and go merrily on their way. Not even Windows administrators.

Yes they are. *Especially* Windows administrators :-). Really.

You're living in a different, self-selected world than we are.
Samba *3* is currently much too hard to use for most people,
and it does much less than Samba4.

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

You've ignored them so far, why would it change now ? :-).

I worked on Kerberos 5 back in 1997. It was hard to use then,
and it's hard to use now. Error messages are opaque and troubleshooting
tools virtually non-existant. I did do a rant about it on
comp.protocols.kerberos once and Sam rightly told me to stop
whining and help fix it :-). But I currently don't have the
time.

But Samba4 needs to be as easy to use and install as W2K. If
it isn't it will fail.

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