Re: Security permissions bug or inheritant permissions??

From: Joe Richards [MVP] (humorexpress_at_hotmail.com)
Date: 07/10/04 

Date: Sat, 10 Jul 2004 11:47:16 -0400

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 

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net
Kevin Buchanan wrote:
> 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]" <humorexpress@hotmail.com> wrote in message
> news:OoK6VTiZEHA.2488@tk2msftngp13.phx.gbl...
> 
>>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
>>
>>
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>
>>Kevin Buchanan wrote:
>>
>>>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
>>>
>>>
> 
> 
>

Relevant Pages

  • Re: Strange problem in Active Directory
    ... Domain Admins or Enterprise Admins security groups. ... This posting is provided "AS IS" with no warranties, and confers no rights.. ...
    (microsoft.public.windows.server.active_directory)
  • RE: software to control domain administrators
    ... Trustworthy Admins already do this with the explicit knowledge that they ... reverse that auditing, which the auditing mechanism should reflect ... Honestly, if you are looking for something to audit domain admins, then ... Si ha recibido este mensaje por error, ...
    (Security-Basics)
  • Re: Enable non-admin users to access member servers or client PC
    ... the client machines they probably will require to be local admins (Not ... In order to modify server folder permissions the group needs to be ... groups like Domain Admins, Administrators, etc. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Administrator
    ... Well as far as the SQL DBA point I brought up, part of the reason for that is ... that there is no global SQL Admins domain group anyway but that wasn't done ... because of Sharepoint especially since SQL Server existed before Sharepoint ... > me a choice which I can choose to include domain admins as ...
    (microsoft.public.sharepoint.portalserver)
  • RE: SBS2003 setup program on working SBS2003 Server
    ... Remove and readd Domain Admins, Schema Admins, and Enterprise Admins to the ...
    (microsoft.public.windows.server.sbs)