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

Brian J. Murrell brian at interlinx.bc.ca
Sun Apr 27 17:18:20 GMT 2003

On Sat, 26 Apr 2003 01:11:52 -0700, Michael Fair wrote:

> - Single Sign-On via Kerberos

OK.  Actually I understood this feature.  I am just wondering how it
applies in an MS network.  SSO to all of what?  If my DCs are my
file/printer server(s) (let's say I mirror the data contents of my PDC to
my BDC as well -- afterall what's the point of the BDC if the PDC goes
down and it has all of the shares on it?) what else would SSO authenticate
me to?  I had kinda suspected Exchange if it was present in the network,
but am not sure.  But what else is there to authenticate to a netowrk of
MS services?

> The trick part here is that an AD ticket has all the
> user/group membership information stuffed inside the
> PAC of the kerberos ticket.

Right.  I followed some of this dicussion through the press of the last
few years.

> However nobody else does it that way, nobody knew what
> the layout of the MS-PAC was, and MS wasn't sharing.

Right.  All in the press.  :-)

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

Cool.  So is this all "on paper" so far or is there any code out there to
do it?  If the info for generating a compliant PAC is out there, what is
stopping the Samba folks from implementing an AD server?  Other than the
constant shortage in the OpenSource field -- time/money/manpower of course?

> - Automatic discovery / Automatic registration
> AD is also embedded with DNS specifically SRV records.

Yes, I was aware of this too.  It's really a neat feature.  But
reproducable as well.

> There is no OSS equivalent
> to that process in widespread use yet.

But again, this must only be a resource issue.  This feature should be
reproducable with current OSS tools.

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

Manual DNS entries are always a PITA aren't they?  :-)  One also has to
know the names that the services use in the AD DNS.  I ran across the LDAP
service name when I was setting up LDAP here.  IIRC, you are supposed to
be able to leave the "host <ldap_server>" parameter out of nss_ldap's
/etc/ldap.conf and it will use the _ldap._tcp.domain.com. SRV record in

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

I agree with that completely.  :-)

> (macs.sf.net comes to mind).

Just downloaded and am reading the whitepaper.

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

OK.  This is what I was hoping.  But what I am weary of is replacing the
W2K DCs and then sometime down the road they want to implement some other
MS solution for which there is no OSS equivillent (for example, perhaps
Exchange) yet and it _requires_ an AD server.

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

Well it's not so much a question of whether _I_ want it but moreso will an
MS application be released requiring it, making all of the MS-license
savings of Samba null and void?

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

Right.  I guess this is worry/fear that needs to be overcome when trying
to "sell" the Samba solution.

Thanx for all your input, it was very helpful.


More information about the samba mailing list