Generating krb5.keytab

Andrew Bartlett abartlet at
Sat Jun 14 12:12:47 GMT 2008

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

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


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Red Hat Inc.        

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

More information about the samba-technical mailing list