Re: Controlling server security -- to domain or not to domain?
From: Daniel Billingsley (dbillingsley_at_NO.durcon.SPAAMM.com)
Date: 12/10/03
- Next message: Russell: "Trouble accessing microsoft sites..."
- Previous message: M. H...: "Message Rules, Outlook Express"
- In reply to: Charles Otstot: "Re: Controlling server security -- to domain or not to domain?"
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Controlling server security -- to domain or not to domain?"
- Reply: anonymous_at_discussions.microsoft.com: "Re: Controlling server security -- to domain or not to domain?"
- Reply: Charles Otstot: "Re: Controlling server security -- to domain or not to domain?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 10 Dec 2003 11:35:18 -0500
Well, I disagree. We're not really talking about "standalone" servers in
the pure sense, as they all have to be part of the network, accessed by
users and applications who must supply credentials of course. So at the
very least you have a bunch of servers physically on the network that each
has its own SAM database. I would guess that someone who has compromised
one of those boxes would find enough information on it to get the next
server, and the next, and so the dominoes would fall. Assuming the DCs are
especially secured (including physically), adding these other servers to the
domain actually improves security in this regard in my mind.
I guess maybe I'm taking somewhat more of a pragmatic view here. With
several layers of firewall and (I presume) NAT, etc., as the OP described he
has in place, it seems to me the biggest risk to these servers is from
within the organization. That is to say, I'd say the risk from internet
attacks has been mitigated to a satisfactory comfort level already,
regardless of whether they're added to the domain or not. Adding a server
to the domain, changing the local administrator NAME, and giving it an
uncrackable password seems like the obvious way to go to me.
"Charles Otstot" <saries@notmyreal.address.com> wrote in message
news:OZo87hovDHA.2408@tk2msftngp13.phx.gbl...
>
>
>
> "Daniel Billingsley" <dbillingsley@NO.durcon.SPAAMM.com> wrote in message
> news:e%23E1F1nvDHA.1340@TK2MSFTNGP09.phx.gbl...
> > How is that true?
> >
> If nothing else, it makes an attacker's life more difficult, since gaining
> access and/or control of a standalone box gives fewer entry points to the
> domain and hence, the overall organization. Obviously, as sP said, it
would
> be more work, but in this light also makes some sense.
>
> In the end, it may not being the appropriate answer for any sP's
> environment, but the idea is certainly valid. The point is especially
valid
> for Internet-facing servers (e.g. web servers). While maintenance overhead
> is indeed greater, the additional protection afforded by isolating (both
> physically and logically) those servers often outweighs the additional
ease
> of administration afforded by domain membership. Keeping services such as
> external web and email outside of the confines of the domain *and* outside
> the confines of the network (putting them in a logical and physical DMZ)
> helps to prevent intrusion into the internal LAN and affords additional
> protection to (generally) more confidential data and applications.
>
>
>
>
- Next message: Russell: "Trouble accessing microsoft sites..."
- Previous message: M. H...: "Message Rules, Outlook Express"
- In reply to: Charles Otstot: "Re: Controlling server security -- to domain or not to domain?"
- Next in thread: anonymous_at_discussions.microsoft.com: "Re: Controlling server security -- to domain or not to domain?"
- Reply: anonymous_at_discussions.microsoft.com: "Re: Controlling server security -- to domain or not to domain?"
- Reply: Charles Otstot: "Re: Controlling server security -- to domain or not to domain?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
