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