I do not feel that having a DC serve files poses a significant risk
for the simple fact that a DC already serves files. To simply add to
this list does not introduce a new service. Any attack method which
would allow a user to circumvent NTFS permissions on files you share
could also be used on sysvol or ipc$. This would work whether you
made it a file server or not.

The only obvious problem is availability, and as a frequent consultant
to small organizations I can say that for most of them that's a way of
life.

Also, if one of those high-school kids is able to hop across volumes
and work through NTFS permissions to damage that server in some way,
let me know so I can give them a job.

- Other Tim

On Thu, 24 Feb 2005 16:00:09 -0500, Murtland, Jerry
<MurtlandJ (at) grangeinsurance (dot) com [email concealed]> wrote:
> 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 (at) nativemode (dot) com [email concealed]]
> Sent: Wednesday, February 23, 2005 11:41 PM
> To: focus-ms (at) securityfocus (dot) com [email concealed]
> 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 (at) nativemode (dot) com [email concealed]
>
> ________________________________
>
> From: Sullivan Tim P [mailto:tim.sullivan (at) nativemode (dot) com [email concealed]]
> Sent: Mon 2/21/2005 6:21 PM
> To: focus-ms (at) securityfocus (dot) com [email concealed]
> 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 (at) nativemode (dot) com [email concealed]
>
> ------------------------------------------------------------------------

> ---
> ------------------------------------------------------------------------

> ---
>
> ------------------------------------------------------------------------
---
> ------------------------------------------------------------------------
---
>
> ------------------------------------------------------------------------
---
> ------------------------------------------------------------------------
---
>
>

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

[ reply ]