This is a discussion on Re: Current ideas on kerberos requirements for Samba4 - Samba ; Gerald (Jerry) Carter wrote: > The other side of the fence is to reimplement AD. A > very admirable goal. But to be 100%, you are not longer > acting as a thin layer of glue. In some ways, Samba ...
Gerald (Jerry) Carter wrote:
> The other side of the fence is to reimplement AD. A
> very admirable goal. But to be 100%, you are not longer
> acting as a thin layer of glue. In some ways, Samba
> no longer acts as an interoperability tool. It the network
> portion of the OS.
> At this point the justification to install Samba is
> not based on interoperability because Samba is acting
> just like AD. Not solving existing interoperability issues
> between Unix and AD. The justification of installing
> Samba is based on license fees.
I might add that AD is in some way an "enabling technology" for
Microsoft. People buy it to get the best out of other MS technologies
like Sharepoint or Exchange, it is the glue and cornerstone of an MS
based network infrastructure. I don't know if that is a goal for samba.
Personally I'd rather like to see it as a bridge for windows clients to
an unix network, e.g. if samba will be able to trick clients into an
kerberos backed domain and hand them out tickets, one will be able to
finally use Kerberos/GSSAPI with all SASL enabled services. I'd love to
see my windows clients doing http/imap/cvs/whatever with a ticket
obtained from samba.
just my 0.02€
BTW: This is a great discussion. I think it is very important for
users/administrators to be aware of the conceptual issues samba has to
cope with. This is invaluable background information a HOWTO will never
provide. I hope to read some more details about the issues mapping AD
concepts to "standard" protocols (e.g. nested/universal groups)