Re: Prevent changes to Administrator password

additional domains in the same AD forest DO NOT give you any ADDITIONAL security.

The AD forest is THE SECURITY BOUNDARY.

To add to what I already said: *ANY* member of a Domain Admins group *MUST* be trusted in what he does with his account. If you *DO NOT* trust that person, *DO NOT* make him/her a member of the Domain Admins groups

Why? Domain Admins can *misuse* the powers of a DC. That's why!


The answer: check what those people *REALLY* need to do and implement a solution based upon that
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

"Taz1972" <Taz1972@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:DE1560A5-FD45-415D-A008-CE52B8B58E7A@xxxxxxxxxxxxxxxx
Thanks Jorge - I suppose your answer makes sense.

What I will do is hold off until we retructure and go over to a subdomain
model and then simply give those admins in their respective new subdomains
'domain admin' rights only in their domains.

sound feasible?

P.S. we are considering moving from .local to .net. There are some
compelling issues for this – the main one being the .local is (in some
instances) ignored and not reachable by some OS’s.

Jorge - how can this be best accomplished and do you know of any good
documentation for this?

Thanks,
Admin




"Jorge de Almeida Pinto [MVP - DS]" wrote:

all those proposed changes won't do you any good. You can set a million DENY
ACEs for a certain DA and in a few clicks that same DA undoes what you have
done.

rule of thumb:
* A DA can do ANYthing!
* You cannot prevent a DA from doing ANYTHING
* End of story

see a similar story:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/28/Granting-admin-level-access-for-the-OS-on-DCs-but-not-for-AD_2E002E002E00_.aspx


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

"John Policelli [MVP - DS]" <JohnPolicelliMVPDS@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:4478301B-2C17-4599-ADCB-E388F3515E60@xxxxxxxxxxxxxxxx
> I am aware that a DA can become EA. However, if you put the right > controls
> in
> place, you can also mitigate this.
>
> As I previously mentioned, I was throwing a "potential option". I was
> upfront with this in my first response to this post. I did not state it > is
> tried, tested, and true. However, it is a starting point for the user > who
> posted this question.
>
> Nonetheless, you make a good point Deji, you would also need to ensure > the
> DAs in question do not have the ability to change group membership on > the
> Restricted Admins group to mitigate against what you propose Deji. You
> would
> also need to make sure the DAs in question cannot elevate their rights > to
> EA,
> which is feasible.
>
> I still agree with everyone - don't give DA to anyone you do not trust.
> However, you can build on my potential option if you want to find a way > to
> try to mitigate this risk instead of living with the risk.
> -- > Please rate my posts: helpful/not helpful/answer/not an answer.
>
> This posting is provided "AS IS" with no warranties and confers no > rights!
> ALWAYS TEST!
>
> Blog: http://johnpolicelli.wordpress.com
>
>
> "A, Deji" wrote:
>
>> You are aware that a DA can become an EA, right? And that the DA, with
>> the
>> know-how, can overwrite pretty much any definition in the domain. I'm
>> sure
>> that you know all these. But (just thinking about your proposition,
>> having
>> not tried it out yet), what if the DA in question just simply removes
>> his/her account from the Restricted Admin group and clears the flag?
>>
>> Deji
>>
>> "John Policelli [MVP - DS]"
>> <JohnPolicelliMVPDS@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> wrote in message
>> news:196E5FDF-271B-4A6E-A365-14749F76B74C@xxxxxxxxxxxxxxxx
>> > By adding the Deny Write Permissions ACE, these individuals will not
>> > have
>> > the
>> > permission to modify the ACL on AdminSDHolder. This is what prevents
>> > them.
>> > -- >> > Please rate my posts: helpful/not helpful/answer/not an answer.
>> >
>> > This posting is provided "AS IS" with no warranties and confers no
>> > rights!
>> > ALWAYS TEST!
>> >
>> > Blog: http://johnpolicelli.wordpress.com
>> >
>> >
>> > "A, Deji" wrote:
>> >
>> >> John,
>> >>
>> >> what is to prevent these admins from undoing all these deny
>> >> permissions
>> >> you
>> >> are setting, do whatever they want to do, then set it back to >> >> whatever
>> >> you've recommended? Are you implying that these modifications will
>> >> actively
>> >> prevent a Domain Admin from messing with an object in his/her >> >> domain?
>> >>
>> >> Just curious.
>> >>
>> >> Deji
>> >>
>> >> "John Policelli [MVP - DS]"
>> >> <JohnPolicelliMVPDS@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> >> wrote in message
>> >> news:56E9E7F2-F207-4396-81DB-AD9900317B60@xxxxxxxxxxxxxxxx
>> >> >I agree with everyone on this post...you should not give DA if you >> >> >do
>> >> >not
>> >> > trust someone. However, the reality is there are cases where you >> >> > may
>> >> > need
>> >> > to
>> >> > give DA to someone. Also, just because you do not want them to
>> >> > change
>> >> > the
>> >> > password of the Administrator account in the root domain, does >> >> > not
>> >> > mean
>> >> > you
>> >> > do not trust them. So I am giving you a potential option to help >> >> > you
>> >> > mitigate
>> >> > the risk of these individuals changing the password on the
>> >> > RootDomain\Administrator account.
>> >> >
>> >> > First, you need to understand that permissions on the
>> >> > RootDomain\Administrator account are applied via AdminSDHolder so
>> >> > you
>> >> > need
>> >> > to
>> >> > modify the permissions on the AdminSDHolder object in the root
>> >> > domain.
>> >> > Keep
>> >> > in mind that doing this will prevent these individuals from
>> >> > resetting
>> >> > the
>> >> > password for any user that is a member of a group that is >> >> > protected
>> >> > by
>> >> > AdminSDHolder and prevent these users from modifying the ACL on >> >> > any
>> >> > user
>> >> > that
>> >> > is a member of the AdminSDHolder group. You need to decide >> >> > whether
>> >> > this
>> >> > is
>> >> > feasible based on your delegation requirements. If you decide >> >> > that
>> >> > this
>> >> > is
>> >> > feasible, this is something you can TEST. Remember, these are >> >> > pretty
>> >> > serious
>> >> > changes, so test the heck out of it in your environment before
>> >> > implementing
>> >> > it into production.
>> >> >
>> >> > 1) Create a group in your root domain (call it whatever you want,
>> >> > but
>> >> > I'll
>> >> > refer to it as "Restricted Admins")
>> >> > 2) Modify the AdminSDHolder in your root domain as follows:
>> >> > - Deny the Restricted Admins group the Reset Password permission
>> >> > - Deny the Restricted Admins group the Write Permissions >> >> > permission
>> >> >
>> >> > You can view the following for more information on modifying
>> >> > AdminSDHolder
>> >> > permissions.
>> >> > -- >> >> > John Policelli
>> >> >
>> >> > Blog: http://johnpolicelli.wordpress.com
>> >> >
>> >> > This posting is provided "AS IS" with no warranties and confers >> >> > no
>> >> > rights!
>> >> > Always test before proceeding.
>> >> >
>> >> >
>> >> > "Taz1972" wrote:
>> >> >
>> >> >> Hello,
>> >> >>
>> >> >> I administer a server 2003 AD domain which spans many sites >> >> >> across
>> >> >> the
>> >> >> globe. Problem is there are too many people who knew the root
>> >> >> administrator
>> >> >> password (which contains enterprise admin rights), so I decided >> >> >> to
>> >> >> change
>> >> >> the
>> >> >> password. I then gave the other admins new accounts with just
>> >> >> domain
>> >> >> admin
>> >> >> rights so they have just enough rights to do their jobs. They do
>> >> >> not
>> >> >> need
>> >> >> enterprise admin rights.
>> >> >>
>> >> >> The problem is that the other admins can change the root
>> >> >> administrator
>> >> >> password at their leisure, and this is not what I want them to >> >> >> be
>> >> >> able
>> >> >> to
>> >> >> do!
>> >> >>
>> >> >> How can I prevent then from changing the password of the root
>> >> >> administrator
>> >> >> account? Is there a registry hack or GPO setting that can do >> >> >> this?
>> >> >> Is
>> >> >> this
>> >> >> even possible to prevent?
>> >> >>
>> >> >> Hopefully there is some way to solve this, and I would greatly
>> >> >> appreciate
>> >> >> your quick advise.
>> >> >>
>> >> >> Thank you,
>> >> >> Admin
>> >> >>
>> >>
>> >>
>>
>>

.

Relevant Pages

  • Re: Disabling some Admins from creating new user objects
    ... BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx ... * This posting is provided "AS IS" with no warranties and confers no rights! ... our administrators from creating user objects in certain OU's, ... they are Domain admins overrridgin any direct modifications to their user ...
    (microsoft.public.windows.server.active_directory)
  • Re: Unable to prevent OU deletion by Domain Admins?
    ... That's how ACLs work, or at ... Microsoft's own guidelines for parsing ACLs states that DENY ACLs ... I understand that domain admins have the delete and delete subtree ... I have a folder where Domain Users have Full control rights. ...
    (microsoft.public.win2000.active_directory)
  • Re: Security without signon
    ... I am thinking that you didn't create a new workgroup file to secure it with. ... I have changed the owner of the database and the tables to a user ... > this group and removed all table rights from the default Admins group. ...
    (microsoft.public.access.security)
  • Re: "Access Denied" to local machine mgmt console
    ... That's already in there by default by the fact that the Domain Admins group ... workstation is joined to the domain. ... an Enterprise Admin to be able to remotely control/connect to a workstaion ...
    (microsoft.public.win2000.active_directory)
  • Re: Log on Locally
    ... even if I do not have the rights to log on locally, ... > Logon to the machine as a standard user and use the runas command. ... > snapin to reset the policy. ... I didn't check very well and I add Domain admins to ...
    (microsoft.public.win2000.security)