ActiveDirctory security questions

[mschunk]

I want to lock down AD, really hard...and delegate authority to a
select few OU's that contain most of the users/computers/groups. (I'm
growing leery of using the term "delegate authority" now that I'm
understanding more about controlling security to AD objects by hand.)

What is the "godly" group/account?

1) Administrator
2) Administrators
3) Enterprise Admins
4) Domain Admins

I'm starting to think the only correct answer is #2. The "Built-in"
Administrators group.

I just learned that #1 is wrong. By "default" the (local)
Administrator on the DC is a member of #'s 2,3, and 4 above...and it
does not HAVE to be that way.

Enterprise Admins, and domain Admins...seams to have full control only
because they are member of #2.

Can anyone confirm this?

Next question...the SYSTEM account.

it looks like the NT "SYSTEM" account is getting full control, by
default, of every single object created. But this permission is being
applied explicitly to every single object...not by inheritance.

This bothers me! To me, this means that ANY code that is executed in
the context of the SYSTEM account has full control of active directory.
Many services running on the DC fall into this category. Or am I
mistaken, and the "local system" account so many services are running
under actually something different?

Is there a better newsgroup for security-specific issues w/ AD?

Thank you for your time.

 

[Joe Richards [MVP]]

You can post in the security newsgroups too but many of us scan both.

Let me rephrase your questions/comments:

Q: What is the god security context?

A: LocalSystem. Localsystem has more rights over the local machine than any
other account.

Of the secprins you list (your 1-4 list), they have different rights at
different levels. Any ONE of those groups (and also even lesser powered groups
that have interactive access to DCs) can escalate to any level of permissions in
a forest. The security boundary of AD is the forest, not the domain like it was
in NT4.

When you say DAs have full control only because they are in #2, I assume you
mean control over DCs for non-AD functions? If so, yes, DAs and EAs do not have
power over the hardware, all of the permissions are delegated in the directory.
This was the same as it was in NT4. In fact, the only purpose of domain admin in
NT4 was as a group that could be placed in the builtin admin groups of member
machines, otherwise the administrator ID had full control over everything on the
DC including the SAM.

I am not sure why you are thinking you should lock down the various Admin IDs
and localsystem. It is pointless. You protect those by not giving them out
except to just a couple of people. For instance I ran a Fortune 5 AD and we had
4 Domain/Enterprise Admins. No one else had any local or management access to
the 400 DCs around the world. Site admins got very limited delegated rights on
specific objects/containers.

The vast majority of services running on any machine, run as localsystem.
However since AD runs in localsystem, it doesn't matter about the others.
LocalSystem account has complete and utter control over AD if someone
compromises a DC, that is why you don't use DCs for a bunch of functions, you
make them DCs and you don't let people mess with them. You don't let anyone but
domain admins log into DCs, you don't let anyone but domain admins manage the
file system or services of DCs, etc.

joe

 

[mschunk]

Thank you VERY much for your comprehensive reply....getting my head
straight.

On DA's and EA's...I have but one domain in the forest, and I think
you just taught me something new.

So, when a workstation/server is joined to a domain...DA is added to
that PC's LOCAL Admins group by default. I've seen that. OK. EA's
however, are not.

I assert then, that EA is a forest thing, DA is domain thing...and the
EA's, by default, become members of the DA of each domain that is added
to the forest...that DA's are, by default, added to the LocalAdmins of
each comp that is joined...but that DA's do NOT _have_ to be members of
the _domain's_ built-in administrators group. It's Just that way by
default, like it is for newly joined PC's.

Am I getting warmer???

On SYSTEM. So they _ARE_ the same thing. ("LocalSystem" in services
snapin = "System" in ACL security windows.)

Well, let me count the number of services. Oh my. There are a TON, as
you know I'm sure. So, how feasible is it to run most services within
a context other than localsystem?

event Log
Clip Book
Alerter
COM+ event system
Computer browser

....I don't want to list them all here...

What about "big" ones like:

Disk Manager
Workstation (lanman)
Sever (lanman)

....Telnet?

WMI services?

....Security Accounts Manager?

Geez. as I write I'm staring at the services list, and even w/ years
of working with windows, I don't even know what half this stuff REALLY
does.

What about drivers? I got an ATI card installed on the DC and it runs
something I know little about: the "ATI Smart" and "ATI HotKeyPoller"
services? Change account, bounce service and pray?

What about DNS and DHCP. As long as these two run in a context that
has access to their data files...will they run?

Or am I wasting time? It just seams like LocalSystem is an awefully
big hole.

....But, LocalSystem has power over only it's domain? or does it get FC
of all child domains as well?

 

[Joe Richards [MVP]]

Don't even think about changing the context of the services that come with
Windows, you will just break it.

As for DA/EA/Administrators. When you get down to it, each can escalate to the
others if they don't have those rights already. If DAs are not in the
administators group of the DCs you will find things that don't work exactly as
expected.

I really don't understand what you think you are going to accomplish by trying
to lock down the admin groups and localsystem. Windows isn't designed to have
you try and lock down those items and when you get down to it, you can't.

 

[mschunk]

Services...OK. I won't. But I will look into eliminating any service
that is not essential for the roles of a DC/DHCP/DNS server. I noticed
that 2k3 have a "services" and a "network services" account for many
services that on my 2000 DC's use "local system" is it knows (and
perhaps even documented) as to how one could go about setting up such
accounts on a 2000 DC?

DA/EA/Administrators...I don't understand how they can esscalate but I
know you know what you are talking about. As you stated before...keep
the number of accounts that are members of these groups to an absolute
bare minimum. I need to do a better job at that.

Joe, can I also...

1) Rename these groups and make three new groups with the same names?
(I assume there are attirubtes that make these groups what they are?)

2) Remove the DC "Administrator" account from EA/DA/Administrators?
Basicaly, strip the the DC Administrator account down to a domain user?
AFAIK, this is not possialbe for the local administrator
account...though the local can be renamed....what about the DC
administrator account?

New questions: I know how to say what computer accounts a user account
is allowed to log into...but what about the inverse? Is there any way
to restrict what users are allowed to run on a computer, from the
computer object's point of view?

 

[Joe Richards [MVP]]

Yes, minimize the services running, that is a great plan. K3 is better than 2K
in this in that many services are disabled/off by default instead of on by
default. There are usually more than can be disabled though depending on the use
of the machines.

A lot of work was put into switching the services to use network services
account for K3, again, not something you want to be mucking with in 2K. If it is
that important, upgrade.

1. Honestly I wouldn't rename them. It doesn't protect anything and could in
fact cause some apps to break or operate incorrectly. The groups have well known
SIDS anyone who wants to attack the groups are going to look up the SIDS and get
the real group names. Ditto for renaming admin ID. The one place renaming the
admin ID helps is if someone doesn't have netbios access to the domain/machine,
then they have to guess at the admin ID (such as FTP or web services). That
doesn't play into account for groups at all so there is no benefit except to
confuse stupid people and stupid people aren't generally something you need to
worry about.

2. The builtin admin account can be renamed. But as I mention in 1, the
resulting security gained from it is usually nil. You have to ask yourself, what
do you feel you are protecting against? The admin account can be determined in
milliseconds by someone who really wants to know and has any kind of netbios
access to the systems involved. The best way to treat the admin account is to
give it a password of about 30 or 40 complex characters, seal it in an envelope,
stick it in the president's or ceo's or cio's or directory of ITs safe and then
never use it. There is no need for that account. I worked in a fortune 5 where
we did that and in the three years after it was done, the envelopes were never
touched, no need unless there is an out and out disaster and no other accounts
were working. Even then, if you know what you are doing, the envelopes weren't
need because if you had physical access you just break in anyway. Which leads to
the next aspect of protecting the admin account. Once it is locked up safe, you
monitor the lastLogon time and password changed time on all DCs to make sure the
password hasn't been changed and the account hasn't been logged into.

3. You can not control any aspect of what users can use what systems by the
Computer objects in AD. All of that permissioning is handled directly at the
computer itself. It may receive policy settings from the domain applied onto OUs
that maintain a computer object, but the policies are only setting things on
the local machine.

 

[mschunk]

Services: Upgrade to 2k3. Yeah. OK. Will do...it's just cheaper.

#1 and #2 after posting...that's what I thought you might say.
Well-known SIDs...Points taken.

#3. Bummer. That's what I thought...just making sure.

Thanks a lot for your help Joe.