Generating krb5.keytab

[Sergey Yanovich]

Andrew Bartlett wrote:
> On Sat, 2008-06-14 at 12:54 +0300, Sergey Yanovich wrote:
>> 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.  

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

My point of view is further from the subject, because I know less. But 
that is sometimes an advantage. I see several big parts here:
1. Kerberos protocol - common part;
2. Kerberos protocol - MS AD extension;
3. LDAP protocol - common part;
4. MS AD LDAP schema - MS AD extension;
5. DEC/RPC protocol (or whatnot) - MS AD extension.

My impression is that the current approach combines the solution for 2. 
and 4., is not good or bad, it is just an observation. That's the 
critical part, because it prevent splitting out anything (except for 
DNS, which is already done).

But that's probably not unavoidable. User accounts resides in LDAP, and 
authentication is done by Kerberos. The fact that Kerberos stores its 
keys in the same LDAP is just an implementation detail. The whole deal 
probably (again probably) maybe boiled down to who writes the keys to 
the LDAP. Right now, it is LDAP server, and everything is tightly 
coupled. But if we teach kadmin to work with LDAP independently from the 
LDAP server, the thing could be split into 3 part - KDC+kadmin, LDAP, 
DEC/RPC. And the only thing that will couple them, will be the LDAP schema.

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

No worries. I gonna promote Samba4 actively, so I just want it to be as 
agile as possible, partly because it is always easier to sell great 
things :)


-- 
Sergey Yanovich