Generating krb5.keytab

[Andrew Bartlett]

On Sat, 2008-06-14 at 12:54 +0300, Sergey Yanovich wrote:
> Andrew Bartlett wrote:
> > On Thu, 2008-06-12 at 11:08 +0300, Sergey Yanovich wrote:
> >> There maybe a few points to consider:
> >> 1. Samba will probably be much happier in the long run, if it manages to 
> >> put 'hdb_samba4.so' (and 'win_dc' plugin as well) into Heimdal's tree, 
> >> so that it is updated/patched together with the rest of their code.
> > 
> > I don't expect this to happen.  The reason these are plugins to
> > Heimdal's stable API and ABI rather than the other way around is because
> > they are better maintained in Samba (they use a *lot* of Samba) and
> > because we expect to maintain them as part of Samba into the future.  A
> > good packaging will of course place them in the right filesystem
> > location to be used by Heimdal. 
> 
> If plug-ins use only stable ABI, this approach is fine.
> 
> >> 3. Using external KDC is a solution that address both 1. and 2. from 
> >> above. However, the solution seems to be in a distant future. However, 
> >> there is a half-way solution: internally build the external KDC with 
> >> proposed Samba-related patches. This will require an /etc/init.d-style 
> >> script to launch that KDC after Samba, similarly to how smbd is launched 
> >> after nmbd in Samba 3.
> > 
> > I do not expect this to happen, because I don't see what benefits it
> > brings us.  One of the gains in Samba4 is that we don't leave the
> > administrator the launch interdependent services, but instead provide it
> > in one deamon.  Samba may be a marvel of Software Engineering, but it
> > does not follow that our users should have to see it's internal
> > construction for it to start :-) 
> 
> The question is rather "see it's internal construction to use it". See 
> Samba4 is on the linux server, and is using a linux KDC, it is natural 
> to manage it in linux way.

But it is a very long way from a linux server in the services in
provides, and (more importantly) the integrated way they must be
provided.  

> BTW, I don't see much difference from user's point of view between 
> Samba4 *being* KDC and Samba4 *starting* KDC the same way Samba3 starts 
> nmbd.

I see that as a flaw in Samba3's design (based on it's history and with
good reason at the time), not an advantage. 

> Samba4 and Kerberos may be managed by people in different organizational 
> units, so having this option maybe useful. 

Sadly due to Microsoft's design of AD, these must be co-located.  That
said, I certainly understand where you are coming from - it mirrors many
of the discussions we had when Samba4 first started, and first looked at
using or building a KDC.  People who understand Kerberos are naturally
very protective of their KDCs, and their initial comments were similar. 

> However, I understand, that 
> resources are always limited, and the only available path is the one of 
> least resistance. With that said, as I stated before, the current path 
> may result in certain adoption resistance. Samba3 isn't usually the 
> central part of linux domain infrastructure, it simply provides one of 
> the services. Samba4 is going to alter the things here significantly, 
> and was thinking about ways to soften transition/interop issues.

It is an unfortunate part of the way AD is designed, and the overlap of
services.  We hope to allow Samba4 to be a consumer of an external
directory (this is the purpose of the LDAP backend project), but it will
always be a big intrusion on the rest of the infrastructure, simply
because of the protocols it must serve.  

I appreciate your comments, and don't mean to just push them aside.  As
you have seen, we are looking to move to a system-provided KDC (in the
form of Heimdal libkdc, which smbd will link to), but I strongly believe
that Kerberos as-is is way to hard to manage, and that of the big things
Microsoft got right with AD is that kerberos is 'just there'.  

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080614/5eb46470/attachment.bin