Generating krb5.keytab

[Sergey Yanovich]

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.

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.

Samba4 and Kerberos may be managed by people in different organizational 
units, so having this option maybe useful. 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.

-- 
Sergey Yanovich