Generating krb5.keytab

[Andrew Bartlett]

On Sat, 2008-06-14 at 15:36 +0300, Sergey Yanovich wrote:
> 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).

It would be better to say that we combine 1 and 2, 3 and 4.  

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

Sure, and that is already the existing design.  All of these parts read
the main ldb (LDAP format) database, independently.  They all assume the
same schema, and rely on more than just the kerberos keys (so LDAP is
more than just an implementation detail, as the full PAC - including
group membership - needs to be generated somewhere, we do it in the
KDC). 

We also prefer to keep the kerberos keys in the main directory (at least
for access, I actually have a module that actually splits them out, but
we don't use it) because this is how we replicate AD passwords inbound,
on DRSUAPI, and we want to be able to replicate them outbound again.  

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/5da8a8d6/attachment.bin