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