On Sun, 2005-07-17 at 20:21 -0500, Les Mikesell wrote:
> There are hundreds of books and classes on Windows networking and
> about the same for at least some flavors of unix, but there is really
> nothing published about integrating heterogeneous systems and even if
> there were, it would change with every samba release and every windows
> service pack.
Not true! The books are out there, but there's not just "1 cookbook."
The "Samba 3 by Example" comes close, but _only_ addresses the CIFS/ADS
aspects for SMB, _not_ the larger considerations of Kerberos, LDAP, NFS,
etc...
And as far as "change with every Samba release and every Windows service
pack" is _limited_ to _only_ the Windows interfaces. The UNIX naming,
authentication, directory and file services change _much_less_. Why?
Because as a rep from a Microsoft Gold Partner put it best to me,
because Microsoft wants to resell you something every 2-3 years, not
necessarily because you need it.
Which is why putting ADS at the top of your enterprise is a real recipe
for a network that is a PITA. It's better to put your UNIX and other
"open systems" under an open naming, authentication, directory and file
service design, and piecemeal or synchronize with Windows clients and
servers as best as you can.
> The seemingly arrogant attitude comes from having to stick to what you
> know works and there isn't much overlap.
I wasn't saying you were arrogant. Quite the opposite. I was saying
your enterprise IT sounds rather arrogant.
> The AD is being added as a new domaim with users moved over as testing
> proceeds. I have added slave zones to my unix dns to accomodate it.
Which is what most UNIX departments at enterprises that put MS ADS at-
the-top do. It's least ideal, but it does keep the ADS issues away from
you during temporary outages.
If you setup Services for UNIX (SFU), and start managing your Netgroups
there, then setup slave NIS servers on your true UNIX servers. If
management has an issue with supporting SFU, you should enlighten them
to why Microsoft introduced it in the first place. Because Microsoft
wants to control UNIX networks, and NIS is the legacy way to do it.
> I think that's about the 4th time they have done that with service
> packs that you are forced to install because of other security
> issues. I'm sure making samba look bad was not accidental - and
> that it wasn't the last time either.
Conspiracy theories aside, Microsoft has all but said they don't support
anything newer than Windows XP for Windows Server 2003. Reality, the
features and performance of pre-NT5.1 (XP/2003) clients suck, and even
Ziff-Davis isn't afraid to say Samba is far better for pre-NT5.1
clients.
> I keep spare parts...
Oh, I meant if the UNIX/Linux network goes down because of the Windows
admins doing things without telling you, like dorking up your SFU
install (assuming you go that way)?
If you "have to" synchronize Windows and UNIX/Linux users, then you
should be using SFU and its NIS server on a DC.
> Oh, they do understand that here - and the new management even has
> a good handle on how much it would save to run more things on Linux.
> But, everyone has their hands more than full already trying to
> integrate the companies without making additional infrastructure
> changes or re-writing apps.
Okay, maybe it's not as bad then. But seriously, I'm not the only one
heavily recommending NIS and Netgroups here, and the best way to do that
when you're synchronizing Windows and UNIX/Linux users, and your
management has already made your network MS ADS' bitch, is to deploy
SFU's NIS service.
> Yes, if you are lucky you might get that. But it's a snapshot of what
> you can do today. What you need is to understand how you should plan
> for a few years out, and an outsider won't know enough about a business
> (at least if it is an unusual business...) to do that. And in our case,
> nothing we could have planned two years ago would have matched our
> situation now, trying to integrate into a completely different company.
As I said, SFU's NIS server. Solves your problem ... bam! One service.
Your organization is already going ADS, so plan for that. SFU's NIS is
the solution. Nuff said there.
So the next consideration is to design your Netgroups, and modify your
system's /etc/passwd to accept logins for one specific Netgroups. I
believe several on this list already showed you the format. It's that
simple, once NIS is running.
> The reason for unique sets of people on these machines is generally
> for ownership of files and stuff in their home directories, so that
> part of the account setup has to be done individually anyway.
"Unique" isn't exactly "unique" because whether or not a user can login
or is in the /etc/passwd doesn't mean they won't have files with UID/GID
set.
Several have already pointed out how you can _explicitly_ allow only
select Netgroups login. You will define which Netgroup at the
individual system, and then maintain the users, groups and netgroups at
your NIS master (which can be SFU's NIS service).
So I'm still scratching my head on why you are so resistant to NIS and
Netgroups?
> Other than personnel turnover the only things that change later are the
> passwords which are taken care of with simple SMB authentication
> against a PDC now.
That doesn't have to change, period.
At the same time, you also have the option of:
1. Kerberos client authenticating against an ADS one-way trust, or
2. Having SFU's NIS server generate NIS password hashes
#2 is _natively_supported_ on just about every UNIX/Linux flavor. Dude,
you are in for such a treat if you get your Windows admins to put SFU on
one of the DCs. Trust me on this, it's cake.
I mean, NIS is already cake. But synchronizing ADS-NIS is cake when one
of the DCs is your NIS master c/o SFU.
> If the AD can emulate that, I may keep it the same for simplicity.
I don't think you understand.
Instead of having to setup your UNIX/Linux clients to use NTLM to
authenticate against a PDC or ADS DC -- which is a PITA and UNIX/Linux
client-specific -- one of the ADS DCs runs SFU's NIS service, and it
_generates_ the _native_ password hashes in the NIS passwd map.
No more headaches. And it's no less secure than NTLMv2 with null
sessions (a commonly unknown fact).
> The one thing that would be worth the trouble to fix would be CVS -
> it is about the only thing left that doesn't use PAM and
> the number of users is increasing. I know there are patches but there
> is a tradeoff in making a version that doesn't match the distribution.
I don't think you understand.
With NIS, there is _no_ PAM modification required.
Even on non-PAM platforms, you merely tell it to use the NIS passwd map.
And if SFU is your NIS master, it is _automatically_ synchronizing the
ADS SAM database for the domain to your NIS domain password maps.
--
Bryan J. Smith b.j.smith@xxxxxxxx
---------------------------------------------------------------------
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. ;->
