Don Munyak <[EMAIL PROTECTED]> wrote:
> OK...Let me back up the bus a little. I'm not a *nix admin
> although I try. My background is in M$. And my area of
> expertise has been primary LAN based.
Understand where you're coming from. The majority of my background
in the '90s was NT and UNIX LAN networks for engineering (_never_
Windows 9x -- my NT adoption pre-dates 95, and _heavily_ Linux on the
desktop as early as 94). Biggest difference between UNIX and Windows
mentality is that UNIX is a set of piecemeal technologies you can
mix'n match into a usable system, whereas Windows is a set of
integrated technologies that are rather fixed (or difficult, but
possible, to work around).
When I do Linux training, I actually cater to individuals like
yourself. You're already very knowlegeable about implementing a set
of technologies from Microsoft. All I have to do is break down those
Microsoft technologies into the individual pieces, and then show you
where various UNIX piecemeal services replace them. E.g., ADS into
the specific authentication, directory, file and naming services and
options (including legacy). You actually know them, just never
looked at them from that angle separate from the others and
piecemeal.
> Design primer:
> I have two win2003 servers and two winXP workstations.
> One server is essentially a dedicated file server that also runs
> Clipper applications for back-end processing of data.
If you're into Clipper, you'll probably want to learn about the
Harbor Project if you haven't already.
> The other server is running IIS6 for public http, asp, php access;
> mysql for back-end database to asp and php front-end.
> The two machine communicated via SMB shares.
Ugh, open RPC. ;->
Have you considered a system-to-system VPN? IPSec doesn't work as
well as advertised in Windows (although Server 2003 is better), and
there are some larger issues with it working at layer-3, when many
RPC security issues of Windows' RPC services are actually at layer-2.
> I have configured the IPSEC policy to only allow ingress/egress
> communication on the LAN. Access to shares is limited to local
> accts/groups and authentication is via NTLMv2.
You can actually use Kerberos ticking instead of NTLMv2, even outside
setting up ADS. It's far more secure, although not nearly as
straight-forward. Of course, not all Windows services are
Kerberosized -- at least not without formal ADS (and not even them
sometimes) -- so it's might be a moot point.
> I currently have a given account/password setup on each
> box, like in peer-to-peer sharing.
Are you doing share-level (share-only) security?
Or user-level (share+filesystem) security?
> Each server will only allow http/https/ssh from public access.
> The winXP workstation are used for front-end processing. They
> connect to the file server through shares.
> Again, I have a limited IPSEC policy for these as well.
At the fear of being a pest, IPSec can't always be trusted. Most
consider Microsoft's whitepapers on its alledged "Security at
Microsoft" to be one big and huge joke. Especially since security
with its RPC services an issue at layer-2, and not layer-3.
But, again, I guess I'm just being argumentative there. ;->
I just prefer to use a VPN and keep all RPC services on it.
> For remote access I have installed the bitwise ssh server daemon on
> each of these workstations. From the remote desktop, we setup an
> ssh tunnel to the workstation, then rdp in through the tunnel to
> run front-end processing scripts.
Now that's very secure. Excellent.
> All four computers are in a workgroup called "test". All four
> computers have two separate accounts, admin/administrators
> group, and processing/power user group
> The preocessing account has the same password for each computer.
> When creating permanent shares between boxes, I have to specify
> computername\account & password.
> I am setting up OpenFiler for the ability to centrally store data
> files from each server as backups. I was planning on doing batch
> RSYNC from the windows servers -to- the OpenFiler server as a
> nightly service inlieu of relying on tape backup.
A lot of people argue disk v. tape. But the reality of today is that
it's really disk (near-line) + tape (off-line).
E.g., "Dissecting Virtual Tape Libraries"
http://www.samag.com/documents/sam0509a/
On a setup like yours, I'd do diff rsyncs nightly, then commit to LTO
tape sometime during the week (possibly several times over the week
-- staging various backups).
> The purpose of my original question:
> From reading the Openfiler doc's , as I understand it, will not
> allow you to use local accounts for network access.
OpenFiler is like _any_ "filer" solution. If you've used NetApp
filers or other NAS devices, the concepts are actually quite a shift,
but a good one IMPO (especially from a security standpoint).
Authentication is not locally configured, authorization reference is
only configured/stored with accessable resources.
> OpenFiler relies on some sort of central account management
> service. Not wanting to either install a DC/AD server, nor
> make one of the existing servers a DC/AD server, I was
> inquiring to the possibilty of using LDAP on the OpenFiler
> server.
I don't think you even need to go that far. You can probably tap
your existing Windows servers and their local SAM (system account
manager) over NTLMv2.
Then again, and not trying to take away from OpenFiler (as I'm not),
but you really don't have much of a formal authentication+directory
approach in your network design for a "Filer" solution. It will
work, but I think you're going to be introducing details you don't
want to -- at least based on what I've heard or where you think you
need to go.
> In a nutshell...I am stumbling through what I think I need in order
> to make OpenFiler work in this environment.
Again, I think you're might be "hacking in" all sorts of workarounds
that you don't want. At the same time, it _could_ be that you
finally address your needs with a _sound_ authentication+directory
approach that does _not_ use ADS.
E.g., You _can_ run NsDS on Windows as your authentication+directory!
You can then peer-replicate that auth+dir between Windows, UNIX,
Linux, etc... And you can have it use specific SSL ports (which can
even be tunneled) and _not_ general RPC services like ADS does.
If you're looking for _that_ kind of solution, then that's definitely
a good move IMHO! It just doesn't have anything to do with OpenFiler
-- although OpenFiler can definitely use it.
--
Bryan J. Smith Professional, Technical Annoyance
[EMAIL PROTECTED] http://thebs413.blogspot.com
-----------------------------------------------------------
Americans don't get upset because citizens in some foreign
nations can burn the American flag -- Americans get upset
because citizens in those same nations can't burn their own
_______________________________________________
Openfiler-users mailing list
[email protected]
https://lists.openfiler.com/mailman/listinfo/openfiler-users
