[Samba] Re: Why would I want Active Directory (rather,how to argue against it?)

[Stephen P. Villano]

I agree on all counts, though I am still a lot irritated over MS LDAP being
majorally broken until recently.
The DNS auto-update is quite a selling point. AD has a lot of admin selling
points, to include Darwinian paring down of the incompetency pool of admins
and granularity of rights with proper propagation, though parts of that are
counter-intuitive.
I'm currently working in a mixed, large domain. Things work reasonably well
and irregularities tend to be somewhat predictable. We're slowly removing
NT4 from the network in favor of NT5, errrr W2K.
For some uses I'll happily recommend Samba/Linux or Samba/*BSD. For others
(particularly large, complex networks) I'll recommend MS solutions. In our
university environment I'd go with deploying a Samba server authenticating
off of the domain for a small/mid department only, never for the entire
domain. Sorry, I'd not go with it yet for most of the hospital network
either, as much as I'd love to...
Ad just has too many points in its favor to ignore or refuse when upgrading
is reasonable. The only reason I can justify not even partially deploying AD
is in a heavily cost constrained NT4/9X environment.
As for XP... They can place that up their BDC, it's not THAT great and
small/mid businesses are stuck with the higher costing professional version
(I have a *LOT* of experience with small/mid business solutions, cost is a
primary factor as it comes out of the approving party's pocket directly)!

----- Original Message -----
From: Michael Fair <michael at daclubhouse.net>
To: <samba at lists.samba.org>
Sent: Saturday, April 26, 2003 4:11 AM
Subject: [Samba] Re: Why would I want Active Directory (rather,how to argue
against it?)


> It really depends on your expectation of
> needing AD compatibility.
>
> I also haven't used it, but here's what it offers.
>
> - Single Sign-On via Kerberos
> The trick part here is that an AD ticket has all the
> user/group membership information stuffed inside the
> PAC of the kerberos ticket.  Without getting into too
> many details the PAC was originally intended to provide
> you with a token that the server would then use to ask
> a second server what the given principals priveleges
> were.  By stuffing the membership information directly
> in the PAC AD obviates the need for this second trip.
> However nobody else does it that way, nobody knew what
> the layout of the MS-PAC was, and MS wasn't sharing.
> That is what threw everyone into a tizzy when MS first
> unveiled this scheme.  Since then things have lightened
> up, it seems that MS and other sources have released
> enough public info (with the associated permission to
> use said info) to allow members of the Samba group to
> produce a compatible PAC thus solving that particular
> aspect of SSO in an AD environment.
>
> - Automatic discovery / Automatic registration
> AD is also embedded with DNS specifically SRV records.
> This is the most oft overlooked aspect of AD when I
> hear people (especially Linux enthusiasts) try and
> declare what is useful about AD.  AD has a method by
> which a service and start up, register itself within
> the AD network, and a client of service need only do
> an DNS SRV query to find out what machine and what port
> that service is running.  There is no OSS equivalent
> to that process in widespread use yet.  But this is
> really only important A) if you have AD only services,
> or C) clients that actually use SRV records, and C) a
> large enough scale of services that manual DNS entries
> are a PITA.  (I happen to take (D) the admin is not
> particularly motivated to do the manual setup and likes
> the auto updating, auto healing nature of the design)
>
> - Uniform, OS provided, redundant Access Control Lists
> for any and all services integrated into the framework.
> There is _no_ OSS equivalent to this except in small
> largely untested environments (macs.sf.net comes to mind).
> Again, this is only important if you actually care to
> deploy services that need/use this functionality.
> AD being it's own little island unto the world makes
> this only useful to AD integrated services.  Don't
> need/use AD integrated services, then you don't need
> this functionality.
>
> - An AD Domain can be one or more DNS domains
> This is only important in larger scale networks
> where DNS subdividing helps for managability.
> It can be useful under other circumstances, but
> in general it's not terribly important.
>
>
>
> I don't know to what degree Samba currently implements
> each of those aspects of AD.  If all you need are some
> Authentication services and file/print services in a
> SOHO environment then Samba as currently advertised
> should suite your needs well.  No AD required for that.
>
> If you want/need all the Network OS packaging that comes
> with it, then it might not be such a good idea just yet.
>
> So in general,a more complete description of AD via the
> protocols it uses would be:
> LDAP, Kerberos, DNS, Proprietary Access Control List API,
> and MS Glue API to cram it all together.
>
> Don't need/want all that served to you the MS way, then
> you don't need AD.  A would imagine that any serious
> 3rd party app isn't too interested in the general market
> if the only support AD environments.  MS of course might
> do everything in their power to try and get you to
> upgrade by making their products more compatible with
> AD environments than non-AD environments.
>
> I'm sure that there are some inaccuracies here that I
> hope someone will correct me on.  A "State of Samba"
> in regards to some of these would be great as well.
>
> -- Michael --
>
> "Brian J. Murrell" <brian at interlinx.bc.ca> wrote in message
> news:pan.2003.04.26.05.56.01.279431 at interlinx.bc.ca...
> > I think I understand what Active Directory is all about.  I understand
> > LDAP and I understand Kerberos.  I can see how AD (well, Kerberos
> > actually) enables single-sign-on (I assume it deals in tickets with the
> > Windows clients as standard Kerberos clients do) and can make life easy
in
> > a large network (which, IIRC was one of the design goals of Kerberos in
> > the first place).
> >
> > But lets say I have a smallish network where I only need a couple of
file
> > & print servers (and the need for even a couple is only for
redundancy --
> > PDC and BDC(s)) and I am using W2K right now.  What arguments could I
> > likely face when I propose replacing those with Samba (2.2 or 3.0) PDC
and
> > BDC(s)?
> >
> > The way I see it, I can build a Samba PDC/BDC pair and use some hackery
to
> > replicate the passwd databases between the two (a utility based on
dnotify
> > or even fam could be quite helpful here to avoid polling for file
> > changes), or even better, use LDAP on the DCs and replicate from the PDC
> > to the BDCs and provide all of the redundancy and distributed access of
a
> > Windows PDC/BDC network.
> >
> > So what else does AD do in a W2K AD network?  Does Exchange use the
> > Kerberos tickets AD hands out?  If I replace the W2K servers with Samba
> > servers will Exchange cease to allow users in?  Or will they need to
> > re-authenticate to the Exchange server?  Where will it get it's
> > authentication data from if the W2K AD DCs go away?
> >
> > What likely future impact could this have with other MS/AD based
servers?
> > Could I find myself having to put W2K AD back in to get other services
to
> > work again?
> >
> > As you might be able to determine, my actual operational experience in
an
> > MS network is slim-to-none (way closer to none than slim) so any
> > experiences/opinions would be welcome.
> >
> > Thanx,
> > b.
> >
> >
> > --
> > To unsubscribe from this list go to the following URL and read the
> > instructions:  http://lists.samba.org/mailman/listinfo/samba
> >
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba