samba - Apr 2003 - Why would I want Active Directory (rather, how to argue against it?)

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.

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@interlinx.bc.ca> wrote in message
news:pan.2003.04.26.05.56.01.279431@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
>