Generating krb5.keytab

Andrew Bartlett abartlet at
Sat Jun 14 09:38:01 GMT 2008

On Thu, 2008-06-12 at 11:08 +0300, Sergey Yanovich wrote:
> Andrew Bartlett wrote:
> > When we finish the work to use Heimdal externally, it will be trivial to
> > package a '' that the kadmind (or an externally launched
> > KDC if someone is mad enough to want that) would be quite happy to load,
> > should that be how you wish to manage it.  We already implement the enum
> > and a few other methods that the KDC will never use, just for this
> > case :-)
> 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. 

> 2. When linux-minded person reads that Samba uses Heimdal KDC under the 
> hood, the person immediately installs Heimdal's client tools, and tries 
> to launch kadmin on the server. When the servers replies negatively, the 
> person glances the docs, and after no clues found there, writes to the 
> mailing list. The person may optionally try to find the solution in the 
> source code, but that doesn't change much ATM ;)

Feel free to craft an appropriate document for the wiki.  However, while
I like our choice of Kerberos backend, it isn't our aim to intentionally
expose the complexity of kerberos administration (and particularly
Heimdal's particular method) to our users any more than Microsoft does. 

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

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