If you have every service on one machine and it goes down, you are done.
No domain, email, file, print, web, nothing. So yes, the fact that that
single box is doing everything certainly makes it a greater point of
failure.
If you have those services spread across systems and you lose your web
server, business goes on. (business should go on either way, but that's
another thread). Users can still send and receive email and access
files. Which do you think your users would prefer? Some or none?
Now, that's not fault tolerance of any single service, no. But it is
fault tolerance of your network.
However, my original thought was this: I don't want people to recommend
SBS based on the number of users alone. Also factor in the tolerance for
lost productivity should you lose that 1 (one) golden box.
Im not trying to point out fault in SBS. I love it, use it at home, and
implement it at customer sites. What I am saying though, is there is
nothing wrong with trying to spread the wealth of services you provide
to multiple boxes, even in "SBSland".
-----Original Message-----
From: Depp, Dennis M. [mailto:deppdm@ornl.gov]
Sent: Tuesday, January 18, 2005 8:49 AM
To: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]; Sullivan Tim P
Cc: focus-ms@securityfocus.com
Subject: RE: IIS6 on W2k3 DCs
Tim,
I find your comments interesting. "Organizations who want fault
tolerance put resources (AKA roles) on separate boxes." This has
nothing to do with fault tolerance. If I have a machine with 1 role or
a machine with 50 roles, it is still a single point of failure. The
fact that a machine with 50 roles affects more people does not make it
any more or less of a single point of failure. To eliminate the single
point of failure, I have to use some type of redundancy. In the case of
domain controllers, this redundancy is accomplished by adding a separate
domain controller. In the case of a web server, Network Load Balancing
can be used. In either case the cost of this redundancy is usually
double the hardware costs. For a Small Buisness, this is not practical.
SBS helps small buisness by providing a lower priced alternative. The
drawback to SBS is it limits your expandability. For a small buisness
this may be a good trade off.
Dennis
Sullivan Tim P wrote:
SBS doesnt have a choice.
Your box is your domain controller, and its your exchange server, so it
has to have IIS installed. No way around it. That doesnt mean its not
going against a common school of thought based on good sensible
practice.
This seems to be a common topic, but again the more you have on one
box,
the more you lose should that one box crash, have a hardware failure,
or
be stolen by gypsies. It then comes down to the tolerance level of your
organization to something like this.
So....
Organizations who want fault tolerance put resources (AKA roles) on
seperate boxes. DC on one, mail on another, web server on another. Your
web server may not even be on the domain.
So is the desktop the biggest threat, probobly, but your DC is (I would
say) your most important machine on the network, and should be
protected
accordingly. Should it fail, AD, exchange, and everything else,
including your desktop's and user accounts, are gone. Have fun
restoring
from tape, or your ASR, if one was made.
Number of employees shouldn't dictate a choice between SBS and
sepearate
products, your mission requirements should.
Tim
-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
[mailto:sbradcpa@pacbell.net]
Sent: Thursday, January 13, 2005 8:12 PM
To: Joe Blatz
Cc: focus-ms@securityfocus.com
Subject: Re: IIS6 on W2k3 DCs
I may be laughed from here to kingdom come on this listserve...but I
gotta ask....
Common best practices for whom? Define a role please? What is "common
best practices" may not be good enough for one person, but may be just
fine for another. What are they doing with this box? Exposing it to
the web as a web server...yeah I'd still argue that's insanity.
But Small Business Server 2003 runs with IIS on our domain controller.
Where's MY security risks these days? Not my server..nope......it's my
desktops where my security risks lie.
Port 80 is closed on my server but IIS is still on there. On the
outside is Firewall, intrusion detection and what not. Running with XP
sp2 firewalls on the inside but still need to get to more use of user
mode on the desktop.
Am "I" freaking out over IIS on my domain controller? Nope. Not at
this moment. Am I freaking out over admin rights on desktops?
You betcha I am... big time.
www.threatcode.com
Susan...the wacko SBSer.
Joe Blatz wrote:
The security guides published by many sources (NSA, MS, etc) stated
that IIS4 and IIS5 do not belong on DCs. Common best practices would,
in general, guide that an HTTP (IIS or otherwise) daemon doesn't
belong
on DC.
By referring to numerous security guides written specifically for NT4
and W2k we were able to convince a customer of this. Now that IIS6 has
come out, and the customer feels that IIS6 is much safer than IIS4 and
IIS5, they want to put it back on their DCs.
I am looking for sources that document that this is a bad idea. When
it
comes to the NSA they don't have a guide for W2k3 but have instead
pointed to Microsoft's "Windows Server 2003 Security Guide" and the
use
of the "High Security" settings and templates. The MS guide does
(rather subtly) show that IIS should not be on a DC. They only show
the
HTTP service enabled on an IIS server, but I think this may not be
direct enough for our client.
Any help finding an explicit statement that IIS6 does not be belong on
a DC would be greatly appreciated.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
----------------------------------------------------------------------
-
----
----------------------------------------------------------------------
-
----
-----------------------------------------------------------------------
-
---
-----------------------------------------------------------------------
-
---
-----------------------------------------------------------------------
----
-----------------------------------------------------------------------
----
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
