On Fri, 2005-07-15 at 16:27 -0500, Les Mikesell wrote:
> I don't want separate smbpasswd files.
Even in the old days, it was transparent. You can configure NIS-Samba
to synchronize passwords so when you change it via [yp]passwd, the Samba
password changes and via NT password change, the NIS password changes.
In Samba 3.0, there are new backends which radically improve this.
There have always been a lot of NIS, NIS+, LDAP and/or Kerberos
integration options.
> The part I wasn't sure about was whether NIS could supply the
> unix account info (uid, gid, home dir) while allowing
> the password check to be via smb, and whether that combination
> would work with samba as well.
You can check _always_ use whatever information/services however you
configure it on the _client_. By default on just about every UNIX
system, when you setup NIS and bind a client to the NIS domain, you do
*0* else (even on NSSwitch clients, which typically default to an NIS
check).
Changing PAM or the relevant UNIX service to authenticate via NTLM (to a
Windows or Samba server) is the _non-standard_ step. It doesn't matter
whether you are using local files or NIS, this does _not_ change because
you've added NIS. NIS is just a simple mechanism to "NIS domain-wide"
your passwd, group, hosts, etc... files.
> The solaris/freebsd versions I used didn't have an obvious way to use
> smb authentication for ssh/ftp logins.
Solaris _should_ have PAM as of 2.6 onward.
Not sure about FreeBSD (been awhile for me).
Again, _nothing_changes_ if you use NIS in this regard, period.
NIS just augments your local files with maps, not replaces any settings.
I know this is difficult to understand, largely because people are used
to working with Microsoft or Novell where you are "forced" to do naming
X, authentication Y and file service Z -- but in UNIX, you can piecemeal
as much as you want.
When it comes to NIS, all it's doing is _augmenting_ your local files
with NIS domain-wide maps. Everything else is the same. So if you're
already configured NTLM for authentication, just make sure that is used
in PAM or your other configuration files _first_, before local/nis.
> Today these are NT domain controllers actually still running NT.
Then consider _not_ going to MS ADS. Is there any reason you have to?
The "key turning point" in an organization is _before_ they go MS ADS.
After they do, your network is ADS' bitch -- and I use that exact phrase
because that's what it is.
Interoperability becomes increasingly difficult after that step. At
worst, your ADS is in charge of everything. Microsoft quickly had to
add NIS to Services for UNIX (SFU) largely because organizations did
have a lot of legacy systems. But at least with DNS and NIS, you can
setup true UNIX secondary/slave servers for when ADS self-destructs.
The better option is to segment your ADS tree off from your UNIX, be you
have NIS, NIS+ or LDAP with or without Kerberos. That's what most
10,000+ node enterprise networks do. A few even make ADS "submissive"
to their formal LDAP tree -- typically those are established NsDS trees
with 8+ years of production (before ADS was even introduced).
>From the sounds of your arrogant and oblivious IT management, you
probably want to choose the latter.
> The replacement is going to be an AD, but run by a group at another
> location that doesn't like unix.
That right there is the problem. Any IT organization that "doesn't like
unix" is not about "servicing users" but "mandating arrogance." 9 times
out of 10 when I come into a shop, it's that arrogant, oblivious
attitude that causes _all_ the problems.
> We will probably have an AD server at this location with AD replication.
> Can it do SFU if the master doesn't?
Yes. DCs are peers. In fact, I highly recommend you setup _true_
UNIX/Linux secondary DNS and slave NIS servers to the ADS-integrated
primary DNS (I assume they made your DNS ADS' bitch with ADS-integrated
DNS) and ADS SFU master NIS server.
That way if your ADS DC with SFU tanks (which it most certainly will),
your UNIX/Linux clients are SOL until it comes back up.
> I would have done that eons ago if someone else hadn't been
> managing the Windows boxes. But by the time samba was capable,
> the worst of the windows bugs were resolved - and you never knew
> when a windows update was going to break authentication against
> samba again...
My recent favorite "Samba issue" was when Windows Server 2003 / Windows
XP Pro re-introduced an old, _broken_ handshake. In a nutshell, 2003/XP
skipped a step in the handshake. Because this violates the security
protocol, Samba refused to allow access. But 2003/XP went right through
the handshake. It made Samba "look bad," but in actuality, Microsoft
violated their own security protocols!
> No, nobody cares if my job is hard or easy - or how many places I
> have to copy a file to make things work.
And if the UNIX/Linux network goes down?
I feel for you dude. I've come in several times and seen people just
like you in your position. It took me only 1 day before I had the
Windows admins and their managers realizing how much their business
relies on the UNIX/Linux services.
>From that point on, the Windows admins at least _notified_ the
UNIX/Linux admins when things changed, if not asked for input before
they did.
At this point, considering your issues, I'd _segment_ myself away from
the CIFS PDC/BDCs and, eventual, ADS DCs. There are solutions the
synchronize passwords and other things, some of which do not have to run
on the ADS DCs (although that's clearly the easiest to support).
> It's no longer my choice, and this is basically why I've always
> considered it worth the trouble to keep separate logins on the
> oddball boxes. Not just for the Microsoft issue, but to be able
> to replace services with any better alternatives that might come
> along without regard to whether they understood NIS, LDAP, SMB
> or whatever. There aren't so many people that it is a problem
> to set up the accounts. It would be annoying, but not impossible
> to maintain passwords separately - the scheme I use will accept
> either local passwords or a match with the windows domain so I
> won't be locked out regardless.
Well, NIS is old and well understood, just like old Netware Bindery.
It's just like for Netware, ADS' LDAP can support Bindery, but not
eDirectory (largely because eDirectory is a superset X.500 DAP
implementation, long story ;-). So for UNIX, ADS' LDAP can support NIS,
but not fully NIS+ or typical UNIX LDAP schema. But at least it's
something.
> I'll probably attempt to set up the RH directory server to pull
> info from AD eventually.
That might be best, although if you don't have control of the ADS DCs,
or their admins are not open to running services on the ADS DCs, then it
makes it extremely difficult for you (but not impossible).
> I've always thought that the worst possible thing you could do is to
> have someone come in and set up something you don't understand yourself.
Then you haven't been hiring the right type of architects/consultants.
A _good_ architect/consultant spends the _majority_ of his/her time
doing "knowledge transfer," giving you options, feedback and then
explaining what options are available to you, how they work, etc... And
after he/she helps you implement them, you have a full set of
documentation of _your_ operations to follow in case you forget
something.
That's _exactly_ what I do. In addition to my capabilities, I easily
average 200 pages/month in technical documentation (as anyone can attest
on this list, I crank out extensive verbage in no time). I typically
leave a company after 3-4 months with their entire enterprise documented
far better than every before, from the standpoint of _their_ operations
and needs. Not "another manual to read," but a sectional document on
how to conduct all IT operations that are key.
Clients call me back again and again because of it, not because I've
setup something only I understand -- quite the opposite! As every
client has said, "we like consultants like you who document yourself out
of a job!"
> In this case the most trouble it would save is editing a few files
> once in a while, something I've never considered to be a problem. I
> started this thread only because the system tools crapped out on a
> duplicate entry - something that might happen with any system.
NIS (originally called Yellow Pages, a British Telecom trademark) was
invented in the very early '80s by Sun Microsystems. All it does is
replicate typical, local files over the network as "maps," which pretty
much all UNIX/Linux flavors support without issue in their standard C
libraries (i.e., every major C function call in any application can
typically lookup NIS as well as local files).
> I can assure you that no one thinks that Windows is easier. However
> it also isn't going away and new things are going to require AD.
Well, as I put it weeks ago, enterprises have had to deal with this
"issue" since the '90s and the NT infestation. Most enterprises went
with NsDS, and even Sun licensed it as its LDAP backend in its Sun One
architecture. Now Red Hat has (finally!) chucked OpenLDAP, bought NsDS
from AOL-Netscape, and its now GPL (after the negotiated period/dollar
amount -- whichever came first (the period did) -- where Red Hat kept it
a commercial product, per AOL's terms).
Luckily, even for the most heavily infested ADS networks, Microsoft
offers several capabilities:
1. Legacy NTLM authentication, WINS emulation, PDC/SAM distribution
2. One-way Kerberos Trusts to UNIX Kerberos Realms/KDCs
3. Services for UNIX (SFU) NIS, NFS and other services
> But, regardless of any global scheme, the set of valid logins on each
> of these boxes is unique so specifying it in some network setup is
> going to be just about the same amount of work as doing it directly
> on each one.
I think Netgroups would be a "fire and forget" setup on each system.
You do it just once on each system, and then you only have to change the
Netgroup membership on the NIS master from then on.
Even if your NIS master is an ADS DC with the SFU NIS server.
--
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. ;->
