On Mon, 2005-07-18 at 15:57 +0800, Feizhou wrote:
> I just want Kerberos. I am not interested in the LDAP part of ADS.
Remember, all Kerberos does is provide authentication and ticketing.
Even Kerberos, on its own, will _not_ provide much for UNIX/Linux
clients. I think you don't seem to realize this.
Furthermore, if you want to use Windows XP Pro clients and Windows
Server 2003 member servers "as is" with the Microsoft administrative
tools, then you need _all_ of the added LDAP schema, RPC services built
around them, etc... That's why there is a Samba schema added to LDAP,
to support some of this (as well as Samba's stores).
> centralized Kerberos account management that Windows 2000/XP clients
> will accept in domain mode.
But what is "domain mode"?
Do you even know what "domain mode" is?
"Domain mode" isn't really about the Windows server.
It's about the assumptions the Windows client makes with regards to
naming (browser) and authentication/authorization (controller).
In fact, the differences between "workgroup" and "domain" are little
more than what assumptions the Windows client makes. Hence why Samba,
as a server, does _not_ see any difference.
At the "lowest level," the "browser" portion of a "domain" means domains
can span multiple subnets. That's all! This is an _artificial_ Windows
client limitation, one that I covered and even showed an example of in
Chapter 33 of Samba Unleashed ("Cross Subnet Browsing" -- please excuse
the "quality" of that chapter, I wrote it in 1 weekend for the author
who was behind on publication). ADS merely takes this to a point where
you can have multiple domains in a larger tree, and now uses passive DNS
(with an option to manage it inside of ADS' LDAP schema), with WINS for
legacy compatibility, instead of more active NetBIOS broadcasts
(although, yes, WINS was also used before as well).
At the "lowest level," the "controller" portion of a "domain" means NT's
Security Accounts Manager (SAM) is accessible domain-wide. This is
actually to address a limitation and inherit design flaw with NTFS (yes,
the filesystem, long story) as much as to make user management easier.
Older NT 4.0 used NT LAN Manager (NTLM) then NTLMv2 as its
authentication. NT5.x (2000+) now uses Kerberos, but clients can fall
back to NTLMv2 (which is what Samba 2.2 can do, or even Samba 3.0
without a Kerberos back-end).
Again, _all_ ADS does over older NT4 DCs is re-organize how it handles
these details, as well as uses DNS for network naming by default, as
well as Kerberos for authentication. Pretty much nothing else really
changes, _unless_ you start adding in services that extend the schema.
Otherwise, an ADS domain is just a "feature rich" domain in comparison
to NT4. Because Windows "domains" are really little more than naming,
authentication and some way to store the NT-SAM "domain-wide" --
servicing Windows clients who make assumptions based on whether or not
they are in a "workgroup" or "domain." Again, all a "domain" is from
the standpoint of a Windows client -- is a set of assumptions!
Samba 3.0, and even Samba 2.2, was pretty good at handling all the
details you need. This includes its own SAM stores for even _multiple_
domains -- ideally in an LDAP store (hence the Samba 2.2 and 3.0 schema
for LDAP). It can provide the Kerberos chat that Windows clients expect
(as well as a native Windows ADS DC, if native Windows ADS DCs already
control your network). And some RPCs have been reverse engineered so
you can use _some_ NT5.x (2000+) Windows tools to modify things, but not
nearly as well as the older NT4.x (NT4.0) tools. And there are both web
and traditional GUIs for maintaining Samba 2.2 and 3.0 LDAP schema,
including managing users, groups, domains, etc...
> Forget LDAP.
Then what are you going to use for your network store?
Kerberos only does authentication and ticketing. You still have to
distribute information network-wide, be it with NIS, NIS+, LDAP, etc...,
for even UNIX/Linux clients.
> Yes, i know the openldap guys have not shown much interest in adding
> MS-LDAP rpc stuff.
Well, I'm not even looking at OpenLDAP anymore, now that Netscape
Directory Server is available as GPL as Fedora/Red Hat Directory Server.
Red Hat's purchase of NsDS basically said they don't think OpenLDAP is
worth developing any further (and I had been asking for this years
ago ;-).
> eh?
I think you keep thinking that you have to have a 100% MS ADS DC
equivalent. I don't think you realize from the standpoint of a Windows
2000/XP "client," the "domain" is really not much.
> That requires a different GINA right?
Yes and no.
Samba 2.2 and, 3.0 even more so, can use the _stock_ Windows 2000/XP
GINA, and provide services to it. Logon, tokens, etc... Samba will
uses its store (typically LDAP for Samba 3.0 with added ADS assumption
compatibility, multiple Windows domains, etc...) and Kerberos for the
password store and services to Kerberos clients (and a Kerberos client
if its talking to an existing Windows ADS DC -- that's the delimiter).
But if you don't want to deal with all the Windows client "assumptions,"
you can replace its GINA, yes. Then you can provide more "raw"
authentication -- local UNIX, NIS, NIS+, Kerberos, LDAP-stored hash,
etc...
> Right, so what open source option(s) do we have to single-logon
> Kerberos? (please assume apps are also kerberosized)
Kerberos _never_ provides "logon" facilities. Kerberos provides the
authentication and ticketing portion for "logon" facilities.
Samba's RPC capabilities can _use_ Kerberos' logon facilities to provide
for the "assumptions" of Windows clients who think they are in a
"domain." Again, you have to think about what a domain is, from the
standpoint of a Windows client.
Of course, if you have a native Windows ADS DC on your network, then you
are _forced_ into providing the same services it provides. Hence the
delimiter -- once you introduce *1* ADS DC, Samba can't play without it.
If you don't, Samba can do what it wants to make Windows clients happy
-- even Windows 2000/XP quite nicely.
I don't think you're seeing that.
--
Bryan J. Smith b.j.smith at ieee.org
---------------------------------------------------------------------
It is mathematically impossible for someone who makes more than you
to be anything but richer than you. Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them). Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work. ;->