[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ms
Subject:    RE: Domain Controller Best Practice - Thanks!
From:       "Chris Costantino" <chris () lschs ! org>
Date:       2005-03-04 3:11:39
Message-ID: 269424F6C5E17A4596BC279F506972D662AA27 () LSEXCBE ! Academic ! lschs ! org
[Download RAW message or body]

Although completely off topic, I feel it is necessary to correct the following \
statement:  
<quote>
Second thing to correct is that a DC does not contain any SAM DB whatsoever.
It contains a copy of the Active Directory (NTDS.dit).  This is not a SAM
DB.
<qoute>
 
A DC does have a SAM database that is used in case Active Directory Restore Mode is \
ever invoked.  If you use use the AD Restore Mode password anywhere else, then you \
are giving away sensitive data.  
Chris
________________________________________
From: Adam Vaxvick [mailto:avaxvick@sunwaptasolutions.com]
Sent: Wed 3/2/2005 5:53 PM
To: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!
I never reply but in order to stop the misinformation I thought I should say
something so someone doesn't accidentally heed the advice given previously
in this thread.

The first and most important thing is that by making a Windows 2000/2003
server into a DC is that it is automatically becoming a file server that is
accessible to every user account in the domain by default.  This is
perfectly normal and absolutely required.  As this guy seems to be
blissfully unaware there are 2 very critical default file shares on every DC
that need to be available to all authenticated domain users for read access.
Namely these 2:

\\DCserver\NETLOGON - all logon scripts are stored here that are run when
users logon (it's actually a direct mapping to a sub folder in the SYSVOL
folder)

\\DCserver\SYSVOL - the root folder for both scripts and most importantly of
all the group policies for domain that this DC is in, this is also used for
GP and script replication between DC's

This is why the 'Authenticated users' group has the 'access this computer
from the network' security right by default on DC's.

Second thing to correct is that a DC does not contain any SAM DB whatsoever.
It contains a copy of the Active Directory (NTDS.dit).  This is not a SAM
DB.

I have no problems using a DC as a file server in small to mid size
companies that don't have the resources for dedicated DC's or dedicated file
servers.  Now I would strongly recommend that any user data shared should be
on a separate partition from the OS and should only be setup by someone that
knows NTFS and share permissions well and can secure them appropriately.

-AV
MCSE/MCSA 2000, MCSE/MSCA 2003, CCNP


-----Original Message-----
From: Murtland, Jerry [mailto:MurtlandJ@Grangeinsurance.com]
Sent: Thursday, February 24, 2005 2:00 PM
To: 'Sullivan Tim P'; focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!

I don't think I've heard anyone say that "you are not creating a real
security risk by allowing your DC to also function as a file server".  In
fact you are.  All user authentication is occurring on this system.  User
ID's and Passwords for your entire organization are stored here in the SAM
file.  I would consider this a substantial risk to any IT infrastructure.

Risk is measured in degrees proportionate to security controls in place.
When you allow 'typical' users to access sensitive servers (especially an
infrastructure server), you increase the risk of this system being
compromised and your network being exploited.  Now, you can lower that risk
by taking certain measures, it would be up to you to determine what those
measures are.  However, if it doesn't cost you anything to rebuild your DC
and recreate your user base (backup), then the level of risk is also
lowered.  However, in most cases, time does have a value, and the data
contained on a system should also.  You also have to look at it from a
liability perspective.  If the data were compromised, how could it affect
our organization?

There are four things you can do with the risk that you have assessed:
Accept, Reject, Transfer, or Ignore.

You really need to evaluate your environment to assess your options.

Jerry J. Murtland, CISSP



-----Original Message-----
From: Sullivan Tim P [mailto:tim.sullivan@nativemode.com]
Sent: Wednesday, February 23, 2005 11:41 PM
To: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!



Thanks to everyone for replies on the DC configuration. I got a number
of good links.

I would summarize the dialog and what I found through reading as this:

It would be *best practice* to limit the roles a DC has, however you are
not creating a real security risk by allowing your DC to also function
as a file server.

________________________
Tim Sullivan
Nativemode Technologies
623.910.4700
tim@nativemode.com

________________________________

From: Sullivan Tim P [mailto:tim.sullivan@nativemode.com]
Sent: Mon 2/21/2005 6:21 PM
To: focus-ms@securityfocus.com
Subject: Domain Controller Best Practice



I am in need of some supporting documentation relating to Domain
Controllers.

The situation is this. A medium sized school would like their single DC
to also be a file server. This DC would be serving about 300 people,
along with another file server and an email server.

My initial recommendation is multiple domain controllers for the simple
reason of fault tolerance of the schema. They buy this.

However, they would like to see technical documentation saying that it
is not a good idea to have a domain controller share roles as a DC and a
file server.

One of my main concerns, aside from load, is that high school age kids
are using the network. They like to poke and prod. I would rather them
not even poke at the DC. Also, as the DC has no local security database,
you can no longer use permission assignment best practice. To me it just
seems like a bad idea, but I need documentation to back it up.

Can anyone offer resources to illustrate this? I am scouring technet and
the MS AD deployment docs now.

Thanks,
Tim



______________________
Tim Sullivan
Nativemode Technologies
(623) 910-4700
tim@nativemode.com

------------------------------------------------------------------------
---
------------------------------------------------------------------------
---




---------------------------------------------------------------------------
---------------------------------------------------------------------------



---------------------------------------------------------------------------
---------------------------------------------------------------------------



---------------------------------------------------------------------------
---------------------------------------------------------------------------

---------------------------------------------------------------------------
---------------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]