Security permissions bug or inheritant permissions??

[Kevin Buchanan]

In our IT department, we have several domain admins, but we want to limit
their access to Active Directory.

The scenario:
In a OU called "Test OU", we have set "Enterprise Admins" to have Full
control and "Authenticated Users" to have "Read" only permissions in the
security tab.

The problem:
"Domain Admins" still have full access to edit Group Policy even though they
aren't in or a member of "Enterprise Admins". If we remove "Authenticated
Users" from the security altogether, then the "Domain Admins" cannot access
the "Test OU" group.

Why would the Domain Admins still seemingly have "FULL" access even though
they SHOULD only have the permission of "Authenticated Users" (read only)?
When we remove the "Authenticated users", then they aren't able to access
the group - so it would seem that a domain admin is being checked against
the ACL list, but why would they have "Full" control if the "Authenticated
Users" only have read only access?

TIA,
KB

 

[Joe Richards [MVP]]

First off, anyone that has at least administrator permission (and even less if
they know what they are doing) on your DCs are effectively Enterprise Admins.
You can not lock AD down to the point that Domain Admins are limited. You can do
it and trust that the domain admins aren't going to go undo what you did, but
you can't guarantee it. If you trust them to that point, why lock them out anyway?

Second off, group policy isn't stored in OUs. It is a stored in files in SYSVOL
and groupPolicyContainer objects in the policies sub-container of the System
container. The only thing for a GPO that would be stored in an OU is a link to
the GPO POlicy Container object. So even though it looks like your domain admins
can't edit the policy when you take away authenticated users, they actually can,
they just have to go into a different OU and say edit policy.

Finally and again because this needs to be burned into your head, you can not
secure your domain or your forest against people who have administrative access
to DCs or anyone who manages a service running in localsystem on a domain
controller.

joe

 

[Kevin Buchanan]

Joe thanks for your comments - here are my replies:

If you trust them to that point, why lock them out anyway?
- Because it isn't just a matter of trust, but job responsibility and
accountability.

Second off, group policy isn't stored in OUs.
- Right you are - and I knew that. My intention was to prevent a domain
admin from "fixing" something stemming from a help desk call (or whatever
the reason). It isn't their job, but in the sense they think "oh, I'll help
out - what harm could it do".

Finally and again because this needs to be burned into your head, you can
not
secure your domain or your forest against people who have administrative
access
to DCs or anyone who manages a service running in localsystem on a domain
controller.
- Again, I agree with you. However, social engineering is (nearly)
impossible and therefore it is my reliance upon the system's means of
security that I have to hang my hat. We aren't at "odds", except in the
perception of how I feel the OS should provide security.

The people with the "keys to the kingdom", utimately, must be honest and
trustworthy. However, that doesn't mean that everyone should be domain
"gods" - they should heirarchal structure that enforces layered security
levels - even among domain admins. I know that the reality is that
Microsoft probably hasn't stepped to the plate to address it...therefore,
the keys to the kingdom, do indeed, rest with more than necessary.

I think that end-user security is granular, but admin security is pretty
much on or off in most areas - which fails to meet our business needs.

Thanks for your comments - I think we agree on most of what you said. But,
if have worked as an Enterprise Admin in a large organization working with
several domain admins, then you must already understand there isn't enough
security granularity with administrators.

BTW - our "domain admins" do not have access to our DCs - only the
Enterprise Admins. But the Admin Tools allow them to, otherwise, pretty
much have access to the security structure/policies (i.e, GPO and OUs).

-KB

 

[Joe Richards [MVP]]

The last Active Directory support position I had was managing an AD for a
company which I started April 2000 and ended just this year and was about 400
DCs and 250,000 users across the world so that should qualify as large global
enterprise. I know we were the largest production installation for quite a while.

We had four domain admins for the 8 domains in our forest. They were the same
four guys who were Enterprise Admins. That was me and two other analyst guys and
a manager whom I threatened to beat up if he ever used his ID when I wasn't dead
and we all sat within 10 feet of each other.

Everything else was delegation and that was minimal even, local site "admins"
could modify group memberships and create/delete workstation accounts. No one
had local logon rights to any DC but us which was tricky sometimes when your
server is under water in the Genk flood and you sit in Michigan but we made it
work.

All user management was through a provisioning system we built. Group creations
and server computer creations were done through my group through normal ticket
requests. We handled something like 6000 tickets last year, a vast majority were
requests for new objects or removal of old objects, all of those functions we
had scripted so creating 5000 groups was as simple as creating one and they were
both easier than even pulling a group up in the gui.

Actually I would say my two co-workers did most of those tickets because my
primary function was to automate processes and consult to app developers around
the company and work on integrating new things into the directory such as
Exchange and managing/supporting the Exchange/AD Dev Lab.

There is perceived granularity with admins and when I say admins I mean real
built in admins, not people with delegated rights to OUs or other objects, but
there truly is no granularity at all. Once someone has access to the file system
of a DC or physical access to the DC, it is very difficult from stopping someone
from doing whatever they have in their head to do.


My opinion is that if someone needs native administrator rights to AD or domain
controllers from administrator to domain admin to Enterprise Admin, you might as
well make them an Enterprise Admin because then you don't fool yourself and your
management and security folks don't fool themselves with a perception of false
security. As you said, the granularity does not exist there, so trying to make
it look that way does no favors. I think it is a huge issue with AD but
understand what a tremendous change it would take to correct.

joe

 

[Kevin Buchanan]

Then I guess will be continue as we have worked for past 4-5 years. I hope
someone from Microsoft is "listening". There needs to be security
granularity from the top down!

-KB

 

[Andrew Mitchell]

Then I guess will be continue as we have worked for past 4-5 years. I hope
someone from Microsoft is "listening". There needs to be security
granularity from the top down!

What Joe has already said is that there is already granularity available, but
you need to set it up.
If you have 'administrators' that you don't want to have full domain admin
rights, remove them from the domain admins group and use delegation to set
the permissions you want them to have.

It is not a Microsost problem if you add people to the domain admins group
who should not be domain admins.

 

[sogjin]

Soryy, guys, I don't get it. Are you saying that any (sub)domain admin in
the forrest can add himself to EA security group? Sounds like privilege
elvation bug for me

 

[Kevin Buchanan]

It is priviledge elevation (see my original post).

The bottom line: there isn't enough granularity of security and we have
tried delegating security - it just isn't flexible enough. SO - they
(domain admins) will remain as they are so they can do their job. It is
just too bad that you can't govern their access/controls. Just as I have
always believed and known, and Joe admits it - either they are an admin or
they aren't.

We can agree to disagree - but there just isn't enough granularity of
control for domain admins. They still can have more control than I want to
allow.

-KB

 

[Joe Richards [MVP]]

I think you are still missing my point. If you allow someone to be an
administrator (a true admin, not someone delegated), they are for all intents
and purposes a domain admin and an enterprise admin. The only reason they can't
get those is if they prevent themselves.

Most everything should be delegated off. As I mentioned, we had 9 domains
comprising 250,000 users on 400 domain controllers across the world with 3
people with native admin rights. Everyone else was delegated.

There is a ton of flexibility in the AD delegation model below native admin. I
disagree when you say there is admin and there is user. It is only correct if
you mean native admin. If you mean user with admin like rights, then that is
mostly possible to delegate. If it anything for delegating rights on a Domain
Controller then no, but then the DC is a KDC and in many places a CA and as they
always say for all of those services whether it is Windows or Unix or mainframe,
you don't share power on those boxes.

You can delegate user administration to the nth degree. Ditto for computer admin
and group admin.

joe

 

[Kevin Buchanan]

Good points - and I suppose I agree - delegated permissions allow
granularity. I guess I haven't examined it well enough, so I'll retract and
say that I'll start experimenting with delegated rights with our domain
admins.

We use delegated rights for other people in the IS department (for handling
user password changes and AD user updates).

Thanks for the advise - I hope I am able to leverage enough delegated rights
to shrink our domain admin memberships.

Thanks!
-KB

I think you are still missing my point. If you allow someone to be an
administrator (a true admin, not someone delegated), they are for all intents
and purposes a domain admin and an enterprise admin. The only reason they can't
get those is if they prevent themselves.

Most everything should be delegated off. As I mentioned, we had 9 domains
comprising 250,000 users on 400 domain controllers across the world with 3
people with native admin rights. Everyone else was delegated.

There is a ton of flexibility in the AD delegation model below native admin. I
disagree when you say there is admin and there is user. It is only correct if
you mean native admin. If you mean user with admin like rights, then that is
mostly possible to delegate. If it anything for delegating rights on a Domain
Controller then no, but then the DC is a KDC and in many places a CA and as they
always say for all of those services whether it is Windows or Unix or mainframe,
you don't share power on those boxes.

You can delegate user administration to the nth degree. Ditto for computer admin
and group admin.

joe

 

[Joe Richards [MVP]]

Take a look at the Delegation Whitepaper at MS Downloads. There is a whitepaper
and an appendix. It is pretty intensive, it took me forever to read it when
doing the tech review.

 

[Kevin Buchanan]

Joe: Thanks for the much need advise. I will find this white paper and put
it in the "reading room". I really appreciate your comments.

-KB