Re: Windows Domain Controllers: Risks involved

[Brian Desmond <brian.desmond () MORANTECHNOLOGY COM>]

Hi Marmina-

 

So fundamentally you’re going to have to agree to trust the people who are
your domain admins. Let’s say you apply ACLs to all your data preventing
domain admins from seeing it. As a domain admin I could still go reset the
password of a user in say the Finance department, login with their ID and
access the data they have access to. Or I could add myself to let’s say the
Finance Users group and have access to a folder full of data which is
secured by that group.

 

So as far as proactive protection here’s a few things I’d aim for:

 

è Know where your sensitive data is. It should all be on file servers,
Sharepoint servers, a document management system, etc. Sensitive data on
people’s laptops, personal machines, USB thumb drives, etc is just asking
for getting your employer some quality real estate on the front page of the
newspaper one day. 

o   Once you know where your sensitive data is you can manage the access to
it with ACLs. The first thing you’d do here is pull the default ACL which
gives domain admins amongst others access and apply a custom ACL. A typical
folder access structure that actually tends to work really well is to have
two groups defined for every file share - <Share> Modify and <Share> Read
where <Share> is the name of the share. I push hard for these standards
based permissions structures because overly complicated permissions add a
lot of support overhead and in my experience you’re going to drastically
increase the skill level requirements of your Wintel admins if you expect
them to support complicated ACLs. 

o   Once you have defined baseline permissions you can audit the data with a
script or some other tool on a recurring basis and trap any deviations from
the baseline. 

o   If you’re still concerned, setup auditing at the file system level. Use
an event log collection/alerting tool (e.g. Microsoft SCOM & ACS) to trap
audits for suspicious activity (e.g. change of permissions).

è Audit group membership changes in the directory

o   Again use something to collect these security events, alert, and report
on them

è Manage group membership with a self service tool in conjunction with
identity management. Generally speaking the people best equipped to speak
for access to data are the people who own it. Use a workflow/self service
package where users can request access to a group. When the user requests
access to the group an approver (e.g. the owner of the data the group
secures) has to approve it, possibly the approver’s manager, and also
possibly the requestor’s manager.

o   On the flipside, setup access renewal for really sensitive stuff. Every
X months (call it 6) every member of a group has to have their membership
re-approved by the group owner/whoever else. This handles the ever present
problem with people not losing access to data specific to their old job when
they change jobs. 

 

As far as encryption goes, this is a double edged sword in some ways. EFS
(Encrypting File System) works great – it’s native to NTFS and has been
there since Windows 2000. The downside of it is that it’s really not the
easiest thing to support and it will generate support calls. In order to
really do EFS right you’re looking at deploying PKI. There are a very
limited number of people who know how to actually do this right, so to be
quite honest you’re going to want to hire one of those people as a
consultant to set it up, write the support procedures for you, and train
your people. When someone loses access to their data for whatever reason you
use what’s called a recovery agent in EFS which allows you to decrypt the
data without the user’s key. EFS will definitely make it a lot harder for a
determined domain admin to get at the data. That said, I would spend a good
deal of time weighing risk versus reward on this part of the discussion
though (EFS).

 

Thanks,

Brian Desmond

brian.desmond () morantechnology com

 

c - 312.731.3132

 

Active Directory, 4th Ed -  <http://www.briandesmond.com/ad4/>
http://www.briandesmond.com/ad4/

Microsoft MVP -  <https://mvp.support.microsoft.com/profile/Brian>
https://mvp.support.microsoft.com/profile/Brian

 

 

From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Marmina Abdel Malek
Sent: Friday, March 13, 2009 6:39 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Windows Domain Controllers: Risks involved

 

 Brian, you seems to be a super expert. So tell me, do you have any
recommendations to proactively protect the sensitive information stored on
these machines such as budgets, payroll, e-mails, etc. I'm interested in a
solution to protect users data from being accessed by domain admins, rather
than a solution which can detect malicious access. Should we use encrypted
folders/drives? if yes, what if a user forgot his password, how can we
recover his/her files?

 

Marmina

 

 

 

On Fri, Mar 13, 2009 at 10:41 PM, Brian Desmond
<brian.desmond () morantechnology com> wrote:

Sure so the basic idea was that you would have this empty root and you would
isolate a few key security groups e.g. Schema Admins and Enterprise Admins.
You'd have a couple trusted people or maybe some sort of system where two
trusted people had half the password or something to get access to accounts
in these groups.

In turn you'd end up with X number of child domains with say X*3 domain
admins - all different people. The theory then was that domain admins in
Dom1 were only able to control things in Dom1, Dom2 Domain Admins could only
control Dom2, and so forth. Above all the assumption was that neither Dom1
admins or Dom2 admins could do anything with your root domain, RootDom.

In reality, as a domain admin in a child domain you can get at security
groups in the root domain or another child domain. It's not particuarly hard
at all for Dom1 domain admins to make themselves members of the enterprise
admins group or similar if they want.

So the net result today is that if you want true security isolation with AD
you need separate forests. The only thing an empty root really gives you now
is an "anchor" name so to speak in a multidomain namespace.

Thanks,
Brian Desmond
brian.desmond () morantechnology com


c - 312.731.3132

Active Directory, 4th Ed - http://www.briandesmond.com/ad4/
Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian


-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv

[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Jason Testart
Sent: Friday, March 13, 2009 3:33 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Windows Domain Controllers: Risks involved

Brian Desmond wrote:
> The model of having the empty root is a Windows 2000 era
> thing that was largely from misguided assumptions.

Could you please elaborate on what these misguided assumptions might be?

jt

--
Jason A. Testart, BMath               | Voice: +1-519-888-4567 x38393
Manager, IT Security                  | Fax: +1-519-884-4398
Information Systems and Technology    | http://ist.uwaterloo.ca/security
University of Waterloo, Waterloo, Ontario  N2L 3G1 CANADA